Deliberations from Dave

Building a CA Hierarchy: Part 3. Building the Enterprise CA

This is part 1 of the 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, with working CRLs, a CDP and the AIA configured on the root CA, we can build our Enterprise CAs.

The procedure we follow is almost identical to that for the standalone root CA. Some organisations may choose to place the Enterprise CAs on a lightly loaded host such as a domain controller; this has the advantage of minimising the number of servers required for the CA hierarchy at the expense of administrative flexibility (remember: local groups on a domain controller are common to all domain controllers).

Having built or selected our server, we'll again create the CAPolicy.INF file. Recall that this text file contains instructions to the CA components that will be used to configure the CA certificate. It's the only chance we get to provide some of the information needed to configure the CA.

The file is very simple. This example sets a 2048 bit key for the certificate, and documents that the cert should be valid for 10 years (note that the issuing CA sets the validity period):

[Version]
Signature="$Windows NT$"

[PolicyStatementExtension]
Policies=AllIssuancePolicy
Critical=False

[AllIssuancePolicy]
OID=2.5.29.32.0

[CertSrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10

Now install the Certificate Authority components. If you're issuing a lot of certificates (and you want the convenience of the web-based certificate request mechanism) go ahead and install the World Wide Web service before you add the CA components. You'll want to run the Add/Remove Windows Components tool seperately for the WWW service and the CA components to ensure the CA registers the correct virtual directory.

Again, you'll need to set your own values as you run the wizard. The following gives you some idea of what to expect:

• CA Type: Enterprise Subordinate CA (the second option); I suggest using custom settings for the key pair and CA certificate;
  
• CSP: Microsoft Strong Cryptographic Provider;
• Hash algorithm: SHA-1;
• Key length: 2048 bits (you want this as long as possible for a root certificate, especially if you plan a 25 year life!). Note that while you can specify a longer key (e.g. 8192 bits) ... calculating the key might take a surprisingly long time (5-10 seconds for a 4096 bit key and 10 minutes for 8192 bits on this 1.83GHz Core 2);
  
• Common Name: Whatever you want to publicly call this CA (probably not the computer name, possibly "Goo Corp Policy CA" or similar);
• Distinguished Name Suffix: A partial LDAP path for your organisation and department. For example, the Corporate department at Goo Corp would be: OU=Corporate,O=Goo Corp. This is optional;
  
• Validity Period: The same number of years as you specified in CAPolicy.INF (you want the certificate lifetimes to be consistent).
  

Having completed the wizard, your Enterprise CA is built. But as you went through the wizard you would have received a notice - you need to issue your subordinate CA a certificate from the offline root.

The subordinate CA setup will create the certificate request - it's your responsibility as the CA administrator to transport that request to your offline CA (remember the floppy disk earlier?), process the request and bring the issued certificate back to the enterprise CA for installation.

Processing the Request

Processing the request is simple. On the root CA, locate your certificate request from the enterprise CA; I'll assume it's located in A:\ and has the name EntCA01.req.

We run the command-line submission tool:

certreq -submit A:\EntCA01.req

This submits the request to the CA, (and prints the certificate request ID) much as the web form would do if the CA was enabled for web submission. Since this is our very first certificate from this CA, the request ID will be 2 (request 1 is the self-signed root certificate).

Now you can view the request in the Certificate Authority console, and issue the certificate.

Once issued, the certificate can be retrieved using the request ID we got from running certreq previously:

certreq -retrieve 2 A:\EntCA01.CRT 

Now you have a certificate you can install on the Enterprise CA with the command:

certreq -accept A:\EntCA01.CRT 

The certreq command confirms that the private key on the enterprise CA matches the public key in the certificate, and installs the certificate. After restarting the CA services, the Enterprise CA is online and can accept requests.

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.