When AD CS is deployed in a two tier fashion
there is a “Standalone Root” certificate authority that is not part of the
domain. This server is used to issue a root certificate to an online issuing CA
which is part of the Active Directory domain. The Root CA is usually turned off
or disabled once the initial certificate has been issued and imported into the
issuing CA, this increases security as the private key for the original Root
Certificate is not available, therefore mitigating the risk of the trust chain
being breeched.
As the issuing CA uses the Root CA
certificate to sign all the subordinate certificates, if the private key for
the original Root CA certificate is compromised the entire trust chain would be
vulnerable and effectively all certificates would be untrusted. Therefore
taking the Root CA offline entirely mitigates against this. The Root CA will
only be required again when the CRL requires digital signing, or when the
original Root CA certificate needs renewed.
GPO’s will be configured to auto enroll
domain joined computers and users with trusted digital certificates. In
addition to this any services, such as IIS websites will be able to request SSL
certificates from the AD CS infrastructure. The AD CS CRL will be published
both internally and externally to allow certificate validity checking
automatically, from within the domain or from the public internet. CRL’s are
complete, digitally signed lists of revoked certificates that are published to
an IIS website to allow clients to check if their certificates are valid before
authenticating various services.
Although all certificates are issues with a
validity period, in some cases certificates must be revoked immediately for a
number of reasons such as a device being lost or compromised. In this case
revoked certificates are added to the CRL and when a client looks up the CRL to
check its validity if the thumb print of the certificate is listed in the CRL a
connection will not be granted to that user or computer. In the case of SSL
certificates for Web Services a certificate warning is disabled to users
accessing websites or service if the associated certificate has expired or has
been revoked.
The Issuing CA will also host the CRL
therefore the appropriate external NAT rules will be configured to present the
IIS Virtual Directory hosting the CRL to the public internet.
Although setting up a two-tier AD CS infrastructure is
fairly straight forward there is 1001 steps to get it working therefore I have decided to write this post so that I can refer
back to it when I need to do it next. The scenario is straight forward, there
is an offline root CA and an online issuing CA. The Certificate Revocation
Lists are published as an IIS website on the issuing CA, in addition to this I
have configured the Online Certificate Services Responder (OCSP).
I have provisioned two Windows Server 2012 R2 Standard
servers, the first step is to get the Certificate Services role installed on
the offline CA. You can use the following PowerShell command;
Add-WindowsFeature ADCS-Cert-Authority
–IncludeManagementTools
|
Alternatively you can use the Server Manager GUI.
Once it is installed there will be a prompt inside Server
Manager stating that the AD CS role requires configuring. Click the link. On
the Credentials screen click next, as the offline CA should not be part of the
Active Directory domain you will notice the credentials are listed as the local
Administrators for that server. Click Next.
As this server is only the offline CA, the only role service
that is required is the Certificate Authority.
Again as this server is not a member of the domain the only
chose here is to configure it as a Standalone CA, click Next.
Select Root CA and click Next.
Ensure that the Create a new Private Key option is selected
and click Next.
For maximum security I always change the hashing algorithm
to SHA256 and the Key Length to 4096.
Do not alter any of the CA Name fields, the Distinguished
name suffix is not populated on purpose, the issuing CA will automatically
publish it’s own AD DN in this field, click Next.
The amount of time you configure for the certificate to be
valid is entirely up to you, as this is the root CA certificate I have chosen
10 years. Please remember when this certificate expires all of the certificates
that use this in the trust chain must be reissued. Do not make this something
like 5 days……..
Keep
the database locations at their default click Next.
Review the settings and click Configure.
The next step is to configure the CRL and AIA info, open up
the Certificate Authority on the offline CA and right click on the OFFLINECA-CA
and select Properties. From the Properties window click on the Extensions tab.
Click Add and configure a new location to point to your
issuing CA in my example the full path is
http://issuing-ca.company.com/CertData/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
|
You would change this to the FQDN of your issuing CA in your
domain. Please note the /CertData folder is a folder we will create in the
wwwroot folder on the issuing CA in a future step. It is important that the
extension is .crl
Ensure the Include in CRL’s Client use this to find Delta
CRL locations and Include in the CDP extension of issued certificates options
are selected and click Apply. Then from the Select Extension drop down select AIA
then click Add.
Do the same again for AIA but use the following syntax
http://issuing-ca.company.com/CertData/<ServerDNSName>_<CaName><CertificateName>.crt
|
It is important to note that the file extension on the AIA configuration
is .crt and not .crl like on the CDP configuration screens.
Click Apply.
You will be prompted to restart the Active Directory
Certificate Services, click Yes.
Now return to the Certificate Authority console on the root
CA and right click on the Revoked Certificates folder and select All Tasks and
then Publish.
Select the New CRL option and click OK, this will generate
the required .crl and .crt files and drop them into the
C:\Windows\System32\CertSrv\CertEnroll folder by default.
Again from the Certificate Authority console right click on
the root CA and select Properties.
Click on the General tab and then View Certificate.
On the certificate properties window click on the Details
tab and click on Copy to File…
Follow the Certificate Export Wizard remembering to choose
DER Encoded Binary x.509 (.CER).
You must specify a location to export the certificate I
always use the same path as the CRL’s as all of these files need copied to the
issuing CA.
The Root CA certificate will have been exported into the
chosen output folder.
Now move across to the Active Directory joined issuing CA
and copy the all three of the files from the offline CA to somewhere accessible
on your network, they should be like shown below.
Now open the Group Policy Management console from a Domain
Controller, expand domains and right click on your domain and select Create New
GPO and Link it Here. Obviously if you have other GPO’s in place you can just
add these settings to one of them. When you have selected the GPO you are going
to use Edit it.
In the GPO Editor, expand Computer Configuration/Windows
Settings/Security Settings/Public Key Policies right click on Trusted Root Certification
Authorities and select Import.
From the this window you must point to the Root CA
certificate, this is the file we just exported and not the .crl or .crt files.
Click OK and the Root CA certificate should be configured to
be deployed via that GPO. This is required because the offline CA is not a
member of the domain therefore cannot self-publish information about itself.
The offline CA is now configured the next phases is to
install the AD CS role on to the issuing CA and then configure the role.
Click Certificate Authority.
As this is the issuing CA select Enterprise CA. In AD CS for
a server to become an Enterprise CA it must be part of a domain.
Most issuing CA’s are Subordinate CA’s as there is a
certificate authority server above them in the trust chain.
Create a New Private Key.
Set
the algorithm and key length to SHA256 and 4096.
The values in the CA Name fields should auto-populate, you
will notice the DN field has a domain value where the offline CA did not.
Select Save a Certificate Request File on Target Machine.
Leave the CA Database locations at their defaults.
Click Configure.
You will receive the following warning, this is because the
issuing CA has not be issued a valid certificate from the Root CA after the
certificate request was generated. This is soon to be resolved.
A certificate REQ file will then appear in the folder in
which you configured using Browse. You must copy this file to your offline CA
so that it can generate a certificate based on the request file.
When you have the REQ file on the offline CA open the
Certification Authority console and right click on the sever and select All
Tasks and Submit new request…
Browse to the REQ file you have just copied from the issuing
CA.
Then from the Certification Authority on the offline CA
click on Pending Requests, at this stage there should only be one request
pending. Right click on it and select All Tasks then Issue.
All going well the CA should issue the certificate and you
should be able to see it under Issued Certificates.
We must then export this certificate from the Root CA and
import it into the issuing CA, you do this by double clicking on the
certificate from the Issued Certificates pane. From the Details tab you can
then use the Copy to File… option.
When you export the certificate ensure you change the Export
File Format to Cryptographic Message Syntax Standard – PKCS 7 Certificate
(.P7B)
Point it to a suitable location to generate the file.
Now copy that newly generate file onto the issuing CA.
You must now install the IIS (Web Server) role on the
issuing CA to host the CRL’s, you can do this from Server Manager.
Once IIS is installed on the root of C:\ there will be a
folder called inetpub, from inside that folder go into the wwwroot folder. From
inside here right click and create a New Folder, if you copied the syntax when
configuring the CRL info, ensure the folder is called CertData. Copy both the
.crl and .crt files that were generated by the offline CA into this folder.
Now open the Certificate Authority console on the issuing CA
and right click on the server object and select All Tasks and Install CA
Certificate…
Browse to the Cert file that was generated by the offline CA
from the REQ file and click Open.
You will receive the following error, this is normal
therefore click OK.
Right click on the issuing CA once more and select All Tasks
and then Start Service.
Provided you have configured everything correctly the
issuing CA should report no further errors and it should become operational.
One more set of step is optional, but recommended. Return to
Server Manager on the issuing CA and install the Online Responder role service.
Return to the CA console and click Certificate Templates
right click inside the pane and select Manage.
Scroll down and find the OCSP Response Signing template,
right click on it and select Properties.
Click on the Security tab and select Authenticated Users and
ensure they have Full Control, you would perhaps give this more thought in your
production environment. Click OK and Apply.
Return back to the Certificate Template pane and right
click, select New and then Certificate Template to Issue.
Choose the OCSP Response Signing from the list and click OK.
Once you have installed the OCSP role service you should see
an icon to launch the MMC console, when you do right click on Revocation
Configuration and select Add Revocation Configuration.
The name is not important here.
Ensure Select a Certificate for an Existing Enterprise CA is
select and click Next.
Click Browse CA certificates published in Active Directory,
click double click on the issuing CA from the list.
If you have configured the permissions on the OCSP template
correctly it should auto-detect you want to auto-enroll using that certificate.
Click Provider...
Then click Add and input the FQDN to your CRL if you have followed this guide from the beginning it will be at the same path as mine, simply change the FQDN of your issuing CA.
http://issuing-ca.company.com/CertData/OFFLINECA-CA.crl
|
Click OK.
If you have configured everything correctly the Online Responder Configuration should report a state of Working.
