Enterprise PKI with Windows Server 2012 R2 Active Directory Certificate Services (Part 2 of 2)

Artikel
10/22/2013

[Part 1 for Steps 1 to 4]

5. Set certificate revocation policies

Revocation is an important part of PKI to ensure the validity of certificates. There are two components to make the process work. A list, or more specifically Certified Revocation List (CRL), as the criteria to identify an invalid certificate needs to be published and distributed. And an Online Responder to make revocation checking data available to client.

For configuring the distribution of CRL, the properties of Revoked Certificates folder of CA console is where the CRL parameters are. On the subordinate CA, the CRL settings are shown as the following.

The CRL is published to designated Certificate Revocation Location (CRL) when setting up the root CA server earlier. And in this case, it is place in a folder under wwwroot at https://subCA.yc.corp/certdata/ as shown below. The directory browsing is here turned on for listing out the content in the certdata folder.

Next, the Online Responder service is a role service to the AD CS role and makes certificate revocation checking data accessible to clients. On the subordinate CA server, one can use Server Manager to add the service as shown below.

Once Online Responder is configured, use the CA console to examine the subordinate CA’s properties. Click the Extensions tab and add a new AIA distribution location to https://subCA.yc.corp/ocsp.

Next configure the OCSP Response singing certificate template and enable Authenticated Users to enroll by following the process below.

Then publish/enable the template as illustrated below.

Open the Online Responder console, add revocation configuration of the subordinate CA, and enroll for an OCSP Response certificate as depicted by the following screen flow.

At this time, certificate revocation settings are in place.

6. Configure and verify private key archive and recovery

Recovering a private key is a process that needs to be well tested and documented accordingly. The process includes assigning a certificate for a recover agent, i.e. a certificate administrator, and enable specific certificate template to allow archiving a private key. These are the main tasks:

(a) Configure CA to issue Key Recovery Agent (KRA) certificate
(b) Request KRA certificate
(c) Configure CA to allow key recovery
(d) Configure a template for archiving key

(a) Configure CA to issue Key Recovery Agent (KRA) certificate

On the subordinate CA, configure and enable Key Recovery Agent, and allow only domain administrators and enterprise administrators can enroll. The process and settings are as the following.

Now the KRA template is enabled.

(b) Request KRA certificate

While logging in as a domain administrator, use the Certificate snap-in on personal store in mmc to request a KRA certificate as shown below.

(c) Configure CA to allow key recovery

This is set in the properties of the CA using CA console as shown below. Notice the CA needs a restart to validate the KRA certificate.

(d) Configure a template for archiving key

This requires defining and enabling a template with Certificate Template console. Use CA console and go to Certificate Template folder to bring up Certificate Template console. Duplicate and rename the User template and set the settings as shown below. This option, Archive subject’s encryption private key, once enabled allows the KRA to retrieve the private key from a certificate store.

The verification of archiving a private key is left for the reader to carry out. :) Or I may publish it in a future blog post.

Closing Thoughts

Implementing PKI is very process-heavy and it does require effort and much concentration. The key is to keep good documentation and standardize as much as possible to minimize overhead. Once PKI is in place, Virtual Smart Card which is one of my favorite features in Windows Server 2012 R2 is just around the corner.