This is part 2 of the (Legacy) Building a CA Hierarchy series. If you're just starting, you might want to read the other parts:

Part 1. Building the Root CA
Part 2. Configuring the Root CA
Part 3. Building the Enterprise CA
Part 4. Configuring the Enterprise CA
Part Oops. How I Screwed Up

Now we need to configure the root CA to allow us to issue certificates to our Enterprise CA, publish CRLs and the AIA, and configure a PKI Publication Point.

Setting the Validity Period for Certificates

It seems unlikely to me that anyone would wish to build a high-maintenance CA hierarchy; to that end, we're going to increase the certificate lifetime from the root CA. This will permit the Enterprise CAs to issue certificates with a usable lifetime (note that a CA can never issue a certificate with a lifetime longer than the CA's own certificate).

Changing the certificate lifetime (for certificates issued to other devices and users) to 10 years on the root CA is a matter of running two command lines and restarting the CA services:

certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod Years

Build a PKI Publication Point

Our first step is to decide where clients will access our CRLs and the AIA. Clients that are part of an Active Directory domain can get a CRL or AIA from their local domain controller; but other clients might need to get the CRL and AIA from a file share or from a web server. Obviously, if you want clients to be able to check CRLs or the parent CA certificate from outside your network, an HTTP URL is the best bet, but you'll need to ensure that the same URL works both inside and outside of the network.

For the purposes of our example configuration, we'll assume that we want clients to retrieve all CRLs and the AIA from the website http://www.goocorp.com/pki/ - we'll use this as the base URL for all our CA publishing duties.

Setting CRL Lifetimes

Our root CA will issue CRLs for us, but the default lifetime will be too short (given we'll rarely issue or revoke certificates) to make administration simple. Right-clicking on the Revoked Certificates folder will show the Revoked Certificates properties dialog, in which we can set the CRL lifetime.

This snap of our production root CA's Revoked Certificates properties dialog shows a CRL lifetime of 6 months - which I personally feel is a reasonable compromise between shorter CRL lifetime (security) and longer lifetime (easier administration). Of course, there's nothing stopping you from issuing a new CRL at any time within your CRL period.

Unfortunately, the image showing this has been lost.

Configuring For CRLs

A CRL is a Certificate Revocation List - a list of the certificates that this CA has issued, and which have been revoked since their issuance. Perhaps the computer that stored the private key had a catastrophic failure, or perhaps someone managed to export the private key from the server (a step that might allow them to impersonate our secure server).

The Microsoft CA will build CRLs but as our root CA is offline, it cannot automatically publish them for us. It builds the list of revoked private keys into the CRL and then signs the CRL with its own private key.

At this point you may have realised that the CRL that the root CA publishes cannot effectively mark itself as revoked (not least because the CA must sign the CRL with its private key, which is either revoked (the old one) or unverifiable (the new one)). So now the reason for keeping the root CA offline and secured becomes clear - if it is compromised in any way, the entire hierarchy must be ripped out and replaced - never a good plan!

In line with our sample PKI Publication Point, our URL to the root CA's CRL is going to be http://www.goocorp.com/pki/rootca.crl.

The CA cannot publish directly to the URL (this is independent of whether the CA is online or not - it just can't). So apart from the URL for clients, we need a local path to which the CRL can be published.

In the picture below (the Extensions tab on the Properties dialog for the CA) you'll see the two paths I've configured for the root CA in my production hierarchy. The checkboxes below vary in availability depending on the type of path to the CRL.

Unfortunately, the image showing this has been lost.

Local paths (like C:\CAConfig\RootCA.CRL) enable the Publish options.

URLs (http://... and file://...) can be included in CRLs (so that delta CRLs can be used) and in the CDP of certificates that the CA issues (so clients can check that the server, device or user that they're talking to is still valid).

For your own configuration you'll need to set the local path, HTTP, file and LDAP paths as appropriate for your own network - your own domain, your own server names and websites, and your own filesystem paths. Check your URLs carefully - once a certificate is issued, those paths are burned into the certificate permanently.

You can publish your CRL before you issue any certificates - use the opportunity to document your own procedures for copying your CRL from the local path on your offline root CA to the online paths on your web servers or file servers, and your procedure for publishing the CRL to your Active Directory.

Configuring The AIA

The AIA (Authority Information Access) is an accessible copy of the parent CA certificate (excluding, obviously, the private key!) . Configuring the AIA is done in the same properties dialog and follows the same configuration rules:

Clients that are part of an Active Directory domain can get the AIA from their local domain controller; other clients might need to get the AIA from a file share or from a web server. Obviously, if you want clients to be able to check the AIA from outside your network, an HTTP URL is the best bet, but you'll need to ensure that the same URL works both inside and outside of the network.

In line with our sample PKI Publication Point, our URL to the root CA's AIA is going to be http://www.goocorp.com/pki/rootca.crt.

Here's our production root CA's AIA configuration.

Unfortunately, the image showing this has been lost.

You can see that unlike the CRL, there's no publishing options, only the option to include the path in the AIA extension and the OCSP extension.

Publishing the AIA is a simple matter of exporting the root CA's certificate to a file and copying it to the entered URLs. Again, this can be tested before any certificates are issued from the CA, so again, use the opportunity to document your procedures for copying your AIA to the online paths on your web servers or file servers, and your procedure for publishing the AIA to your Active Directory.

In part 3 we'll build the Enterprise CA.

In part 4 we'll configure the Enterprise CA to allow us to issue certificates, and publish the CRLs, AIA and configure CDP's.

Finally, part 5 will cover ongoing maintenance.