This is part 4 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 Enterprise 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, so again we're going to increase the certificate lifetime from the CA.

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

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

Build the PKI Publication Point

Our next step is to decide where clients will access our CRLs and the AIA. As before, 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 existing website http://www.goocorp.com/pki/ - we used this as the base URL for all our root CA publishing duties, and we'll keep it consistent. Your own organisation might want to separate the root CA publishing point from the Enterprise CA publishing point; in that case you'll need to build your web site or filesystem appropriately.

Setting CRL Lifetimes

Our Enterprise CA will issue CRLs for us, but the default lifetime will be too short (given we'll rarely 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 Enterprise CA's Revoked Certificates properties dialog shows a CRL lifetime of 3 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.

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 Enterprise CA can automatically publish CRLs for us, but only to the Active Directory. It builds the list of revoked private keys into the CRL and then signs the CRL with its own private key.

In line with our sample PKI Publication Point, our URL to the Enterprise CA's CRL is going to be http://www.goocorp.com/pki/entca01.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.

Local paths (like C:\CAConfig\EntCA01.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 Enterprise 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) for a certificate 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 Enterprise CA's AIA is going to be http://www.goocorp.com/pki/entca01.crt.

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

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 5 we'll cover ongoing maintenance.