Publishing a Public Key Infrastructure with ISA Server 2004 (Part 2)

If you would like to read the other parts in this article series please go to:

This is Part 2 of a three-part article is a step-by-step guide to building a Public Key Infrastructure (PKI) and using ISA Server 2004 to enable some often overlooked but important features in certificates. In Part 1 the ground work was established ready to create a PKI.

Introduction

Every Certificate Authority (CA) has its own certificate to uniquely identify it. A Public Key Infrastructure, being a collection of one or more CAs, has a “root” CA to rule over all the others. The Root stamps this authority on any “subordinate” by using its certificate to brand, or sign, the certificate to be associated with that subordinate. This brand is a mathematical mark that can only have been created by the Root in question and the brand can’t be tampered with without being detectable. A Root CA signs its own certificate because it has no-one else to do it.

If a client “trusts” the root certificate, it also trusts any certificate carrying its signature. It also means any CA who has its certificate signed by that root can also issue trusted certificates: The trust of the root CA passes all the way down the chain of CAs.

The root CA should only sign certificates of subordinate CAs and delegate the role of signing any other certificates to those subordinates. Many don’t bother with this hierarchical PKI structure and allow a root CA to issue all certificates. Here are a couple of arguments for not doing this:

  • Simplicity: You may need another issuing CA for another location or a development project, or perhaps you just messed up your current issuing CA! You could create yet another root CA, but that means getting those root CA certificates out to the users, removing them when done, and … ahh, it’s just plain messy! But there will always be those who get along just fine in a virtual dustbin full of ad-hoc root CAs.
  • Security: Leave the root CA around and someone might be tempted to find a way of stealing that root CA’s private key. They can now create certificates for mischievous purposes. If the root CA is compromised, none of your certificates can be trusted. For some this an unlikely scenario; others will not think it so.

This guide will demonstrate a two tier PKI consisting of an issuing CA and its root CA.

Creating the Root CA

The big disadvantage of a separate root CA is the additional hardware and Windows licensing. You can install the root CA on an existing live server but you’ll not have the security of being able to isolate, switch off and lock away the root CA. Economy measures could involve schemes with archiving, or perhaps virtual server technologies. An old Windows 2000 license might prove useful because a Windows 2000 root CA will work just fine.

When installing the operating system for your root CA there are a few points to remember:

  • The root CA server will not need to be a member of any of your AD domains. If you are going to switch it off for weeks at a time it must not be a domain member.
  • The root CA server doesn’t need to have network connectivity at all and the very security minded would never allow it.

Preparation Steps

Some CA settings just can’t be configured during normal installation and must be provided through a text file named “CAPOLICY.INF” in the system root folder (“C:\WINDOWS” for most of us). Using a text editor of your choice go ahead and create this file with the following content:

[Version]
Signature=”$Windows NT$”
[CRLDistributionPoint]
Empty=true

If you want to use Windows 2000 you need Service Pack 4 installed and the format is different:

[Version]
Signature=”$Windows NT$”
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=20
RenewalValidityPeriodUnits=Years
[AuthorityInformationAccess]
URL=””
[CRLDistributionPoint]
URL=””

The additional lines are because Windows 2000 doesn’t offer these options from the Windows Component Wizard. These extra lines have little effect in Windows 2003, but if you do include them be aware that the ‘RenewalValidityPeriod’ and ‘RenewalValidityPeriodUnits’ entries are the wrong-way-around for Windows 2000!

Installing Certificate Services

With the CAPOLICY.INF file created in the C:\WINDOWS folder go ahead and open the Windows Components Wizard (from ‘Add and Remove Programs’ in Control Panel).


Figure 1

Check the Certificate Services selection box. This warning appears:


Figure 2

Click Yes and then click Next.

Changing the name or domain membership of a Stand-alone CA server

The warning is a lie! Our root CA server is to be a stand-alone CA with no links to an Active Directory. You can actually backup a CA database, uninstall certificate services, rename the server, join or leave a domain, reinstall certificate services, restore the backup, reconfigure, and all will work fine. However this is an unlikely manoeuvre and don’t try it with an Enterprise CA.


Figure 3

We are installing a stand-alone root CA and also check the Use Custom Settings box and click Next. Note “Enterprise CA” is not an option for this non-domain server.


Figure 4

The defaults can be left on this page, but it is common practice to use a larger Key length for a root CA of say 4096 bits: However be aware that key lengths greater than the default 2048 bits will mean that you will not be able to use certificates from your PKI with Cisco equipment, and perhaps some other networking boxes too. Click Next.


Figure 5

On this page enter a suitable Common name. The Distinguished name suffix is entered with all sorts of flashy X.500 style strings to supposedly create a unique distinguished name, or DN (e.g. “OU=MyBusinessUnit,O=MyOrganisation”). Its importance will be lost on most of us so leave it blank if you want. Change Validity period from five years to something bigger because you never want to have to update the resulting certificate; 20 years should do the trick. Click Next.

Root CA Validity Period

There is a tiny security risk in having certificates valid for such a long period although cracking a 4096 bit private key in that time is currently incomprehensible. But who knows what the future will bring: If you are haunted by conspiracy theories and general extreme paranoia, well, choose something less (although you probably think all PKI is insecure anyway).


Figure 6

There is no need to change any of this; just click Next.

The Wizard will go through the Configuring Components and will stop with the following warning if you haven’t installed IIS:


Figure 7

This is fine; your root CA server is best not connected to the network so what use is Web enrolment! Just click OK. The Wizard will complete the installation and present a ‘completed’ dialog box: Click Finish.

If you choose to use Windows 2000 SP4 for your root CA, the steps are very similar but with fewer options (such as validity period). You will rely on all those other settings in the CAPOLICY.INF file to fill in the gaps.

Configuring Certificate Services

The first step to configuring our new CA involves a little tinkering with the registry. By default a Windows stand-alone CA will create certificates from requests that have a validity of only one year. This is not often acceptable when the certificates are for subordinate (issuing) CAs. Start up REGEDIT and navigate to:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Your CA Name


Figure 8

Locate the REG_DWORD value called ValidityPeriodUnits and change it to a suitable value (5 would be reasonable). The ValidityPeriod value is ‘Years’ by default.

If you’re using Windows 2003 you can avoid using REGEDIT and instead run the following command-lines:

certutil -setreg ca\ValidityPeriodUnits “5”
certutil -setreg ca\ValidityPeriod “Years”

Subordinate CA Validity Period

Don’t consider this validity period to be permanently set. You may decide to create a subordinate CA for a specific project that will be over in three months. In such cases you may temporarily change these registry settings and restart the Certificate services. A CA will never issue certificates that are valid beyond the validity of its own certificate so doing this allows you to create subordinate CAs tailored for the job.

With that done find the Certification Authority console amongst Administrative Tools.


Figure 9

Right-click on the CA’s name in the left pane and select Properties.


Figure 10

The Properties sheet open on the General page, and you can view your CA’s certificate from here (note that on the details page the CRL Distribution Points setting is absent because of the CAPOLICY.INF file we used). Our real interest lies on the Extensions page, so click on that.

None of the default entries under Specify locations from which users can obtain a CRL will suit our purpose: this server is not a domain member so the LDAP entry will have invalid data; the server is offline so the HTTP and FILE entries will not point anywhere accessible, and all entries use a filename that is too complex for this purpose. First take note of the path in the first entry then high-light each in turn, click the Remove button and confirm the removal.

Now click Add.


Figure 11

Enter a local distribution point where certificate services can save a suitably named CRL. You can use the default location with the path you noted above together with a suitable filename (I use an abbreviation of the CA name and avoid spaces). The entry will have a similar format to:

C:\WINDOWS\system32\CertSrv\CertEnroll\Company1RootCA.crl

Click OK. You may use variables here if you wish but all sorts of unexpected behavior will result. Watch out for the HTTP examples provided under Description of selected variable: All those variables following ‘<CaName>’ are not only inappropriate for an HTTP location; they can also prevent the location appearing in your issued certificates!


Figure 12

Check the Publish CRLs to this location box and then click Add again.


Figure 13

Enter a LDAP distribution point although we are not actually using this location for the purposes of this article. It will have the format similar to:

ldap:///CN=<CATruncatedName>,CN=ROOTCA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=company1,DC=local<CDPObjectClass>

The domain components (DC) here are for ‘company1.local’; you would enter the values from your own AD domain name. Note that there are three forward slashes.

Strictly speaking you should use the ‘<CATruncatedName>’ variable to insert the ‘sanitised’ CA name. Unless you used a huge CA Name, this truncated name will be the same as the CA’s full name.

This example explicitly uses the string ‘CN=ROOTCA’, which happens, in this case, to be the server’s name. Beware of using ‘CN=<ServerShortName>’ here; this may cause confusion should you ever recklessly follow my earlier comments about renaming a CA server! Use ‘ROOTCA’ or another name; it doesn’t have to be the server’s name for an offline CA.

Click OK but do not check any of the boxes for this entry. Click Add again.

Using Active Directory for CRL Distribution Points

For this article we’ll only be using an HTTP Distribution Point which is perfectly adequate and makes good sense when the certificates are to be used externally. So why configure an LDAP location? Your root CA doesn’t want to be limited to a one off job; it should be able to service many if not all of your PKI needs. It may be you decide to create a CA solely for internal use and want to use AD as the distribution point. With this entry already in place you need only check the Include in the CDP extension of issued certificates box, restart the service and issue the CA’s certificate.

You can check the Include in all CRLs option and save some typing when publishing the CRL to AD (we’ll do this in Part 3), but personally I’d avoid having any AD information in a CRL that will ultimately be viewable on the Internet. Never check Publish CRLs to this location on a stand-alone server.


Figure 14

Under Location enter the URL of your chosen HTTP distribution point (from Part 1) together with the filename you’ve already used in the earlier entry. For example:

http://certificates.company1.local/Company1RootCA.crl

Click OK. If you are using more than one HTTP distribution point, go ahead and add those too.


Figure 15

Check the Include in the CDP extension of issued certificates box for the HTTP entry.

If you chose to have this server connected to the network (not recommended) you could add a FILE entry to save some of the manual copying of files that will be coming up. This will be described in detail for the subordinate (issuing) CA in Part 3.

From the Select extension pull down list, select Authority Information Access (AIA).


Figure 16

As for the CDP remove the default entries, but this time there is little point in changing the first entry (C:\WINDOWS…) so you can keep that one. Click Add and enter a LDAP entry as you did for the CDP locations but this time make it similar to:

ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=company1,DC=local<CDPObjectClass>

Use your own AD domain name for those DC bits! Click OK.

Using Active Directory for Authority Information Access

As with the CDP, I’ve included an LDAP entry here solely as a fore-sight and it will not be used for the purposes of this article. Check the Include in the AIA extension of issued certificates and restart the service before issuing a CA certificate for a CA that will be used in the AD domain only.

Click Add again and enter an HTTP entry that suits your chosen URL. In this example I’ve used:

http://certificates.company1.local/Company1RootCA.crt

Again, avoid those variables here or you may be faced with some unexpected problems.


Figure 17

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. Now click OK and then click Yes to the prompt to restart the service.

Note the OCSP option on this property sheet; we’ll mention that stuff again a bit later.


Figure 18

Now right-click the Revoked Certificates folder and select Properties.


Figure 19

You will not be publishing Delta CRLs from this root CA, so don’t check that option. The CRL publication interval is 1 week by default and needs changing to something greater such as the three months here.

Dilemma of the CRL Publication Interval for an offline root CA

Before a new CRL is due you will have to manually create a new CRL and then copy this to your distribution points (described later). This is an annoying job that you must not forget so the temptation is to set a very large publication interval. But if you then need to revoke a subordinate CA’s certificate, because it is compromised say (unlikely but you never know), you can’t immediately enforce this because clients cache CRLs for the period of their validity. You must reach an acceptable compromise when choosing the publication interval and this is an unavoidable limitation of the CRL mechanism.

There is a better way: ‘Online Certificate Status Protocol’ (OCSP) is an up and coming method that avoids issues with CRLs. There is an option for OCSP when configuring a CA’s AIA, and the “CryptoAPI” on Windows clients can easily be enhanced to support OCSP. But “OCSP responder” software to work with your PKI is not so easy to find.

Managing the Root CA, CA Certificate and CRLs

Back in the Certification Authority console, again right-click the Revoked Certificates folder and this time select All Tasks and Publish.


Figure 20

Click OK and a new CRL is created in the default C:\WINDOWS\system32\CertSrv\CertEnroll folder. Now open File Explorer and navigate to this location.


Figure 21

Copy both the ‘CRL’ and ‘CRT’ file to media that can be transferred to your online servers (floppy disc, pen-drive, or whatever). Rename the copied ‘crt’ file to match the HTTP AIA location you configured, which in this example would be Company1RootCA.crt. The older CRL is from before reconfiguring the CRL Distribution Points and can be safely deleted.

Take this media to the server where you created the shared folder earlier in Part 1 and copy the ‘CRL’ and ‘CRT’ files to that folder. Part 3 will discuss how we will publish these files in AD.

Distribute the Root CA Certificate with Group Policy

This step ensures everyone in your domain will trust your new root CA. This step modifies the Default Domain Policy Group Policy object (GPO) and Microsoft recommends that you always back this up before such changes.

Log on to a domain controller with administrator privilege. Amongst the Administrative Tools locate and open the Domain Security Policy.

Under Security Settings in the left-hand pane expand Public Key Policies and right-click Trusted Root Certification Authorities. Select Import from the menu. The Certification Import Wizard opens:

  1. Click Next on the Welcome page and on the next page browse to the shared location where you copied the Root CA’s certificate. Click Next.


Figure 22

  1. Click Next to the next page (you can’t change the certificate store location).
  2. Click Finish and confirm the successful import.


Figure 23

If you have more than one domain where this certificate applies, repeat the process on DCs in those domains.

Maintaining the Root CA

The root CA is now ready to issue its first certificate to a subordinate CA. Meanwhile, if you followed recommendations, this CA is offline (not connected to the network) so you may as well shut it down and turn it off!

You need to protect your root CA both for security and so you don’t lose it to hardware failure. Lock it up, or keep it in a secure server room. Before you do so ensure you have a backup of at least the CA’s database and private key (in the Certification Authority console, right-click the CA name and select All Tasks and Backup CA). Keep the backups as securely as the server itself. Make backups after issuing any new certificates and after publishing a new CRL.

As the end of the ‘CRL Publication Interval’ draws near you will need to visit your root CA, manually publish a new CRL as described above and take a copy of the new ‘crl’ file to your publishing points.

Conclusion

We’re now half way through the creation of a PKI for use with ISA Server in an Internet facing scenario. Part 3 will step through the creation of a subordinate CA.

 

If you would like to read the other parts in this article series please go to:

 

Appendix

The following is a list of those variables used in generating locations. Some are inappropriate especially for stand-alone CAs, the rest probably don’t save any labour and some will cause all sorts of problems if used in the wrong place! I recommend not to use them unless absolutely necessary although one or two will still find some use in Part 3 of this article.

CAName
The name of the certification authority.

CAObjectClass
The object class identifier for a certification authority, used when publishing to an LDAP URL.

CATruncatedName
The name of the certification authority, truncated to 32 characters with a hash on the end!

CDPObjectClass
The object class identifier for CRL distribution points, used when publishing to an LDAP URL.

CertificateName
The renewal extension of the certification authority.

ConfigurationContainer
The location of the Configuration container in Active Directory.

CRLNameSuffix
Inserts a name suffix at the end of the file name when publishing a CRL to a file or URL location.

DeltaCRLAllowed
When a delta CRL is published, this replaces the CRLNameSuffix with a separate suffix to distinguish the delta CRL.

ServerDNSName
The DNS name of the certification authority server.

ServerShortName
The NetBIOS name of the certification authority server.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top