Security

Enterprise PKI with the 2 tier hierarchy – Offline Root CA and Online Subordinate CA – Step by Step – Part 1

5 Mins read
  • 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.

CA Compromise


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.

  • VPN
  • 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
  • DirectAccess
  • 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

Server NameOSRoleWorkgroup/Domain
RootCAWindows Server 2012Standalone Offline Root CAWorkgroup
IssuingCA1001Windows Server 2012Enterprise Subordinate CADomain Joined
DC01Windows Server 2012Domain ControllerNAN
Certificate Authority Serers List
  • 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…

Installation

  • on the ROOTCA server, click Add roles and features… Next – Next  – Next – select Active Directory Certificate Services 
  • Next

Next

Make sure Certification Authority is selected

Install

Configuration

  • You can configure the AD CS form here or from the server manager

ROOTCA should not be a domain joined, Local Administrator required


As mentioned above “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”


Choose 5 years, so after trusting the sub CA, it will be kept offline for the next 5 years

  • 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  

Remove all of the CRL distribution point locations, except the local CRL distribution point


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
AIA
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.
Click OK

Publish the CRL


!!! 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

Subordinate CA

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

Conclusion

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


Thanks


Related posts
Security

Enterprise PKI with the 2 tier hierarchy - Offline Root CA and Online Subordinate CA - Step by Step - Part 2

4 Mins read
Today I’m glad to continue our journey for Setup an Enterprise Subordinate Certificate Authority deployment “Installing – Configuring Subordinate CA as Online…

1 Comment

Leave a Reply to Jack hann Cancel reply

Your email address will not be published. Required fields are marked *

×
Security

Enterprise PKI with the 2 tier hierarchy - Offline Root CA and Online Subordinate CA - Step by Step - Part 2