Last week, I discussed the public key infrastructure (PKI) and its uses in a Windows 2000 environment. I mentioned that Win2K includes Certificate Services, which lets you create your own Certificate Authority (CA). The CA is responsible for issuing the digital certificates that form the backbone of the public key infrastructure (PKI). Creating your own CA hierarchy is appropriate when you have control of the resource you want to protect and you have the desire and the ability to manage which users get the necessary credentials to access those resources. Conversely, a commercial CA is your only viable option when you either don’t have control over the resources you want to protect or the ability to verify credentials of those seeking certificates.

Once you decide that you want to provide your own CA, you can use the Control Panel Add/Remove Programs applet to install Certificate Services. Choose Add/Remove Windows Components, then click Certificates Services to launch an installation wizard that walks you through the CA configuration process. Let's review some of the configuration options you'll face as you configure your CA.

Certificate Hierarchies
Certificate hierarchies establish your "path of trust" throughout an organization. As the most trusted CA within your organization, the root CA issues certificates to confirm the validity of other CAs, known as subordinate CAs. Subordinate CAs can issue certificates that serve various purposes (e.g., for smart cards, Web authentications). Because of its importance, the root CA typically issues certificates to subordinate CAs only—not to end users. You must vigilantly secure the root CA machine; otherwise, someone might compromise the root CA's certificate store or the root CA might issue certificates to unauthorized machines—both of which would undermine your entire enterprise's PKI infrastructure.

Standalone vs. Enterprise CAs
In addition to deciding whether to configure a root or a subordinate CA, you must also decide whether yours will be a standalone or an enterprise CA. Enterprise CAs require Active Directory (AD), which identifies entities requesting certificates and determines whether they have the appropriate permissions. You should use enterprise CAs if you plan to issue certificates to users and computers within your organization only. You should use standalone CAs, which don't require AD, to issue certificates to users and computers outside of your organization. Standalone CAs are useful if you want to issue certificates to vendors or partners that need secure access to your company resources.

Certificate Revocation List
In addition to issuing certificates, the CA is also responsible for maintaining and publishing the certificate revocation list (CRL). Each certificate includes an expiration date. However, using the CRL, you can invalidate certificates before they expire, which might be necessary if a certificate becomes compromised or if you want to revoke access from a certificate holder.

Next week, we'll discuss implementing PKI and working with Web services to provide client and server authentication and encryption.