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....
Click Add
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)
Click Add
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
http://revocation.ryanbetts.co.uk/crl/CAName.crt
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.