Windows 2000 comes with a host of new security features, such as the Encrypting File System (EFS), smart card support, and IP Security (IPSec) through encryption. To fully use these new features, you need to deploy a public key infrastructure (PKI). A PKI has been described as everything from a silver bullet to a political quagmire that's a nightmare to implement. As is usually the case with complex technologies, the truth is somewhere in between: A well-designed and rolled out PKI can help you secure many parts of your Win2K environment, but it will also make you rethink how you manage your users and computers. For a smooth PKI deployment, you need to be familiar with the role of a PKI, some of the design concerns and decisions you face when you deploy a PKI, how to install and configure the appropriate services, and routine ongoing tasks.
The Role of the PKI
The term public key infrastructure is somewhat misleading because most PKIs don't just manage keys. (I won't discuss those PKIs that deal exclusively with keys.) The PKI's role is to issue and manage certificates, which are used to uniquely identify real-world objects such as users or computers. A typical PKI has four components: the Certification Authority (CA), which issues and revokes certificates; the Registration Authority (RA), which lets entities such as users or computers request certificates; the certificate store, which holds copies of issued certificates; and the certificate revocation list (CRL), which holds details about certificates that are no longer valid.
As its name suggests, a PKI is based on the principles of public-key, or asymmetric, encryption. When an entity requests a certificate, a public/private key pair is generated locally. The public key, along with information about the requesting entity and the certificate's purposes, is sent to the RA. When the CA issues the certificate, this information—along with an optional legal policy statement, the dates between which the certificate is valid, and information about the issuing CA—is stored as attributes in the certificate. Although the certificate is usually public knowledge, the private key must be secured. If the private key is compromised, you must revoke the certificate and a new certificate must be requested. A CA can issue many certificates to one entity, and each certificate can serve one or more purposes. If the certificate conforms to the X.509v3 standard, the certificate stores information about its potential uses.
Certificates, Security, and Trust
Certificates enhance application security in two ways: Certificates offer assurance that any entity using a certificate is what it claims to be, and they provide a public key that can be used to encrypt information that only the associated private key can decrypt. Trust in a certificate's legitimacy is derived from the trust that systems and applications place in CAs.
When a CA issues a certificate, the certificate is signed with the private key that complements the public key in the certificate that identifies the issuing CA. When an entity presents a certificate to an application, the signature is validated with the public key in the issuing CA's certificate. If an unknown CA issued the certificate or the certificate has been altered, the signature can't be validated and the certificate is rejected.
For this approach to work, CAs must be trusted and copies of their certificates must be available. As a convenience, Microsoft distributes copies of certificates for trustworthy CAs with Win2K and Microsoft Internet Explorer (IE), and you can install other certificates manually. When an entity presents a certificate to an application, such as a Web browser, the application examines the certificate's validity dates to make sure that the certificate hasn't expired and checks the CA's published CRL to verify that the certificate hasn't been revoked. A certificate can be revoked for many reasons—for example, if the certificate doesn't correctly identify the entity to which it was issued or if the CA's issuing certificate or the associated private key has been compromised. (If the certificate or the private key has been compromised, you must obtain a new certificate for the CA, then revoke and reissue all certificates that the CA issued and signed with the compromised certificate or private key.)
After you've established the certificate's legitimacy, you need to take a further step to guarantee that its rightful owner is using it. One method involves checking whether an attribute within the certificate matches a verifiable value (e.g., if you point your browser to https://www.microsoft.com but the certificate returned was issued for some other URL, you know to distrust the Web site). Another method involves trusting the entity that presents the certificate but encrypting all data sent with the public key. Intruders can use someone else's certificate, but without the associated private key, they can't decrypt the data.
Installing and Configuring Microsoft Certificate Services
Microsoft distributes its PKI, called Certificate Services, with server versions of Win2K. Third-party PKIs, such as Baltimore Technologies' UniCERT, support enhanced Win2K security. However, I recommend that you use only Certificate Services within a Win2K environment unless an overwhelming business case prevents you from doing so.
Before you install Certificate Services, you need to design your infrastructure carefully. You must determine which services your PKI will support and which entities will be able to obtain certificates, how they'll obtain them, and for what reason. When you install Certificate Services, you create a CA. Microsoft's PKI supports two types of CAs: an Enterprise CA, which is integrated with Active Directory (AD) services, and a Standalone CA, which isn't. Both types of CAs support all the enhanced security features in Win2K, with the exception of smart card logon support, which requires an Enterprise CA because certificates are mapped to user accounts in the AD.
One advantage of choosing an Enterprise CA over a Standalone CA is automated approval of certificate requests and security through ACLs on certificate templates. You can create entries in the ACL that protects a template to explicitly grant or deny users and groups permission to obtain certificates. Because a Standalone CA doesn't use templates, by default, it must place requests for certificates in a queue pending the CA administrator's approval. You can configure a Standalone CA to automatically approve certificate requests, but doing so creates an insecure PKI because it removes the trust that only legitimate entities have obtained certificates. Although Microsoft recommends that you install Certificate Services as an Enterprise CA, you might choose to install a Standalone CA if you intend to programmatically extend Certificate Services, if you want more control over the certificate request and issuance process, or if entities that will be requesting certificates aren't part of your Win2K environment (e.g., UNIX Web servers and users).
Certificate Services is extremely flexible and lets you create CA hierarchies comprising root and subordinate CAs. A root CA is considered special because it uses a self-signed certificate. Because no third party vouches for the PKI's integrity, you must determine whether it's trustworthy. A parent CA issues and signs a subordinate CA's certificate, which creates a certificate trust list (CTL). When an entity presents a certificate, the receiving application must validate the entire CTL before accepting the certificate. This process ensures that each subordinate CA is legitimate and that the topmost subordinate CA has a certificate that a trusted root CA has issued. In an extremely simple single-domain environment, you can install just a root CA. In most environments, however, and especially in those that need stronger security, you must create subordinate CAs to issue and manage certificates and use the root CA only to issue certificates for subordinate CAs, powering the root CA off when it's not in use. You can create multiple CA hierarchies within your organization or even within a single domain, but I recommend that you strive to keep the number manageable. You might find it logical to place root CAs as high up in your domain tree as possible, although you're not required to do so, and to place subordinate CAs in subdomains. You can delegate au-thority to manage CAs by setting ACLs on each subordinate CA. I recommend that you delegate authority to user accounts in the same domain in which the CA resides. Everyone need not trust CA hierarchies. With Group Policy, you can control which hierarchies each domain trusts by distributing each hierarchy's root CA certificate, as Figure 1 shows.
Installing a CA is a simple process. Using the Control Panel Add/Remove Programs applet, you can start the Windows Components Wizard, which Figure 2 shows. Selecting Certificate Services displays a dialog box warning you that after Certificate Services is installed, the machine can't be renamed and can't join or leave a domain. Heed this warning and plan carefully where you place CAs in your Win2K environment. Dedicate a member server in your domain to function as a CA, a server well equipped with memory and disk space. For security reasons, you should never install a CA on a domain controller (DC) or on a server that's visible outside your organization because Certificate Services will use remote procedure call (RPC) endpoints and Microsoft Internet Information Services (IIS) 5.0 to give applications and users access to services.
Clicking Next displays a dialog box that prompts you for the type of CA you want to install, as Figure 3 shows. Plan to install your hierarchy from the top down. The root CA in a hierarchy will issue itself a self-signed certificate, but subordinate CAs request certificates from their parent CAs. If the root or parent CA is unavailable, you can create a certificate request for a subordinate CA and store it to a file, submit it later when the root or parent CA is running, and manually install the issued certificate. If you select the Advanced options check box, you'll be prompted later to choose among such options as Cryptographic Service Providers (CSPs), algorithms, and key lengths. Unless you have specific requirements, use hardware cryptographic accelerators, or are restoring a CA, the default settings will probably be acceptable, so I recommend that you not select this check box because you could inadvertently weaken your PKI's security.
After you have chosen the type of CA you want to install and clicked Next, you'll be prompted for identifying information, as Web-exclusive Figure 1 shows. Make sure you use the available fields to accurately describe your CA because the information you enter becomes attributes of the certificate issued for the CA and will be viewable. If you create a root CA, you must also decide how long its certificate will be valid. The length you specify will be reflected in every certificate that the root or a subordinate CA issues. You can find different recommendations for how long a certificate should be valid; your decision about the length of a certificate's validity should reflect factors such as the certificate's use and the length of its keys. In general, the longer the keys or the less critical the systems, the longer the validity period can be. For a typical Win2K environment, in which certificates are used only within the organization, a period of between 2 and 4 years is generally acceptable.
If you install a subordinate CA, you'll be prompted to obtain a certificate for it, as Figure 4 shows. The CA that issues the certificate will be the parent of the new CA. You can either request a certificate online or save the request to a file and submit it manually later. In an Enterprise CA hierarchy, an online request will be processed immediately; in a Standard CA hierarchy, you must wait for the parent CA's administrator to approve the request before you can retrieve the issued certificate and install it.
After the CA has been commissioned, I recommend that you use the Microsoft Management Console (MMC) Certification Authority snap-in to immediately back up the CA. Right-click the CA, select All Tasks from the menu, then select Backup CA. When the Certification Authority Backup Wizard appears, click Next to get a screen on which you can specify what components of the CA to back up, as Figure 5 shows. The wizard will also prompt you for a password to protect the backup.
You must be sure to record the password and store it in a safe place. If you suffer a system failure and either the root or a subordinate CA is lost, you'll need to restore the CA. Otherwise, issued certificates will be rejected as invalid.
Issuing Certificates and Ongoing Tasks
After you create your PKI hierarchy, you might need to distribute the certificate of the root CA by using the Group Policy Editor (GPE). You can also save a copy of the certificate to a file and import the certificate file manually onto systems that trust the hierarchy.
Users can request and install certificates to use with EFS, to secure email, and to identify themselves to remote systems through the Web Enrollment pages that are automatically installed with Certificate Services or by using the Certificate Request wizard. The Web Enrollment pages are installed in a virtual directory called CertSrv, as Web-exclusive Figure 2 shows. You can use the MMC Active Directory Sites and Services snap-in to restrict what types of certificates users can request by granting or denying Enroll permissions on certificate templates.
Occasionally, you'll need to revoke a certificate, perhaps because a user has left your organization, a computer has been decommissioned, or you suspect that a private key has been compromised. You can revoke a certificate with the Certification Authority snap-in by selecting a certificate in the folder Issued Certificates, right-clicking the certificate, and selecting Revoke Certificate from the Tasks submenu. You also need to publish the CRL frequently. By default, the CRL is published weekly, but you can change the frequency by right-clicking Revoked Certificates in the Certification Authority snap-in and selecting Properties. Consider increasing CRL publication frequency if you revoke certificates often or need strict security. You can also manually publish a CRL by right-clicking Revoked Certificates, selecting All Tasks, then selecting Publish.
In future articles, I'll discuss security features that make use of certificates and PKIs. I'll also discuss how to install and configure the appropriate services to leverage them.
