In this guide I will show you how to set up and configure two tier PKI hierarchy, meaning one standalone Root CA and one Subordinate CA.

As we all know, or should know, setting up a standalone Root CA with a subordinate issuing CA is best practice. Actually you could have three or four subordinate CA without any issues, the principal is still the same when it comes to the configuration. All you might need to do extra is to publish the CDP and AIA to all subordinate CA servers.

The configuration I’m going to use is based on four servers:

• One DC – Server 2012 R2, joined to the domain, running AD DS
• One Root CA – Server 2012 R2, not joined to the domain
• One Sub CA – Server 2012 R2, joined to the domain
• One IIS server – Server 2012 R2, joined to the domain, running IIS for publishing

 

Install and configure the Root CA

The first server that we will configure is the standalone root CA. Once the root certificate and the enterprise certificate for the subordinate CA have been issued and the CDP and AIA is in place, this server will be shutdown. The only time we need to start it again is if we need to revoke the certificates for the subordinate CA servers, renew the root certificate or add a new subordinate CA.

So on our root CA, add the “Active Directory Certificate Services” role and the other required features.

 

Accept the default features and on “Features” and on “Role Services”

 

When the installation has completed, click on:
“Configure Active Directory Certificate Services on the destination server”, to start the configuration wizard.

 

 

On the first page, make sure that the account that you are using is local administrator on the server.

 

On setup type, we chose to install a Standalone CA

 

The type of CA that we need to install is a Root CA.

 

Next, chose to create a new private key.

On the next page, accept the default values. You could increase the length of the key to increase security, but some applications and features does not support longer keys than 2048.
Edit the common name for the server if needed on the next page, or accept the default values.

On the page called “Validity Period”, enter 20 years. Right now, this setting will not do anything more than setting a value in the registry. Further down in this guide I will explain what more that needs to be done before it will actually be 20 years.

Then click “Next” twice and the “Configure” to setup your standalone Root CA. (The image bellow is a sample of my configuration, used in an environment for test)

 

Remember the value of 20 years that we set for the validity period earlier? Well, even if you type 300 in that box, the time would still be just 5 years. This is not a bug or anything, it’s by design. To make this setting you need to edit one key in the registry called “ValidityPeriodUnits”, located in HKLM\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\<ROOT_CA>\

 

Also, for extra functions, you could create a file named “CAPolicy.inf” and place it in your %systemroot% (Default C:\Windows). This file should contain the following information.

[Version]
Signature = "$Windows NT$"

[certsrv_server]
RenewalValidityPeriodUnits = 20
RenewalValidityPeriod = years
RenewalKeyLength = 2048

Next step is to map the Namespace of the Active Directory to the Offline Root CA. In an elevated command prompt, run the following two commands, replacing the “DC” to match your setup.

• certutil.exe -setreg ca\DSConfigDN CN=Configuration,DC=config,DC=local
• certutil.exe -setreg ca\DSDomainDN “DC=config,DC=local”

Configuring CDP and AIA

Next we need to update the CDP and AIA locations informtion with a location that is accessible by all future Subordinate CAs. This is because this Root CA will be shut down when the new sub CA is in place. In my case, this will be on the IIS server.

Start with opening up MMC.exe on the root CA and add the certificate authority snap-in. Then right-click on the CA and select “Properties”

 

Under the tab called “Extensions”, remove all entries EXCEPT the local entry for both CDP and AIA.
Then add the path to the new place where they should be published and what the name of the file should be, in my case it will be (For CDP):

• http://iis01/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

When done, it should look like this:

For AIA, it is the same principal, my location will be the following:

• http://iis01/CertEnroll/<ServerDNSName>_<CAName><CertificateName>.crt

And it should look like this when completed:

When completed, click on “Apply” and restart the service to make the changes take effect.

This step is one of the most important steps. We need to change how often the Root CA should publish the CRL. Default value is a week and I for one don’t want to boot up the server once a week to publish 🙂
To change this, right click on “Revoked Certificates” and select properties, then changes the value to 20 years and click on “OK”.

Now we need to publish the CRL. Right click on “Revoked Certificates”, point to “All Tasks” and click on “Publish”.

 

For now, we are done on the Root CA and we will start to install and configure our Subordinate CA.

Install and configure Subordinate CA

Now that we have our Root CA in place, we need a subordinate CA that can issue certificates to our future clients and servers. On our subordinate CA, in my case CA01, we need to install the “Active Directory Certificate Services” role. The same as earlier, but we also need to add the “Certificate Authority Web Enrollment” role.

 

When configuring our Subordinate CA, select to configure both features.

 

Choose to install an Enterprise CA and on the next page, select Subordinate CA.

Next, select to create a new key and accept the default settings for cryptography, unless you changed these on your Root CA. Under CA Name, change the name if needed and verify that the DN is correct.

 

Since we do not have a Root CA that is joined to the domain, we need to save the request file and manually request a new certificate for our Subordinate CA. Note the location of this file for later use.

Then click on “Next” twice and under “Confirmation”, click on “Configure”.

Before we can do anything else, we need to copy the CRL and AIA from our Root CA to the same place on our Subordinate CA. Sine the Root CA is not joined to the domain, this is not done by default. The files we need to copy are located under C:\Windows\System32\CertSrv\CertEnroll. Copy these two files to the same location on our Sub CA.

We also need to install the root-certificate on our Subordinate CA. (Failing to do so will result in a broken chain). I prefer to export the certificate and add it manually to my Sub CA and then create a GPO that will install it on all domain joined machines.
To get the *.cer file, on the Root CA, right click on the name in Certification Authority and click on “Properties”. On the “General” tab, click on “View Certificate” and export it to a file, using DER encryption. Then install it on the Sub CA.

Now, to issue  certificate our subordinate CA, copy the file created to the Root CA and click on “Submit New Request”, choosing the file you just copied and then issue the certificate.

Next, open the certificate under “Issued Certificates” and under the details tab, click on “Copy to file”, copying it to a *.P7B file.

Now we need to install the CA certificate, so copy the *.P7B file you just created to the Subordinate CA, then in the Certification Authority, right click on the CA, point to “All Tasks” and click on “Install CA Certificate”.

 

After a few seconds, you should see that the Subordinate CA has started.

 

If the CA fails to start, try to right click on the CA, point to “All Tasks” and click on “Start Service”. Some times, this isn’t done automatically.

Now we are almost finished with our two tier PKI setup. The only thing left to do, is to add the CDP and AIA extensions on our Subordinate CA. Remember to add the IIS location as well!

When this is done, start the pkiview.msc on the Subordinate CA to verify that everything is in order.

 

Now it’s just to shutdown the Root CA and wait for another 20 years before it needs to be booted up again, unless, you need to add a new Subordinate CA or create a new root certificate, something that I will show you how to do in a later post!