If you would like to read the other parts in this article series please go to:
- Publishing a Public Key Infrastructure with ISA Server 2004 (Part 1)
- Publishing a Public Key Infrastructure with ISA Server 2004 (Part 2)
In Part 1 the ground work was established ready to create a PKI and Part 2 covered configuring the “Root” CA. In this Part 3 we’ll create an “Issuing” CA to provide certificates suitable for use outside your local network.
In this article we are creating a two tiered PKI hierarchy; we’ve already created the top tier ‘root’ CA in Part 2 and are now going to cover the second tier ‘issuing’ CA. Some PKI hierarchies may have additional tiers, perhaps with a second tier of stand-alone offline CAs and the issuing CAs on the third tier. These multiple tiers seem overly complex for the majority of deployments and even public PKIs rarely utilise more than two tiers of CAs.
This article will only cover a single issuing CA, but you might choose to have more for availability, load spread across different locations, or for specific purposes and projects.
The process of creating the issuing CA often mirrors the root CA installation described in Part 2, so here we’ll concentrate on describing the differences.
Creating an Issuing CA
A general purpose issuing CA, such as this article describes, will be installed as a subordinate Enterprise CA on a domain member server. Enterprise CAs (root or subordinate) should always be available and certainly not ‘offline’.
Administrators commonly install issuing CAs on their domain controllers. This isn’t entirely unreasonable given that you should be defending the security of your CA with the same rigour as domain controllers. However, it is common to provide the Web enrolment features for an issuing CA and many administrators will be uncomfortable with installing IIS on a domain controller: An issuing CA installed on a member server is preferred.
In Part 2 the use of Windows 2000 SP4 was suggested as a satisfactory option to Windows 2003 for an offline root CA, but for an issuing Enterprise CA you’ll be using the additional features with Windows 2003. There are also big differences between Enterprise CAs on Windows 2003 Standard and Enterprise editions: Enterprise edition allows you to create custom certificate templates and auto-enrolment of certificates by computer and user accounts. You can get by using Windows 2003 Standard, but those custom certificate templates can come in very handy for some advanced certificate usage.
Side-note on Auto-enrolment of Certificates
Computers have been able to auto-enrol for certificates since Windows 2000. To do this the required certificates are uploaded into a Group Policy Object under Computer Configuration, Windows Settings, Security Settings, Public Key Policies, and Automatic Certificate Request Settings.
GPOs in Windows 2003 have an object in Public Key Policies called ‘Autoenrollment Settings’ that makes use of custom certificate templates available on Windows 2003
edition. These are two separate mechanisms; either use the old or the new as you please Enterprise
Installing Certificate Services
As for the root CA in Part 2, start with the Windows Components Wizard (from ‘Add and Remove Programs’ in Control Panel). You don’t need a CAPOLICY.INF file in this case, but you will need to be a temporary member of the Enterprise Admins group.
Select Certificate Services and heed the warning about renaming the server. In this case you may also want to select the World Wide Web Service buried under Application Server. Adding the WWW Service will allow the use of the Web enrolment tools, but this feature is not an essential part of certificate services. Click Next.
We’re installing an Enterprise subordinate CA so select that and check the Use custom settings box too (it allows you to set a bigger key size). Click Next.
The next screen displays default key size of 1024 bits; it is common practice to increase this to 2048 for subordinate CAs, especially if you elected to use a 4096 bit key for your root CA. The other options can be left with the defaults as it was for the root CA. Click Next.
Provide a Common name for this CA. The Distinguished name suffix is automatically created for you from the AD domain name (e.g. DC=Company1,DC=local): Such ‘local’ information isn’t appropriate for certificates that will appear on the Internet so either clear this field (as above) or fill it with other X.500 style strings (see Part 2). Note the validity period can’t be set; the root CA will do that. Click Next.
Click Next to the next screen too (you don’t really need the ‘shared folder’ stuff it talks about).
Select Save the request to a file option (you can change the default save location if you want). You can’t send the request directly because your root CA is offline if you’re following the recommended track. Click Next. You will need to provide the Windows 2003 installation CD.
Eventually these instructions appear. Click OK.
You may see this warning which is particularly valid to those who choose to install a CA on a domain controller. If you see it, click Yes. Click Finish on the completion dialog box.
Locate that ‘req’ file and copy it to removable media (floppy disk, pen-drive, etc.) for transfer to the offline root CA a bit later on.
Configuring Certificate Services
Find the Certification Authority console amongst Administrative Tools.
Because we haven’t processed the CA certificate request yet, the console will indicate that the service is stopped. No matter, just right-click the CA name and select Properties. Click OK to the warning about the stopped service.
Go to the Extensions page. Ignore the first entry, select the LDAP entry and clear all the check boxes except for Publish CRLs to this location and Publish Delta CRLs to this location.
The certificates this CA issues are to be used externally with ISA Server so un-checking the boxes for the LDAP entry will ensure that unusable LDAP locations won’t appear in the certificates this CA issues. Leaving the LDAP entry in place and publishing the CRLs to AD even though they will not be used is just a whim of mine! If this CA was only issuing certificates used only on the internal network you might as well leave all the check boxes in place.
Select the HTTP and FILE entries and remove them as we will not be using these.
Now click Add and create an HTTP location just as was done for the root CA in Part 2 (do refer back to this for some warnings). The example here uses:
As with setting up the Root CA I recommend a filename based on an abbreviation of the CA’s name without any spaces rather than using the ‘<CAName>’ variable.
Highlight the HTTP entry and check the Include in the CDP extension of issued certificates box.
Click Add again and create an entry along the lines of:
This is the share we created earlier in Part 1 from where our certificates and CRLs are published using IIS. The entry you use will reflect your chosen share. Click OK.
If this CA is to be very busy with many revocations of certificates you might consider using Delta CRLs. If so use the ‘<CRLNameSuffix><DeltaCRLAllowed>’ variables in filenames (but not on the HTTP location) and check the Include in CRLs… for HTTP entries and Publish Delta CRLs to this location for FILE entries. The majority of us can leave all this out.
Check the Publish CRLs to this location box.
From Select extension pull down list, select Authority Information Access (AIA). Again remove the default HTTP and FILE entries and the click Add. Add the URL of your distribution point with a filename along the lines of:
Check the Include in the AIA extension of issued certificates box for our HTTP location and ensure all check boxes are cleared for the LDAP location (if you haven’t removed it too). Click OK.
You may optionally use the ‘<CertificateName>’ variable to add a renewal suffix to the filename and save you manually renaming when renewing the CA’s certificate in a few years time. The purpose of slightly changing the name at renewal is to allow both old and new CA certificate to co-exist. However, the labour saving is minimal when using long validity periods like the five years in this example.
The default one week publication interval should be okay, but unless you know your CA is going to be extremely busy, with a lot of revocations of certificates likely, uncheck the Publish Delta CRLs option. Click OK.
Signing the Issuing CA’s Certificate
Take the floppy disk (or whatever) containing the request file generated when installing certificate services over to your Root CA. Open the Certification Authority console on that server.
Right-click the CA name and select All Tasks and Submit new request.
Browse to your saved request file, select it and click Open.
Click on the Pending Requests folder and right-click our submitted request which now appears in the right pane. Select All tasks and View Attributes/Extensions.
Click the Extensions tab and check that the CRL Distribution Points and Authority Information Access entries are as expected. Click OK.
Again right-click our submitted request in the Pending Requests folder. Select All tasks and Issue. If we were not happy with the CDP and AIA entries checked above, you would select Deny here, correct whatever is wrong in the Root CA’s configuration for these entries, then repeat the process with the same request file. Now click on the Issued Certificates folder.
Double-click the newly created certificate appearing in the right pane. Select the Details page from the property sheets that open.
Click Copy to file which opens the Certificate Export Wizard which we’ll quickly step through:
- Click Next on the Welcome page.
- On the Export File Format page check the Cryptographic Message Syntax Standard – PKCS #7 Certificates (.P7B) option and check the Include all certificates in the certification path if possible box. Certificate services likes all the information in this one package when it comes to importing the new CA certificate. Click Next.
- On the File to Export page click Browse, browse to your removable media and type in the filename you’ll be using to publish the certificate (in this example this will be Company1IssuingCA). Click Save then Next.
- Click Finish on the Completion page and OK the confirmation.
Repeat the export steps but this time select DER encoded binary X.509 (.CER). Rename the created file so that it has the extension CRT instead of CER. With that done, exit.
Copy the Issuing CA’s newly signed certificate (now with CRT extension) to your distribution point shared folder. The P7B file is to be used later.
The Root CA can now be backed up and locked away, but before doing that run certutil –cainfo at the command-line of the Root CA server and take note of the ‘sanitised’ or shortened CA name (you will need this later if this name differs from the full CA name).
Finalising the PKI Configuration
Before installing the Issuing CA’s signed certificate there are a few optional steps that can be taken in advance to smooth the way.
Testing the Certificate Configuration
On the Issuing CA’s server run the following command-line (using your share location and certificate file name in place of the example here):
certutil –URL \\DC01\Certificate$\Company1IssuingCA.crt
Click Retrieve. This will let you check your distribution point and CA certificates and ensure all is well before proceeding further. If you use the Certs (from AIA) option the status will report ‘No CRL’ which is expected because the Root CA’s certificate has no CDP entry.
You can also run the following command-line:
certutil –verify \\DC01\Certificate$\Company1IssuingCA.crt
There will be a lot of output, but any errors should stand out.
Publishing the Root CA Certificate and CRL in Active Directory
As mentioned before, having the Root CA certificate in AD isn’t required for this article but having it there for future use is not an unreasonable step to take.
On the Issuing CA’s server run the following command-line to publish the Root CA’s certificate (using your share location and certificate file name in place of the example here):
certutil –dsPublish –f \\DC01\Certificate$\Company1RootCA.crt RootCA
The command should report that the certificate was successfully added in two locations.
Next run the following command-line to publish the Root CA’s CRL:
certutil –dsPublish –f \\DC01\Certificate$\Company1RootCA.crl ROOTCA “Company1 Root Certificate Authority”
‘ROOTCA’ is used here and reflects the CDP LDAP entry created in Part 2. The CA name at the end of the command is the ‘sanitised’ or shortened name referred to earlier, although it is usually identical to the name you’ve used all along. Refer back to the discussion about all this in Part 2.
You will need to run the command to publish a CRL (but can omit the ‘-f’ switch) whenever you create a new CRL on the Root CA and copy it to the distribution point.
Restart the Issuing CA Server
At this point restart the Issuing CA server. This is for the server to establish its membership of the Cert Publishers built-in local group. It will need this to publish its first CRL.
Installing the Issuing CA’s Certificate
Finally, with the server restarted and everything checked and in place, go back in the Certification Authority console on the Issuing CA:
Right-click the CA name and select All Tasks and Install CA Certificate.
Browse to the removable media you are using, select your newly issued P7B certificate and click Open. After a short while you’ll return to the console: Right-click the CA Name and select All Tasks and Start Service.
Do check your distribution point folder share: You should see the Issuing CA’s CRL that has been published there automatically. The CA will continue to do this every week from now on.
Testing the PKI
The CA is now ready to issue certificates! You can further test the health of your PKI with the “Enterprise PKI” MMC snap-in which is part of the Windows 2003 Resource Kit tools (and can also be downloaded separately).
The IIS Certificate Wizard provides a good place from which to request the first certificate. Set up a secure Web site, open it in Internet Explorer and click on the padlock icon in the bottom right corner.
It has been quite a long haul to finally get all the parts of this PKI in place; but this is a substantially abridged version of Microsoft’s “best practice” documentation! The process can be off-putting for many administrators, but getting it right is a huge improvement over the alternative of having ad-hoc root CAs popping up all over your organisation; accompanied by the popping up of all those certificate warning messages too!
Throw ISA Server 2004 into the mix, and your certificates continue to function slickly even out on the Internet. It has got to be worth the effort!
If you would like to read the other parts in this article series please go to: