Active Directory Certificate Services is Microsoft implementation of a Public Key Infrastructure, which allows enterprise organisation to deploy digital certificates to secure internal corporate services.
This is an update version of my post from 2015
In this example I'm going to deploy two AD CS servers in a two-tier fashion with a Root CA and an Online CA, the Root CA will only be used to issue a single certificate to the Online CA. The Root CA is then taken offline once this certificate has been issued, this increases the security posture of the PKI. The idea being, that if the Root CA is offline it cannot be comprised, meaning the PKI trust chain cannot be compromised.
- CA1 is a non-domain joined server which is going to become an offline root certificate authority.
- CA2 is a domain joined server which is going to be the Certificate Authority for my AD domain along with the CRL point for both CA servers.
- CA2 is also going to host the OCSP component of AD CS to streamline certificate revocation requests.
The following bullet points cover, at a high level the work flow on how this AD CS infrastructure is going to work. The most important thing to understand is how certificate revocation works, without proper certificate revocation the validity of your digital certificates cannot be checked.
- CA1 is configured with CRL paths to both for C:\ and HTTP
- CA1 is configured to use CRL paths which reside on CA1 served via HTTP
- CA2 generates a CSR for a new root certificate
- CA1 issues the certificate based on the CSR, cert is installed
- CA1's root certificate is installed on CA2
- CA2 checks the validity of the certificate using the CRL paths published in the certificate
At this point in the process, there is a trusted certificate installed on CA2 which has been issued by CA1. However, certificate revocation would likely fail unless the CRL for CA1 was somehow accessible to CA2. I cover how to do this further down.
- CA2 is configured with CRL paths for both HTTP and LDAP, including the OCSP path for certificate it issues.
- CA2 is configured to use CRL paths which reside on CA2 served via HTTP
- CA2 issues certificates with CRL and OCSP paths which point to http://revocation.ryanbetts.co.uk/crl and http://revocation.ryanbetts.co.uk/ocsp
- CA2 issued certificates also have CRL paths published to AD over LDAP.
Configuring the Certificate Authority Servers
Install and Configure the Certificate Authority Role on CA1.
Use the GUI to install the Certification Authority role on CA1.
Select Standalone CA.
Select Root CA.
Choose to Create a New Private Key.
Choose to set your key length to a minimum of 2048.
You can extend the root CA length if you like 5 years is long enough.
After you complete the wizard you are left with a functioning standalone CA.
· Certification Authority
· Online Responder
Choose Enterprise CA, this option will only be available if this CA server is domain joined, we want CA2 to be domain joined.
It's not going to be the top of the trust chain so select Subordinate CA. Subordinate CA only means that this CA is not the highest in the trust chain, in otherwords there is another CA above it in the trust chain.
Create a New Private Key.
Again ensure the key length is set to a minimum of 2048.
Do not alter any of the CA attributes below.
Take now of the path below, this is the CSR that CA2 is creating. This will be needed to generate a new certificate on CA1.
Configuring the Revocation Websites in IIS
Once the wizard of installing and configuring the CA is complete open up IIS which will have been installed for you. Expand the Default Website and create a new Application.
I like to call this /crl and point it to the physical path on your server I have used C:\inetpub\wwwroot\crl - please note I had to create the /crl folder.
Create your CRL application and your IIS installation should look like this, for testing it’s a good idea to enable Directory Browsing on the CRL application.
Logon to one of your DNS servers and create a new A record in your domain forward lookup zone. This DNS service name is going to be used in the CRL and OCSP paths when we configure CA2.
I use the service name revocation.ryanbetts.co.uk for my certificate revocation. This should point to CA2 in this example as this server will host the CRL and the OCSP.
Now return to CA1, the step above is important so make sure you do it correctly.
Configuring CA1's Certificate Revocation CRL Paths
Configuring CA1's Certificate Revocation CRL Paths
Right click on the Properties of CA1 and go to the Extensions tab.
Delete all the default entries until you are left with only C:\Windows\system32....
Select Include in CRL's, Include in the CDP Extension, Include in the IDP etc.
Click Apply and the AD CS service will restart.
From the same pane use the drop down and select Authority Information Access (AIA)
Remove all the paths except C:\Windows and ldap://
Ensure you select Include in the AIA extension of issued certificates
Again click Apply and AD CS will restart.
At this point we have CA1 configured to issue certificates, in our example CA1 will only ever issue a single certificate to CA2. The details above are setting the CRL paths which will be published into any certificates issued by CA1. Without these paths CA2 would not be able to validate certificates issued by CA1.
Remain on CA1, now we need to complete the CSR generated on CA2.
Go to All Tasks and Submit New Request.
You might need to copy the CSR from the C:\ on CA2 so that it's available on CA1.
Once done, go to Pending Certificates, find the certificate, right click and select Issue.
Go to Issued Certificates and open the Properties and Details of the certificate.
Click Copy to File, run through the wizard and export the certificate to the Desktop.
Now we need to copy the following files from CA1 to CA2 to the respective locations.
- CA1's CRL and CRT files which are at C:\Windows\System32\CertSrv\CertEnroll
- copy these to CA2 C:\inetpub\wwwroot\crl
- CA1's root certificate copy and install this on CA2. - we export in a couple of steps!
- CA1's certificate issued to CA2 based on the CSR.
Once the CRL and CRL files are copied to CA2 C:\inetpub\wwwroot\crl they will be accessible over HTTP using our IIS website.
The CRT file must be renamed to so that both files have the same name. In other words the CRT file must be named <CAName> as shown below, this is because we configured the path to use <CAName>.crt.
It should look something like this, the root of your IIS application should have a .CRT and .CRL file both from CA1, they must be labelled correctly or validation will fail.
To test these files are accessible over HTTP open a browser and go to http://revocation.ryanbetts.co.uk/crl
Exporting the Root CA (CA1) Certificate
Now we must export the CA1 root certificate and install it on CA2, open the Properties and double click the Certificate #0 go to Details and Copy to File.
Dump this out to the Desktop along with the CA2 certificate.
The two certificate files now need copied over to CA2.
Now open Certificate Authority on CA2 and go to All Tasks and Install CA Certificate.
From CA2 open C:\Windows\System32\CertSrv\CertEnroll, these files need copied to the IIS virtual directory folder so they can be accessed over HTTP. Copy these files to C:\inetpub\wwwroot\crl
Return to CA2 and install the Root Certificate first, ensure this is installed under the Local Computer under the Trusted Root Certification Authorities store.
Browse for the other certificate copied from CA1.
Refresh and the CA should become active. If you have made a mistake at this point it's probably due to the location of your CRL/CRT files. If the CA cannot access them in the paths you provided validation will fail.
To double check validation we can open the root issued CA cert on CA2 and look under Details and you will see CRL Distribution Point, please note that http://revocation.ryanbetts.co.uk/crl is listed as the path.
Another good way to check the overall health of the AD CS is to use pkiview.msc
Configuring Certificate Revocation (CRL) and OCSP Paths for CA2
It will report any issues it finds with the deployment.
On CA2 open up the Properties from the Certificate Authority MMC. Select AIA from the drop down and add the following
http://revocation.ryanbetts.co.uk/ocsp and ensure to tick Include in the Online Certificate OCSP extension.
Add another which points to
Click Apply to retain they changes.
Select CDP from the drop down and use Add.
Add a new point which points to http://revocation.ryanbetts.co.uk/crl/CAName.crl
Ensure all the option to Include are selected.
The wwwroot\crl folder should look like this with two sets of CRL/CRT’s. One pair from both CA1 and CA2.
Now if you refresh pkiview.msc it will be reporting an issue with the OCSP location, this is because we have not configured the OCSP yet.
Configuring the OCSP Service
We need to copy and apply permissions to the OCSP Repsonse Signing certificate template before we can configure the OCSP. Right click on it and select Duplicate Template.
Click on the General tab and rename the template something descriptive.
Click on Security and add the computer object to the ACL, this should be the computer object of the server which is going to host the OCSP role, in this case that is CA2.
Ensure the object has the Read and Enroll permissions. Click Ok.
Close the Certificate Template management window and return to the CA, right click on the Certificate Template folder and select New > Certificate Template to Issue.
Now open the OCSP MMC (if it’s not there you probably never installed it), right click and select Add Revocation Configuration.
Name it something descriptive.
Select to use an Existing Enteprise CA.
Select Browse CA Certificate Published in AD, click Browse, then Next.
If the OCSP template has been configured correctly the wizard should detect it.
If you return to pkiview.msc and it still reports a OCSP Error #1 you might need to renew the CA Exchange certificate, to do this open Issued Certificates on CA2 and find the latest CA Exchange certificate, you can search using the Certificate Template column.
Right click it and select Revoke.
Open an admin CMD and type certutil -cainfo xchg
Return to pkiview.msc and refresh the report and the issue with the OCSP should disappear.
Configuring Certificate Distribution with GPO's
We now need to distribute the root certificates to the domain devices, open Group Policy Management, create a new GPO and scope it to the correct place.
Edit the GPO and go to Computer > Polices > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
Right click and select Import, select both the root certificate for CA1 and CA2 so that the entire chain of certificate is trusted.
We can also put an additional setting in to auto enroll computers with device authentication certificates.
Perform a GPUPDATE /force and you will notice the root certificates from CA1 and CA2 have been automatically installed on devices which are scoped to the GPO.
If you have followed all the steps correctly you now have a fully functioning PKI infrastructure.