- Deploying Enterprise PKI on Windows Server Part 1
- Offline Root CA
Today I’m glad to start our journey for Setting up an Offline Root Certificate Authority “Installing – Configuring Offline Root CA as Part of Online Issuing CA”
Installing – Configuring Subordinate CA as Online Issuing CA – Part 2
What is Root CA
A root certification authority (CA) is the top of a public key infrastructure (PKI) and generates a self-signed certificate. This means that the root CA is validating itself (self-validating). This root CA could then have subordinate CAs that effectively trust it. The subordinate CAs receive a certificate signed by the root CA, so the subordinate CAs can issue certificates that are validated by the root CA. This establishes a CA hierarchy and trust path.
If a root CA is in some way compromised (broken into, hacked, stolen, or accessed by an unauthorized or malicious person), then all of the certificates that were issued by that CA are also compromised. Since certificates are used for data protection, identification, and authorization, the compromise of a CA could compromise the security of an entire organizational network. For that reason, many organizations that run internal PKIs install their root CA offline. That is, the CA is never connected to the company network, which makes the root CA an offline root CA. Make sure that you keep all CAs in secure areas with limited access.
To ensure the reliability of your CA infrastructure, specify that any root and non-issuing intermediate CAs must be offline. A non-issuing CA is one that is not expected to provide certificates to client computers, network devices, and so on. This minimizes the risk of the CA private keys becoming compromised, which would in turn compromise all the certificates that were issued by the CA.
Certificate Authority Purpose
As mentioned in Microsoft Certification Authority Guidance, the best practices for implementing a good PKI hierarchy design should contains an Offline Root CA and two or more-tier of online enterprise subordinate CA.
For my needs I will install my own CA, so I can use it to issue any number of certificates to support for the following Servers and Services with free charge.
- RD Gateway
- Lync (Skype for Business) Servers Internal Access
- Lync (Skype for Business) Servers External Access
- Web Server
- Web Services
- SharePoint https access
- Office WebApp
- Others …
This CA removes the cost required to buy a dozen of certificates to support those services
Before I start let’s know what is Certification Authority (CA) and what is the CA main purposes?
Certificate Authority (CA) is well-designed and highly trusted service in an enterprise that is trusted to sign digital certificates. CA verifies identity and legitimacy of company or individual that requested a certificate and if the verification is successful, CA issues signed certificate.
The main purposes of the CA are
- Issue certificates
- Revoke certificates
- Publish AIA and CRL information
By doing this, the CA ensures that users, services, and computers are issued certificates that always valid and validated. Before start let`s discuss this diagram 🙂
Enterprise PKI Design
Being diligent, I sketch out what we are about to do first.
My Servers Information
|RootCA||Windows Server 2012||Standalone Offline Root CA||Workgroup|
|IssuingCA1001||Windows Server 2012||Enterprise Subordinate CA||Domain Joined|
|DC01||Windows Server 2012||Domain Controller||NAN|
- DC01 – an active directory domain controller called msallal.com which connected to several machines and will be the central point for distributing the certificates over domain joined machine
- ROOTCA – Standalone offline Root CA which will generate the private key and trust the Issuing CA to generate a certificate after that it will be kept offline for the next 5 years to renew the trust with IssuingCA1001. A Root CA is special in that it`s certificate is self-issued. This mean that the certificate’s issuer name and subject field contain the same distinguished name
- IssuingCA1001 – is an Enterprise Subordinate CA which will issue and revoke the certificates as needed.
Phase 1: Enterprise PKI Deployment – Offline CA
For this scenario I will implement a 2 tier PKI hierarchy which contains offline standard Root CA server and online enterprise subordinate CA.
Prepare your servers with latest update and enforce your organization policy, let`s go…
- on the ROOTCA server, click Add roles and features… Next – Next – Next – select Active Directory Certificate Services
Make sure Certification Authority is selected
- You can configure the AD CS form here or from the server manager
- Run this command to map the Namespace of Active Directory to an Offline CA’s Registry Configuration
certutil -setreg ca\DSConfigDN "CN=Configuration,DC=corp,DC=msallal,DC=local"certutil -setreg ca\DSDomainDN “DC=corp,DC=msallal,DC=local”
Configure the CRL and AIA for Root CA
The default CRL and AIA location need to be changed to a place where all the locations need to be accessible by the sub CA server, in my case is IssuingCA1001 server
Add a new CRL Distribution Point (CDP) to the new CA server:http://Isssuing1001/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
tick the following options, and click Apply:
- Include in the CDP extensions of issued certificates
The reason why we only have two location for the offline Root CA is because since this server is not domain joint and the best practice for location settings is always using HTTP
the same way for AIA, Remove all of the AIA locations, except the local AIA distribution pointAdd a new AIA to the new CA server:http://Isssuing1001/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt
Click Apply (Restart AD CS service) then OK
Change the CRL publish intervalthe CRL publish interval is very important, once the CRL is expired, you will need to bring up the offline root CA server and republish the CRL to sub-CA server again.The default interval is one week, we don`t need to bring the offline server back online every single week.
just change the interval to 5 years and this will leave the root CA server offline for 5 years, the same as private key validityYou can always bring the server online anytime and manually re-publish the CRL if we need to revoke the sub CA certificate.
!!! Very Important StepFor the time being there is no IssuingCA1001 Server yet, so create folder on RootCA c: drive called ROOTCA and store the certs file certsrv\CertEnroll. we will back to this files later
Now we should prepare the Issuing CA as a Subordinate CA and make the ROOT CA trust the issuing CA as a part of hierarchy, check part 2 Configuring Online Subordinate CA
Awesome, done for now.
At this moment, we have deployed and configured an Offline Root CA…
Next, check the part 2 to Enterprise PKI with the 2 tier hierarchy – Offline Root CA and Online Subordinate CA – Step by Step – Part 2