Difference between revisions of "Certificate Services General Notes"

Revision as of 03:10, 28 May 2015

Overview

By enabling Active Directory Certificate Services you create a private SSL/TLS Root Certificate Authority (CA) for your organization. This is useful for certificate signing for internal hosts such as Web Servers or workstation certificates for use with SCCM.

Best Practices

For security reasons you want to create a 2 tiered CA structure. You start by creating a standalone Root CA. Then you create a subordinate CA that is Active Directory integrated.

Root CA

The Root CA needs to be protected, if an attacker were to obtain control over the Root CA, they could use it to issue certificates that could grant them access to an entire organization. This CA doesn't need to do much. it needs to create a cert for itself, and certs for the subordinate CA, and it needs to create a Certificate Revocation List (CRL) periodically. If setup properly the Root CA will issue a small number of certificates with lengthy expiration dates. This allows for the Root CA to be turned off and network disconnected (the ultimate security measure) except for the periodic publication of new CRL's. Root CA's that operate in this fashion are referred to as "Offline" Root CA's.

Subordinate CA

Subordinate CA's are allowed sign certificate requests (CSR) on behalf of the Root CA. Subordinate CA's can be integrated into Active Directory so that other AD objects can participate in certificate auto-enrollment. Subordinate CA's are less of a security threat because if they are compromised, you can revoke their certificate and create new Subordinate CA's. Subordinate CA's should still be secured though!

Certificate Revocation Lists

The CA's need to publish a CRL periodically otherwise you will get certificate errors. In the case of AD integrated Subordinate CA's thats handled automatically (the CRL's are stored in Active Directory). Offline Root CA's shouldn't be joined to a domain and are intended to be offline, so you can't publish their CRL to AD or their internal web server. So typically you would manually publish the CRL, copy it to a location on the subordinate CA via a USB drive. This allows for the Root CA CRL to be accessible by clients.

CRL Publication Locations

On the Offline Root CA, you need to modify the CRL Distribution Points. By default the CA is configured to use its local HTTP server for CRL distribution. Its also configured to use the wrong LDAP location. You should add new CDP locations that correspond to the Subordinate CA's HTTP server and the LDAP path to the Active Directory the Subordinate CA is integrated with.

Offline CRL Publishing

You can create a new CRL on the Offline Root CA by opening certsrv.msc, and right clicking on "Revoked Certificates" -> "All Tasks" -> "Publish" This will create a .CRL file in:

%systemroot%\system32\certsrv\certenroll

Copy the CRL to a thumbdrive and move it to the Subordinate CA's certdata folder:

%systemdrive%\inetpub\wwwroot\Certdata

certutil -dspublish"<RootCA.crl>" ldap:///CN=<Root CA name>,CN=<Subordinate CA hostname>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=<contoso>,DC=<com>?certificateRevocationList?base?objectClass=cRLDistributionPoint

or if the CDP's are setup correctly on the Root CA, you can shorthand it like this:
certutil -f -dspublish %systemdrive%\Inetpub\wwwroot\certdata\RootCA.crl

References

http://itcalls.blogspot.com/2013/08/how-to-publish-new-certificate.html

https://technet.microsoft.com/en-us/library/dd299871(v=ws.10).aspx