Learn how to implement Microsoft Certificate Services
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.