Thursday, 8 January 2015

Implementing a two-tier Active Directory Certificate Services (AD CS) infrastructure on Windows Server 2012 R2

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.



No comments:

Post a Comment

Comments system

Disqus Shortname