As security becomes more and more important in a network environment, client workstations and servers need some way to securely pass data. The most common way to do this is through the use of digital certificates. Although you can use third-party certificate issuers to create and issue digital certificates, you can, instead, use Certificate Services on your Windows 2000 server. Using Certificate Services introduces a whole new level of complexity to your Windows 2000 server, along with some new terms and concepts. However, in the end, it’s worth the extra effort. In this Daily Drill Down, I’ll introduce you to the terms and concepts in preparation for ultimately deploying Certificate Services.
What is a certificate?
A certificate is a digitally signed document that works as a part of public key infrastructure (PKI). The certificate contains a public key and the name of the subject, such as a directory name, e-mail name, and/or domain name service (DNS) name. By signing the certificate, the Certification Authority verifies that the private key associated with the public key in the certificate is in the possession of the subject named in the certificate. You can create your own Certification Authorities within your enterprise, or you can use third-party companies such as Versign that provide commercial Certification Services. For more information about certificates and PKI, see the Daily Drill Down “Understanding and selecting authentication methods.”
Some Certificate Services terminology
Before you deploy Certificate Services on your Windows 2000 server, you should understand some of the basic vocabulary associated with it. Although there are many new terms to learn, the following are some of the more prominent ones:
- Policy modules
- Exit modules
- Certificate Trust List
- Certificate Revocation List
- Certificate Publishers
- Certificate Templates
Let’s take a brief look at each term.
A policy module is the set of instructions that guides the Certificate Authority (CA) in what to do when a new certificate is received. Policy modules are flexible and can be configured to automatically approve or reject a request or place it into a pending queue awaiting manual approval. Policy modules can be custom created using developer’s tools available on the Microsoft Web site. Policy modules are typically adjusted so that they modify the content of certificates issued by adding or removing extensions.
The standard Windows 2000 Server CA policy module performs the following tasks:
- It approves or marks incoming requests as pending, depending on what type of CA receives the request and any optional settings you configure.
- It adds (an optional) extension to the generated certificate that specifies where the Certificate Revocation List (CRL) for that CA is located.
- It adds (an optional) extension to the certificate that specifies how to find the issuing CA’s certificate—a necessary item when attempting to verify the validity of the certificate, as it must be verified all the way to its source.
The exit module specifies what the CA is to do after generating a certificate. One possible exit module action is e-mailing the certificate to the requestor and placing it in the Active Directory store or any other specified location. The standard Windows 2000 Server CA exit module is configured to publish generated certificates either to a specified file path or Active Directory, or both. The standard exit module is also responsible for publishing CRLs for the CA in the location that you specify.
Certificate Trust List
The Certificate Trust List (CTL) is a list of Root Certification Authorities that are designated as being reputable (trustworthy) for a designated purpose, such as client identification, securing e-mail, or file encryption using EFS file encryption. A Windows 2000 Server CA comes with a prepopulated CTL thanks to Microsoft, but you can add or remove certificates from your CTL as desired. The CTL is crucial to being able to trace a certificate from the end user all the way back to the root CA. Figure A shows how your Certificate Authority setup might look in a large organization.
|Here is an example of the Certificate Authority hierarchy.|
Certificate Revocation List
The Certificate Revocation List (CRL) is maintained by each CA and specifies the list of certificates that are no longer valid. This is a critical part of verifying the validity of a certificate. CRLs, like user certificates, are digitally signed by the issuing CA, and thus can be verified by using the issuing CA’s certificate. A CRL will only contain those certificates that have been revoked and have not expired. If a certificate is expired (past it’s Valid To date), it cannot be used anyway, so inclusion on the CRL is not required.
A certificate is immediately added to the CRL as soon as you revoke it; however, the CRL is not published immediately. CRLs are refreshed according to the schedule that you configure and can be published to Active Directory, a URL for Web-based viewing, or to a CRL file for transfer to another (nonconnected) CA. By default, CRLs are published weekly, although you can configure any amount of time between one hour and 9999 years.
A Certificate Publisher serves the same purpose as any other type of publisher: It makes information accessible to those who want it. In this case, the Windows 2000 Server Certificate Publisher makes certificate and CRL information available to clients using whichever mechanism they want to use. By default, Active Directory is the Certificate Publisher for Windows 2000, although you can opt to change this should you need to.
A Certificate Template is exactly what it sounds like: a predefined set of attributes and extensions that can be used to easily issue a newly requested certificate. Templates simplify the requesting and issuing process. A requestor can pick from the available options and receive the certificate he or she needs.
Because templates are objects, you can specify which groups and users can use templates to create new certificates—something you will want to look into further as you get going in your Windows 2000 Certificate Services deployment. The only limitation when using Certificate Templates is that you cannot change or control the content in them—you must work with them as Microsoft has delivered them.
Each template is different from the others. Windows 2000 Certificate Services contains these 19 templates:
- Authenticated session
- Basic EFS
- Code Signing
- Domain Controller
- EFS Recovery Agent
- Enrollment Agent
- Enrollment Agent (Offline request)
- IPSec (Offline request)
- Router (Offline request)
- Smart Card Logon
- Smart Card User
- Subordinate Certification Authority
- Trust List Signing
- User Signature Only
- Web Server
Certificate Authority types
There are two different types of Certificate Authorities: Enterprise and Stand-Alone. The type of CA you configure and install will determine to whom you can issue certificates and how these certificates can be used. Although the functional differences between the two types of CAs is very small (only a matter of using a different Policy Module), the operational characteristics of each type is much different. You will want to carefully consider all of the information available to you before choosing one type of CA over the other.
An Enterprise CA is part of an overall enterprise security solution. It is used to issue and revoke the certificates of Subordinate CAs and end users, although the job of dealing with end users (and other computers) is usually best left to the Subordinate CAs themselves. Since an Enterprise CA is part of an “enterprise” solution, it requires Active Directory to be running in the domain, but it provides you with the ability to use the certificates it issues as positive identification in the domain.
A Stand-Alone CA does not require Active Directory, as it is designed to operate as a server that is disconnected from the rest of the Windows 2000 domain. The typical usage of a Stand-Alone CA is to issue certificates to users outside of your organization who are not participating in Active Directory. Stand-Alone CAs are often used for Internet applications. Unlike an Enterprise CA, the Certificates and CRLs associated with a Stand-Alone CA are not automatically published anywhere—you must manually do this yourself.
Certificate Authority roles
Using the two types of CAs, you can create four distinctly different roles in which a CA might serve. Again, the distinction between the roles is usually based on whether the CAs participate in Active Directory. The four different roles a CA can serve are:
- Enterprise Root Certificate Authority: As seen in Figure A (above), the Enterprise Root CA sits at the top (root) of the enterprise certificate chain. The Enterprise Root CA issues certificates to the Enterprise Subordinate CAs, which in turn issue certificates to users and other computers. Due to its position at the root of the certificate hierarchy, all certificates within the organization can ultimately be traced back to the Enterprise Root CA. Enterprise Root CAs sign their own certificates, thereby asserting their place at the root of the chain.
- Enterprise Subordinate Certificate Authority: Also shown in Figure A, the Enterprise Subordinate CA sits directly below the Enterprise Root CA in the certificate chain. Enterprise Subordinate CAs typically field requests from network clients (users and computers) and fulfill these requests based on the configuration chosen during CA setup. Enterprise Subordinate CAs can also issue certificates to other Enterprise Subordinate CAs should the need arise.
- Stand-Alone Root Certificate Authority: A Stand-Alone Root CA performs the same basic functions as the Enterprise Root CA, except that it does not participate in Active Directory by default. Stand-Alone Root CAs can be easily moved around as required, something that an Enterprise CA cannot. Most importantly, Stand-Alone Root CAs can be used to issue certificates and then be locked away in a secure location to prevent possible security breaches inherent with being connected to the network.
- Stand-Alone Subordinate Certificate Authority: The Stand-Alone Subordinate CA works directly under the Stand-Alone Root CA and can also participate in Active Directory, but it does not have to. Certificates from a Stand-Alone Subordinate CA are only issued to users, as computers will not need them if they are not participating in Active Directory. Stand-Alone Subordinate CAs also benefit from the ability to issue certificates and then be taken off the network and placed in a secure location when not in use.
There you have it, on good authority
Certificates can help improve security on your network, but you don’t have to rely on a third-party certificate issuer. You can deploy Certificate Services on your Windows 2000 server instead. Armed with your knowledge of Certificate Services terminology and background, you are now ready to set up your first CA with no problems.