I’ll be doing a series of articles about PKI, it’s uses and how to set things up in a secure and correct manner. Information in these articles is gathered from various online resources, books and study material. Disclaimer: Though I am confident this information can be used to securely deploy a PKI even in big enterprises, you can use this information at your own risk.

This is the first part of the series, which will talk about setting up a root CA and it’s subordinate CAs. In the next articles we will talk about using this infrastructure to secure mail, encrypt files, secure your web servers, using smart cards for Windows logon and electronically sign your documents. Also, signing macro’s, software, add-ins, and more will be part of all of this. This article is full with abbreviations, though each of them should have at least once mentioned their full meaning.

Setting up a Private Key Infrastructure (PKI)

A PKI needs the following ingredients:

• One root certificate authority
• One or more subordinate certificate authorities
• Active Directory to facilitate in distributing and installing certificates
• A web server

The root CA

The root CA must be installed on a stand-alone machine. This machine must not be connected to the network at any time. Start by installing Windows (Standard Edition recommended), activate Windows by phone, install the latest service pack from a CD or DVD. After that, we’ll need to make some preparations for installing the certificate authority. Make sure the computer name of the machine is unique within your network, even though it’s an offline machine.

Create a text file that is called: “CAPolicy.inf”, and put in the following lines:

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
[CRLDistributionPoint]
[AuthorityInformationAccess]

This will ensure that in the root certificate, the AIA and CRL fields are suppressed. (More about these in a minute.) Place CAPolicy.inf in your Windows directory and install the CA. Enable the web enrollment option, since we’ll be using the website for creating certificates later.

During the installation of a CA, you’ll need to choose a Cryptographic Service Provider (CSP). Since the root CA (or any CA for that matter) only does signing, no encryption, the MS Strong CSP is sufficient for keys up to 16K, the enhanced CSP has essentially the same parameters. When you want to support CNG (Cryptography Next Generation) certificates, the selection of the CSP is an important one. But note that you might be breaking backwards compatibility if you’re using older clients (i.e. Windows XP SP2 or lower, or Windows Server 2003 and lower.) There is a hotfix though: http://support.microsoft.com/kb/938397

Once the CA is installed, you should have a root certificate that is valid for 20 years.

Configuring the Root CA

The Authority Information Access field in a certificate tells the end user where it can download a certificate which signed the certificate that you are using. For example, John sends you a certificate signed by an unknown certificate authority. You see a signature, but you have no idea who it is… Using a AIA extension you can see where you can obtain that certificate which placed the signature on John’s certificate. You download it and you see that it’s issued by a trusted root certificate authority. Since you trust the root CA, you can trust the signer of John’s certificate and therefore John’s certificate is valid. (There are more things to consider, but are outside of the scope of the AIA.) Without an AIA field you could never have verified John’s certificate.

The problem with an offline computer is that it has no network access. The default AIA field in certificates the root CA will issue will be the computer name of the root CA, which is… unreachable. The same story goes for the CRL Distribution point. The CRL (Certificate Revocation List) is used when certificates are revoked. An OCSP (Online Certificate Status Protocol) responder on the Root CA itself will also not work, because of the same reason: no network access. These fields are therefore important and need to be changed before any certificates are issued.

CA addresses (AIA and CRL) can contain multiple protocols, but I usually stick to http. The reason I do this, is because it’s easy to implement, manage, distribute and why should we make our lives more difficult? This is where the web server comes in. The CRL and the CA Certificate need to be hosted on a web server which anyone (internal in the network and outside of the network) has access to. An example:

On the left you see a picture of one of our intermediate CA’s. The CRL distribution point points to http://cert.thewheel.nl/rootca/The%20Wheel%20Enterprise%20Services%20Root%20CA.crl and if you click that link, you’ll get a CRL file. This is a CRL of our root CA, which is manually copied every month to a web server using an old-style method of either a floppy or a USB disk.

To change these extensions you can use the “Certificate Authority” console, right-click on the server, select properties and select the “Extensions” tab. Next, select the CRL extension and you’ll see a whole lot of items in the list box below, which can look quite intimidating, but don’t worry, it isn’t that geeky.

1. The extension starting with: “C:\Windows\system32\…” must have “Publish CRLs to this location” and “Publish Delta CRLs to this location” selected
2. Make sure that for the LDAP Extension all checkboxes are unchecked. This is an offline CA, so there’s no LDAP that we can use.
3. The default HTTP extension: “http://<ServerDNSName>/…” can be disabled. Uncheck all the checkboxes.
4. The default FILE extension: “file://<ServerDNSName>/…” can be disabled. Uncheck all the checkboxes.
5. Add a new extension, and type in the following: “http://myserver.mydomain.com/mysubdirectory/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl” (Without quotes, replace “myserver.mydomain.com/mysubdirectory with the address of your own web server which is everywhere accessible)
6. Apply your changes by clicking on the “Apply” button.

Now, we’re doing the same thing for the AIA. Select the AIA extension.

1. The extension starting with: “C:\Windows\system32\…” does not have any options you can set
2. Make sure that for the LDAP Extension all checkboxes are unchecked. This is an offline CA, so there’s no LDAP that we can use.
3. The default HTTP extension: “http://<ServerDNSName>/…” can be disabled. Uncheck all the checkboxes.
4. The default FILE extension: “file://<ServerDNSName>/…” can be disabled. Uncheck all the checkboxes.
5. Add a new extension, and type in the following: “http://myserver.mydomain.com/mysubdirectory/<CaName><CertificateName>.crt” (Without quotes, replace “myserver.mydomain.com/mysubdirectory with the address of your own web server which is everywhere accessible)

Next, create an empty directory somewhere on the disk and backup your certificate authority to this location. Copy this to some removable media (Floppy, USB flashdrive, etc)  and store it in a very secure location. If this data gets compromised, your PKI will be worthless and needs to be rebuilt from scratch. Lastly, we’re going to install the root certificate on all the machines in the network. (That’s the public certificate, not the private key of course!)

Copying the CA Certificate and the Root CA CRL to another computer

First, we need the root certificate, this you can obtain in multiple ways. The easiest way is to go to %windir%\system32\certsrv\certenroll and copy the files to removable media. Next, you can put these files (one CRL, one CRT and a ASP file for Netscape(!) compatibility) This CRT file is the public certificate of you root CA, not a private key so you don’t have to worry that this contains anything that is worth protecting. In fact, it’s quite the opposite, the more people/computers who trust that certificate, the better.

Installing the root certificate on all computers in the Active Directory domain

Now it’s time to get to either your domain controller or your own workstation if you have the group policy management console (GPMC) installed. Open the GPMC, and edit the default domain policy. Select the following path:

• Computer Configuration
• Policies
• Windows Settings
• Security Settings
• Public Key Policies
• Trusted Root Certification Authorities
• Add the root certificate by right-clicking the folder and click “Import”
• Next, open a command prompt and type: “GPUpdate /force” and wait for group policy to be applied.

Verify the root certificate is installed by doing the following steps:

• Open MMC
• Press Ctrl-M to open the “Add or remove snap-ins” dialog
• Add the “Certificates” snapin
• Choose “Computer account” –> “Local computer”
• Add another instance of the “Certificates” snapin
• Choose “My user account”
• Click on OK
• Expand each certificates node
• Check in the “Trusted root certification authorities” folder if your root certificate is there. (Both for the user account and for the computer account)

If they are both there, congratulations. You’ve done the most difficult step in setting up a PKI. The rest is easy :)

Installing a enterprise subordinate certificate authority

Subordinate CAs are CAs that issue certificates to end users. The Root CA doesn’t do this for several reasons, among which are:

• The CA Certificate of the Root CA can never be revoked
• The Root CA is offline, to issue end user certificates from a offline machine is impractical and a administrator’s nightmare.

Therefore, we create a subordinate CA to take away that burden. Subordinate CA’s are installed on domain controllers. Since we use AD, we can use a enterprise subordinate CA and use Certificate Templates to fine-tune our PKI. You’ll need Windows Enterprise Edition on the DC to do this. If you don’t want to use certificate templates (which is a huge benefit sometimes) you can use standard edition. Note that creating certificates for auto enrollment (which means kind-of zero administration) will require Windows Enterprise Edition. My recommendation? Stick with Enterprise Edition, it will save you a lot of time and effort. If you have a DC installed with Standard Edition, you can upgrade this DC to Enterprise Edition. (Both for Windows Server 2003 and 2008). Cross-platform upgrades (i.e. x86 to x64 or vice-versa) are not supported. Only Wipe & Load migrations or side-by-side migrations are possible. If you can, then this might be a good time to get to Windows Server 2008 x64, the 2008 R2 edition (and any future versions of Windows Server) coming in a few months will only support x64. (until 128 bit computing is invented and we’re reaching the 2 Exabyte of memory limitation on a machine ;-))

The subordinate CA will be a lot easier to install. Add the CA role and enable web enrollment option. I recommend using keys of 2048 bits in length for the intermediate CA. Also here, choose the CSP that best suites your purpose. During the installation you will be asked for the generation of a certificate request. Save the request to disk, we’ll be using the request file later for obtaining the certificate at the root CA.

Once installed, copy the request file to your USB flash drive or floppy, and bring it to the root CA. There you can start the web browser and browse to http://localhost/certsrv and you'll see the website which you can use to request a new certificate. Do the following steps to obtain a certificate for your new intermediate CA:

• Open the certificate authority management console
• Right-click on the CA
• Select All-Tasks –> Submit new request
• Open the request file
• Go to pending requests
• Issue the request
• Go to issued certificates
• Open the issued certificate
• Select the “Details” tab
• Export to a file
• Select the P7B format
• Check “Include all certificates in the certification path if possible”
• Save the file on your removable media

Now you have your certificate for your intermediate CA. Next, you need to install this on your intermediate CA. So you go back to your DC, open the certification authority snap-in and right-click on the CA. Select “Install CA Certificate” and select the certificate on your removable media. If everything went OK your new CA is up-and-running.

Now it’s time to change the extensions, and add some HTTP extensions so that the certificate and CRL can be downloaded via the web. Finally, make sure that the CA publishes the CRL at regular intervals to your web server.

Concluding

I recommend to have at least 2 intermediate certification authorities running, and in larger environments, to load-balance the web server for fault tolerance. (Note that the amount of web traffic is negligible, the goal is fault tolerance, not throughput.) Make sure that the root CA’s private key is well-guarded and treat this like the most important business secret.

If you would be able to factor this number:

30 82 01 0a 02 82 01 01 00 a9 02 bd c1 70 e6 3b f2 4e 1b 28 
9f 97 78 5e 30 ea a2 a9 8d 25 5f f8 fe 95 4c a3 b7 fe 9d a2 
20 3e 7c 51 a2 9b a2 8f 60 32 6b d1 42 64 79 ee ac 76 c9 54 
da f2 eb 9c 86 1c 8f 9f 84 66 b3 c5 6b 7a 62 23 d6 1d 3c de 
0f 01 92 e8 96 c4 bf 2d 66 9a 9a 68 26 99 d0 3a 2c bf 0c b5 
58 26 c1 46 e7 0a 3e 38 96 2c a9 28 39 a8 ec 49 83 42 e3 84 
0f bb 9a 6c 55 61 ac 82 7c a1 60 2d 77 4c e9 99 b4 64 3b 9a 
50 1c 31 08 24 14 9f a9 e7 91 2b 18 e6 3d 98 63 14 60 58 05 
65 9f 1d 37 52 87 f7 a7 ef 94 02 c6 1b d3 bf 55 45 b3 89 80 
bf 3a ec 54 94 4e ae fd a7 7a 6d 74 4e af 18 cc 96 09 28 21 
00 57 90 60 69 37 bb 4b 12 07 3c 56 ff 5b fb a4 66 0a 08 a6 
d2 81 56 57 ef b6 3b 5e 16 81 77 04 da f6 be ae 80 95 fe b0 
cd 7f d6 a7 1a 72 5c 3c ca bc f0 08 a3 22 30 b3 06 85 c9 b3 
20 77 13 85 df 02 03 01 00 01

... then Microsoft would have a serious problem. But since they keep their private key secure, it will be long after the time that this key is valid that the secret will be revealed, if ever.