In Windows Server 2003, Certificate Services provides many new features that will simplify the Certification Authority (CA) administrator’s life and that support newer standards. Among the new and improved features are Version 2 certificate templates, which provide enhanced control over enrollment and certificate issuance; key archival and recovery; and delta certificate revocation lists (CRLs). Even if you haven’t considered Certificate Services in the past, you might want to do so now. In this article, I describe how to work with these key new Certificate Services features.
Enhancing Security with Certificate Services
Certificate Services is the Windows component that lets large and small enterprises install a full-blown X.509v3-based public key infrastructure (PKI). The PKI can issue certificates to users and computers to enhance security by enabling IPsec; 802.1x authentication for wireless networks; the Encrypting File System (EFS); Secure Sockets Layer (SSL) and Transport Layer Security (TLS) to protect Web sites; smart card authentication; and Secure MIME (S/MIME) to protect email. Certificate Services is free with the server OS and lets you avoid buying certificates from a third-party CA for internal operations. (Note, however, that you might need to get third-party certificates for external security—e.g., for e-commerce Web sites.)
Each edition of Windows 2003 provides a different level of functionality for Certificate Services. In the Windows 2003 Enterprise Edition (and the Windows 2003 Datacenter Edition), Certificate Services is designed for use in enterprise environments and offers the fullest range of functionality. In the Windows 2003 Standard Edition, Certificate Services offers more functionality than the version that shipped with Windows 2000, functionality sufficient for many small-to-midsized businesses (SMBs). The Windows 2003 Web Edition doesn’t offer any PKI services but can function as a client. Table 1 compares the Certificate Services functions available in several popular Windows server versions. In addition, the Windows Server 2003 Resource Kit provides such key features as the Simple Certificate Enrollment Protocol (SCEP) add-on. For more about SCEP, go to http://www.microsoft.com/downloads/details.aspx?
displaylang=en&familyid=9f306763-d036-41d8-8860-
1636411b2d0.
Like its Win2K counterpart, Windows 2003 Certificate Services offers several installation and configuration options. You can install Certificate Services as either an enterprise CA or a standalone CA, depending on your planned use. An enterprise CA is fully integrated with your Active Directory (AD) infrastructure. Through a process called autoenrollment, you can leverage the enterprise CA to automatically issue certificates to subjects (typically users or computers) without administrative intervention. Also, many Windows security technologies (e.g., IPsec, smart card logon, 802.1x) are designed to leverage an enterprise CA. An enterprise CA is always online even if it’s a root CA.
A standalone CA, however, isn’t necessarily integrated with AD and isn’t as transparent to subjects or to Windows security technologies. A standalone CA can be an offline root CA that comes online to issue certificates for intermediate or sub CAs when required. If your organization wants to have an offline root CA, you can create a standalone CA that functions as your root CA and issue a sub CA certificate to your enterprise CA. For more information about enterprise versus standalone CAs, see "Defining CA Types and Roles," http://technet2.microsoft.com/windowsserver/en/library/1b28424c-8c62-44b6-a24f-8ea06ac5832b1033.mspx.
Installing Certificate Services
Although installing Certificate Services is straightforward, you need to plan your installation carefully. If you’re installing a new CA, you must decide whether you’ll be installing an enterprise CA or a standalone CA as your root CA. Note that it’s possible, even quite common, to install several standalone CAs, either as self-contained root CAs or sub CAs. This approach is useful if you need to create a CA for a particular application or group, especially if you also want to delegate administration. If you plan to install an offline standalone root CA, you must configure a CAPolicy.inf file to ensure that the CRLs and Authority Information Access (AIA) distribution points named in the root CA’s self-signed certificate point to online locations that users can access. For more information about planning a PKI deployment, see the white paper “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” at http://technet2.microsoft.com/windowsserver/en/library/32ba85e7-3ef0-44d1-b9e8-b7fe0d4907261033.mspx?mfr=true.
To begin installation of Certificate Services, log on to the server that will be a CA. For an enterprise CA or standalone CA, the server you select can be a member server (recommended) or a domain controller (DC—not recommended). For a standalone CA, the server can also be a workgroup server not joined to a domain. You must log on as a member of the Enterprise Admins group to install an enterprise CA and as a member of the Domain Admins group to install a standalone CA that will store certificates in AD. To install a standalone CA that won’t store its certificates in AD, you must be a member of the local Administrators group.
To install Certificate Services with the Windows Component Wizard, you begin with the following steps:
- Start Add/Remove Programs and click Add/Remove Windows Components to launch the Windows Components Wizard.
- Select the Certificate Services option to begin installation and click Next. By default, this choice installs the CA service and database and the Web-based enrollment service. If you don’t need the Web-based enrollment service (or want to install it later), you can click Details to select which components of the CA to install. A message will appear with a warning about moving or renaming the system after the component is installed. Heed this message well. Click Yes to continue the installation.
- Select the type of CA that you want to create from the following four choices: Enterprise Root CA, Enterprise subordinate CA, Stand-alone Root CA, and Stand-alone subordinate CA. At this point, you can also choose to configure the Cryptographic Service Provider, key length, and hashing algorithm by selecting the option to use custom settings. You should choose custom settings if you use Hardware Security Modules (HSMs)—such as those nCipher offers—to protect your CA’s private key.
As you continue to step through the wizard, you’ll be asked for configuration information (e.g., the name of the CA you’re installing, the location of the certificate database and log files). The wizard will then generate a public/private key pair for the CA to use. If Microsoft IIS is running and you’re installing the Web-based enrollment service, the wizard will prompt you with a question about whether it can temporarily stop IIS so the Web service can be added.
Version 2 Certificate Templates
For many CA administrators, Version 2 certificate templates are the most important new feature in Certificate Services. (For information about Version 2 templates, see the Web-exclusive article “Certificate Templates,” August 2002, InstantDoc ID 26119, and “Version 2 Certificate Templates,” May 2002, InstantDoc ID 24545). To use Version 2 templates, you must have Windows 2003 Enterprise Edition and you must have installed Certificates Services as an enterprise CA. To view the available templates, launch the Microsoft Management Console (MMC) Certification Authority snap-in from the Administrative Tools program group, expand the CA node, right-click the Certificate Templates node, and select Manage. Alternatively, you can run the MMC from the command line by typing
MMC.EXE
The screen in Figure 1 displays a partial list of the templates that ship with Windows 2003 Enterprise Edition. You’ll note that some templates require a Windows 2003 Enterprise Edition CA while others require a Win2K or later CA. If you double-click a template that requires a Windows 2003 CA, you’ll see that you can edit and customize many of its properties. If, however, you double-click a Win2K CA certificate, you’ll see that you can’t modify the properties (with the exception of security settings). However, you can use the Certificate Templates snap-in to duplicate Win2K CA templates and make them customizable. Simply right-click a template and select Duplicate Template. In the Properties dialog box that appears, you can name and customize the template, as Figure 2 shows.
In the Properties dialog box, tabs correspond with several customizable settings. For example, the Request Handling tab lets you select the purpose (which determines the type of security) for the certificates the template will issue. Your options are signature, encryption, signature and encryption, or smart card logon and signature. If your choice includes encryption, you can choose whether to archive the encryption private key. (I’ll discuss key archival and recovery later in more detail.) The Subject Name tab controls whether identifying information will come from AD when a certificate is issued and what form the subject name will take. You can choose alternate subject names; your choices—Email Address, DNS Name, User Principal Name (UPN), and Service Principal Name (SPN)—appear as a list of check boxes from which you can select more than one.
You select requirements for issuing certificates through the Issuance Requirements tab. For example, you can set restrictions on how many signatures each certificate must have (if you require more than one, you can’t issue a certificate through autenrollment) and application and issuance policies (e.g., assurance requirements). You can specify which templates a new certificate template replaces through the Superseded Templates tab. When a certificate template is replaced, those who hold certificates from the old template must obtain a replacement certificate from the new template before the scheduled expiration.
You can use the Extensions tab to define Application Policies (aka Extended Key Usage) in certificates issued from a template. The Application Policies define the uses to which a certificate can be put. Application Policies include EFS, Client Authentication, Email Security, SmartCard Logon, Code Signing, and Server Authentication. Also on the Extensions tab are Issuance Policies, which define the level of assurance associated with the certificate and contain the location of the Certification Practice Statement (CPS). You can create new levels of assurance from this tab and modify existing ones as required. You use the Security tab to define who can use the template and how. Through this tab, you can grant subjects permission to obtain a certificate through autoenrollment (although how you customize the template might keep a subject from acquiring a certificate in this manner). Also, you must give users read and enroll permissions before they can use autoenrollment.
The CA won’t issue every template listed in the Certificate Templates snap-in. Before a certificate can be issued from a template, including from templates you create, the template must be imported into the Certificate Templates listed in the Certification Authority snap-in. To import a template, in the Certification Authority snap-in, right-click the Certificate Templates node and select New, then Certificate Template to Issue. From the list of available certificate templates displayed, you can select the templates for those certificates you want the CA to issue.
Key Archival and Recovery
Introduced in Windows 2003 Certificate Services, key archival and recovery lets CA administrators configure the CA to archive the private keys associated with issued certificates. To use key archival and recovery, you must have an enterprise CA installed on Windows 2003 Enterprise Edition. When a user loses a private key, the user can request that a key recovery agent recover it from the CA. Windows 2003’s key archival and recovery replaces Microsoft Exchange 2000 Server’s Key Management System (KMS). Key archival and recovery doesn’t replace the function of the EFS Recovery Agent, however. Typically, you use the recovery agent in a variety of situations—not just when users lose the private key associated with their EFS certificate.
You need to plan carefully before you implement key archival and recovery. First, you must designate user accounts as key recovery agent accounts. The number of accounts that you designate will depend on your policies; I recommend that you designate as few key recovery agent accounts as possible. These accounts will be able to extract the archived private keys from the CA. You must protect these accounts and use proper processes to facilitate key recovery and to keep rogue users from obtaining other users’ private keys.
In environments that use certificates for signing operations (e.g., secure email) or for authentication, CA administrators should consider modifying Version 2 certificate templates to ensure that certificates used for these purposes are separate from certificates used for encryption. In addition, CA administrators must ensure that only certificates used for encryption are configured for key archival and recovery; otherwise, with a recovered key, rogue administrators could perform signing operations or authenticate as users. Users would be required to obtain at least two certificates—with one required for signing and one for encryption.
After you have created or identified accounts as key recovery agents, they must obtain Key Recovery Agent certificates. An enterprise CA won’t issue these certificates by default. You must configure the CA to issue them by importing the Key Recovery Agent template, by using the steps I described previously. Accounts can obtain a Key Recovery Agent certificate through the Web-based enrollment tool at http://<fqdnofca>/certsrv. By default, Key Recovery Agent certificates are issued only to accounts that are members of Enterprise Admins. If a key recovery agent account isn’t a member of this group, you can modify the template’s security to grant the account (or a group to which the account belongs) the necessary permissions.
You obtain the Key Recovery Agent certificate by first clicking the link to request a certificate, then clicking the link to submit an advanced certificate request, and finally clicking the link to create and submit a request to this CA. From the drop-down list, you select Key Recovery Agent. Barring any special requirements, you can click Submit. Unless the CA has been configured to do otherwise for Key Recovery Agent certificates, the request will be held pending the CA administrator’s approval. The CA administrator can use the Certification Authority snap-in to approve the request.
To approve the request, the CA administrator can right-click the request in the Pending Requests container and select Issue. The user can obtain the Key Recovery Agent certificate by revisiting the Web site after the request has been granted, clicking the link to check pending requests, then clicking the certificate to install it.
Before the CA can begin responding to requests to archive keys associated with certificates, you must configure the CA to do so. Right-click the CA node in the Certification Authority snap-in, select Properties, click the Recovery Agents tab, then select the Archive the key option. By default, one recovery agent is configured per CA, but you can specify more than one. The recovery agents for the CA must be named. You can select recovery agents by clicking Add and then selecting the key recovery agents’ certificates. After you specify the recovery agents, Certificate Services must be restarted for the changes to take effect. (You’re offered the choice of restarting the server immediately or restarting it later manually.) Figure 3 shows the properties of a CA configured for key archival.
Next, you must modify the properties for each template from which certificates are issued for which you want key archival. If a template is a Version 1 template, you need to duplicate it to create a Version 2 template that can be modified. (You can then configure the template to supersede the template from which it was duplicated.)
When a user notifies a key recovery agent about a lost private key, some level of verification should be performed. First, the key recovery agent must make sure that the user is who he or she claims to be. Second, the agent needs to identify the certificate whose accompanying key has been lost.
To retrieve an archived key, the key recovery agent must know one of the following: the certificate common name, the serial number, the SHA-1 hash, or the requester’s name or UPN. Some of these items of information will identify more than one certificate. For example, both the requester’s name and UPN can map to multiple certificates. To identify certificates belonging to a particular user and to obtain unique identifiers, the key recovery agent can use the Certification Authority snap-in to view Issued Certificates. You can identify certificates for which keys have been archived by selecting Add/Remove Columns from the View menu and adding Key Recovery Agent Hash to the list of columns displayed. The Key Recovery Agent Hash column will be populated for those certificates whose private keys have been archived.
The simplest method of recovering the private key for a certificate is to use the certutil.exe command with the -GetKey option. For example, if the serial number for the certificate is 118b237e000000000006, the following command will retrieve and save the private key in an encrypted form in the file named recoveredkey:
certutil -GetKey 118b237e000000000006 recoveredkey
The certutil.exe command also performs the necessary decryption for the recovered key. The following command will save the key in a PKCS#12 file named recover.pfx and protect the file with a password for which the key recovery agent running certutil.exe is prompted twice:
certutil -RecoverKey recoveredkey recover.pfx
The key recovery agent can send the PKCS#12 file to the user and import the file into the user’s certificate store by launching the Certificate Import Wizard. The recovery agent types the filename at the command line or double-clicks the file in Windows Explorer. To successfully import the certificate, the key recovery agent must communicate the password selected (e.g., by phone) to protect the PKCS#12 file.
Archiving and recovering private keys is a security function, one that you can and should audit. I recommend periodically reviewing audit logs for key recovery agent operations and matching them to user requests. You’ll need to build a process to support the necessary auditing. To generate audit events of archival and recovery operations, right-click the CA in the Certification Authority snap-in, select Properties, click the Auditing tab, and select Store and retrieve archived keys. As key archival and recovery operations take place, details are written to the Security log.
Delta CRLs
CRLs publish details about revoked certificates. You might need to revoke certificates because the owner believes that the private key has been compromised or because the owner is no longer allowed access to a system that uses certificate-based authentication. In Win2K Certificate Services, CRLs must be downloaded to clients in their entirety. In large environments, CRLs can grow to a size that becomes unmanageable and difficult to download each time the client needs to check the CRL. In Windows 2003, Certificate Services clients can download a full CRL, then download changes, or deltas, to the CRL until the full CRL is republished.
You revoke certificates by using the Certification Authority snap-in, right-clicking a certificate, selecting All Tasks, then selecting Revoke Certificate. As certificates are revoked, Certificate Services manages the full and delta CRLs. Clients will download the full CRL if they don’t have one or if it has expired. The next time the client needs a CRL, the client can download a delta CRL. The default expiration period for a full CRL is one week after it’s published; the default expiration period for a delta CRL is one day.
Windows 2003 Certificate Services: A Robust PKI
Although I’ve discussed several key Windows 2003 Certificate Services features, I’ve barely scratched the surface of what Certificate Services offers. Additional new features include qualified subordination, enhanced auditing, and separation of roles. Together, these features make Windows 2003 Certificate Services a robust PKI suited to the enterprise. For more information about Windows 2003 Certificate Services, including links to white papers and downloads, visit http://www.microsoft.com/windowsserver2003/ technologies/pki/default.mspx.
John Howie ([email protected]) is the director of the World Wide Services and IT Technical Community for Security at Microsoft. He has more than 15 years of experience in information security and is a CISA, a CISM, and a CISSP.