Lesson 1: Introducing Certificates | MCSE Training Kit(c) Microsoft Windows 2000 Accelerated 2000

In this lesson, you learn about digital certificates and Microsoft Windows 2000 Certificate Services. Certificates are a very important part of Microsoft's PKI. You also learn about certificate authorities (CAs) supported by Windows 2000 Certificate Services.

After this lesson, you will be able to

Define a certificate
Explain the components of a certificate
Describe the use of certificates
Explain the difference between enterprise and standalone CAs

Estimated lesson time: 25 minutes

Overview of Certificates

A certificate (digital certificate, public key certificate) is a digital document that attests to the binding of a public key to an entity. The main purpose of a certificate is to generate confidence that the public key contained in the certificate actually belongs to the entity named in the certificate. As illustrated in Figure 15.1, certificates play a fundamental role in the Microsoft PKI.

Figure 15.1 Certificate Services integrated with Active Directory directory service and distributed security services

A certificate may consist of a public key signed by a trusted entity. However, the most widely used structure and syntax for digital certificates is defined by the International Telecommunications Union (ITU) in ITU-T Recommendation X.509. Figure 15.2 illustrates a certificate that can be used to validate the sender of an e-mail message.

Figure 15.2 Sample certificate

An X.509 certificate contains information that identifies the user and provides information about the organization that issued the certificate. The information provided includes the serial number, validity period, issuer name, issuer signature, and subject (or user) name. The subject can be an individual, a business, a school, or some other organization, including a CA.

How Certificates Are Created

Certificates are issued by a CA, which can be any trusted service or entity willing to verify and validate the identities of those to whom it issues certificates, and the association of those identities with specific keys. Companies may issue certificates to employees, schools may issue certificates to students, and so on. Of course, a CA's public key must be trustworthy or the certificates it issues will not be trusted. Because anyone can become a CA, certificates are only as trustworthy as the authority that issues the underlying keys. The following six steps describe the process of requesting and issuing a certificate.

Generating a key pair. The applicant generates a public and private key pair or is assigned a key pair by some authority in his or her organization.
Collecting required information. The applicant collects whatever information the CA requires to issue a certificate. The information could include the applicant's e-mail address, birth certificate, fingerprints, and notarized documents—whatever the CA needs to be certain that the applicant is who he or she claims to be. CAs with stringent identification requirements produce certificates with high assurance. That is, their certificates generate a high level of confidence. CAs themselves are said to be of high, medium, or low assurance.
Requesting the certificate. The applicant sends a certificate request, which consists of his or her public key and the additional required information, to the CA. The certificate request may be encrypted using the CA's public key. Many requests are made using e-mail, but requests can also be sent by postal or courier service, for example, when the certificate request itself must be notarized.
Verifying the information. The CA applies whatever policy rules it requires to verify that the applicant should receive a certificate. As with identification requirements, a CA's verification policy and procedures influence the amount of confidence generated by the certificates it issues.
Creating the certificate. The CA creates and signs a digital document containing the applicant's public key and other appropriate information. The signature of the CA authenticates the binding of the subject's name to the subject's public key. The signed document is the certificate.
Sending or posting the certificate. The CA sends the certificate to the applicant or posts the certificate in a directory as appropriate.

How Certificates Are Used

Certificates are used to generate confidence in the legitimacy of specific public keys. A certificate must be signed with the issuer's private key; otherwise, it is not a certificate. Therefore, the issuer's signature can be verified using the issuer's public key. If an entity trusts the issuer, the entity can also have confidence that the public key contained in the certificate belongs to the subject named in the certificate.

Enterprise and Standalone CAs

Certificate Services includes two policy modules that permit two classes of CAs: enterprise CAs and standalone CAs. Within these two classes, there can be two types of CAs: a root CA or a subordinate CA. The policy modules define the actions that a CA can take when it receives a certificate request, and can be modified if necessary.

CAs are usually organized in a hierarchy in which the most trusted CA is at the top. The Windows 2000 PKI assumes a hierarchical CA model. There may be multiple disjointed hierarchies; there is no requirement that all CAs share a common top-level parent.

Enterprise CAs

In an enterprise, the enterprise root CA is the most trusted CA. There can be more than one enterprise root CA in a Windows 2000 domain, but there can be only one enterprise root CA in any given hierarchy. All other CAs in the hierarchy are enterprise-subordinate CAs.

An organization should install an enterprise CA if it will be issuing certificates to users or computers within the organization. It is not necessary to install a CA in every domain in the organization. For example, users in a child domain can use a CA in a parent domain. Enterprise CAs have a special policy module that enforces how certificates are processed and issued. The policy information used by these modules is stored centrally in Windows 2000 Active Directory directory service.

NOTE
Active Directory and a DNS server must be running prior to installing an enterprise CA.

Standalone CAs

An organization that will be issuing certificates to users or computers outside the organization should install a standalone CA. There can be many standalone CAs, but there can be only one standalone CA per hierarchy. All other CAs in a hierarchy are either standalone subordinate CAs or enterprise subordinate CAs.

A standalone CA has a relatively simple default policy module and does not store any information remotely. Therefore, a standalone CA does not need to have Microsoft Windows 2000 Active Directory available.

Types of CAs

The setup requirements for the four types of CAs available from Certificate Services are described in the following sections.

Enterprise Root CA

An enterprise root CA is the root of an organization's CA hierarchy. An organization should set up an enterprise root CA if the CA will be issuing certificates to users and computers within the organization. In large organizations, the enterprise root CA is used only to issue certificates to subordinate CAs. The subordinate CAs issue certificates to users and computers.

The enterprise root CA requires the following:

Windows 2000 Domain Name System (DNS) service
Windows 2000 Active Directory directory service
Administrative privileges on all servers

Enterprise Subordinate CA

An enterprise subordinate CA is a CA that issues certificates within an organization but is not the most trusted CA in that organization; it is subordinate to another CA in the hierarchy.

The enterprise subordinate CA has the following requirements:

It must be associated with a CA that will process the subordinate CA's certificate requests. This could be an external commercial CA or a standalone CA.
It must use Windows 2000 DNS Service.
It must use Windows 2000 Active Directory directory service.
It must have administrative privileges on all servers.

Standalone Root CA

A standalone root CA is the root of a CA trust hierarchy. The standalone root CA requires administrative privileges on the local server. An organization should install a standalone root CA if the CA will be issuing certificates outside of the organization's enterprise network, and the CA needs to be the root CA. A root CA typically only issues certificates to subordinate CAs.

Standalone Subordinate CA

A standalone subordinate CA is a CA that operates as a solitary certificate server or exists in a CA trust hierarchy. An organization should set up a standalone subordinate CA when it will be issuing certificates to entities outside the organization.

The standalone subordinate CA has the following requirements:

It must be associated with a CA that will process the subordinate CA's certificate requests. This could be an external commercial CA.
It has administrative privileges on the local server.
Certificate enrollment is the process used for obtaining a digital certificate.

Lesson Summary

In this lesson, you learned that certificates are fundamental elements of the Microsoft PKI. Certificates enable users to use smart card logon, send encrypted e-mail, sign electronic documents, and so forth. Certificates are issued, managed, renewed, and revoked by CAs. In this lesson, you also learned how to install and configure certificates.