A PKI allows client and server applications to gain trust in each other's authentication credentials in a highly scalable and efficient manner. Applications can then employ those credentials to perform strong authentication and make use of end-to-end confidentiality and integrity services.

To show where a PKI might prove useful, let's look at the case study of a company called Exploration Air that wants its customers to have access to an internal Web server. Exploration Air expects a number of users in each customer organization to securely log on to the Web server. The challenge lies in managing authentication credentials for all those external users. If Exploration Air uses passwords, their IT department is expected to somehow identify those users, as well as process password changes for them. This solution does not scale well, and for a large number of users it becomes unmanageable. Attackers can also guess passwords, and passwords might not offer strong enough authentication for high-value transactions.

With a PKI, Exploration Air can delegate the issuing of authentication credentials to certification authorities run by the customers themselves, or to a commercial certification authority. This way, the company needs to configure its Web server only to trust those authorities. Those credentials also offer strong authentication because they cannot be guessed.

Now let's say that Exploration Air wants to exchange secure e-mail with users of the same customers. A password infrastructure is actually incapable of offering end-to-end secure e-mail among multiple users, and no such implementations exist. Technically, the servers that hold the passwords would have to get involved for every recipient, for every e-mail sent. The servers would also have access to either the contents of the e-mail or the secret key material that protects the confidentiality or integrity of messages. In contrast, public key–enabled e-mail clients can directly exchange secure e-mail using the authentication credentials of their users.

Windows 2000 PKI Offerings

Windows 2000 offers a comprehensive mechanism for issuing certificates that allows organizations to take full advantage of the PKI technology. Microsoft's adherence to industry standards means Windows 2000 will interoperate with any third-party public key–enabled software.

Windows 2000 will work equally well with certificate services offered by other PKI vendors. Windows 2000 can also participate in Internet-based commercial PKIs, such as the one offered by VeriSign.

Windows 2000 offers the following PKI features:

A number of public key–enabled applications and services: Internet Information Services, Internet Explorer, Microsoft Outlook and Microsoft Outlook Express, Encrypted File System (EFS), IPSec, and smart card logon.

Active Directory, which you can use as a publication point for certificates and certificate revocation lists (CRLs).

Microsoft Certificate Services, which enable an organization to issue its own certificates and implement its own PKI.

Support for smart cards in Windows 2000, which you can use for key storage and cryptographic operations (in addition to logons).

Commercial certification authority (CA) certificates preloaded in Windows 2000, which enable users and computers to participate in existing PKIs on the Internet.

Public Key policies in the Group Policy, which allow administrators to control the external CAs that users and computers can trust.

These features are implemented on industry standards such as X.509, LDAP, SSL/TLS, S/MIME, IPSec, and the Public Key Extensions of Kerberos, enabling interoperability with third-party applications and PKIs.

Top Of Page
Cryptographic Background

Cryptography provides the following security services to the operating system and applications. In this chapter, we use the term entity to refer to both users and servers.

Confidentiality

Confidentiality ensures that only authorized entities have access to information. This service is particularly useful when you must store sensitive data in vulnerable locations such as laptops, or transmit it across vulnerable networks, such as the Internet or an outsourced WAN. Cryptography then helps by turning big secrets (your data) into small secrets (the cryptographic keys). Keys are easier secrets to manage, especially since they can be exchanged in advance.

Entity Authentication

The entity authentication service proves one entity's identity to another, and it is commonly implemented by demonstrating the possession of a secret. Cryptography helps by keeping that secret private during the authentication process.

Data Integrity

The integrity or data authentication service assures that a chunk of data did indeed originate from an entity and that it remains unaltered. Cryptography helps by binding the data to its originator. In some contexts, integrity might be defined only as ensuring that data remain unaltered.

Nonrepudiation

Nonrepudiation enables users to digitally sign electronic documents and be legally bound by the signatures, as if those signatures were handwritten. Cryptography can provide evidence that a user signed a document, but a lot of conditions need to be met for a court to consider this legally binding. Some countries and some U.S. states legally recognize digital signatures. You can find more information on this issue at http://www.mbc.com/ecommerce.html and http://rechten.kub.nl/simone/ds-lawsu.htm.

PKI Basics

Entities can have one or more private-public key pairs and associated public key certificates. A certificate is a statement issued by a certification authority according to a policy that binds an entity's public key to its name for a period of time. (You'll learn more about policies later in the chapter.) Another entity that trusts this CA also trusts that the public key belongs to the named entity.

When entity A is presented with a certificate by entity B, entity A can tell from the certificate name that the certificate belongs to a legitimate user of the system. Entity B proves he or she is the legitimate holder of the certificate by proving his or her knowledge of the associated private key. Entity A can optionally check the certificate's current validity by looking it up on the CA's CRL.

Furthermore, entities A and B can now use end-to-end confidentiality and integrity services without the cooperation of any third entity. For example, users can exchange secure e-mail and securely access Web content on an intranet.

For certain applications, this security model presents some advantages when compared to a security model that forces all entities to share secret keys with central authorities. One advantage is that users and computers can authenticate thousands or millions of other entities in a scalable manner, without the immediate cooperation of a mediating server such as a Windows domain controller, a Kerberos Key Distribution Center (KDC), or a CA. For example, almost all Web browsers can authenticate a Web server bearing a certificate from VeriSign, a universally trusted commercial CA.

Another advantage to this model is that users and computers can efficiently use end-to-end security services between them, without the immediate cooperation of a mediating entity. For example, users can exchange confidential e-mail without sharing the contents or keys that protect the contents with mediating servers.

A third advantage is that private keys are typically 1024-bit-long strings and cannot be guessed the way that passwords can. Therefore, you can use certificates for strong authentication.

Finally, account databases need not store a secret for every user and computer. Active Directory actually stores hashed passwords for use by Kerberos and other authentication protocols.

Multiple CAs and Issuing Policies

An enterprise can have multiple issuing CAs to serve the different certificate needs of users and to implement different security policies.

Note that CAs also have a private-public key pair and the associated public key certificate. Multiple CAs are typically linked together in a hierarchy, with parent CAs issuing certificates to subordinate CAs. Trust in a CA implies trust in its subordinate CAs. Therefore, if you trust the root CA at the top of a hierarchy, you implicitly trust all CAs in it.

Users and computers are typically configured to trust root CAs. Therefore, they can efficiently authenticate entities bearing certificates from any subordinate CA. An organization's CA can even be certified by a universally trusted commercial CA, which could make the certificates it issues recognizable by other organizations.

The certification authority issuing policies we've mentioned so far describe a) how the CA identifies users and computer before issuing them a certificate; and b) what legal liabilities, if any, the CA accepts by issuing a certificate.

Policies, on the other hand, might be less important for certificates issued by an organization for internal use. A policy created for this situation could be equivalent to your policy for issuing user passwords. Policies are essential when you use certificates to communicate with other organizations—or when other organizations use them to communicate with you.

Policies are also essential when other organizations issue certificates to your organization and vice versa. Examples include having your own CA certified by a commercial CA, or issuing certificates to customers for use in an extranet application.

Top Of Page
Cryptographic Services

This section introduces some building blocks in cryptography and the security services they offer. If you are familiar with cryptography, feel free to skip this section.

Symmetric Cryptographic Algorithms

Symmetric cryptography is the classic form of cryptography. People have relied on it for thousands of years to keep messages private.

Symmetric cryptography works by transforming (encrypting) the plaintext (the original data) to ciphertext (the protected data) in a way that makes it infeasible to reverse the process without the full knowledge of the transformation function. For a number of reasons the secret transformation is split into a constant part, the cryptographic algorithm, and a variable part, the cryptographickey. The algorithm can be widely deployed in software or devices that use cryptography, and in general it is not assumed to be secret. Therefore, all security lies in keeping the key secret.

By definition, the reverse process uses the same key—hence the name symmetric cryptography. The decryption transformation turns the ciphertext back into the plaintext. The transformation is split into a decryption algorithm and the same cryptographic key.

Symmetric keys are either random blocks of data or are derived from user passwords, and are usually 40 to 128 bits in length. Symmetric algorithms use symmetric keys and a block algorithm such as DES, DESX, RC2, or RC4 to encrypt and decrypt raw data.

Asymmetric Cryptographic Algorithms

Asymmetric, or public key, cryptography also turns plaintext into ciphertext using an algorithm and a key. The difference lies in the use of a different decryption key, hence the name asymmetric.

The decryption (private) key and the encryption (public) key are related to each other, but the former cannot feasibly be derived from the latter. Therefore, the encryption key need not be kept secret, and can even be made public. Instead, users of public keys need to trust that a given key does belong to a particular owner. This issue is addressed by the process of certification (described later in the chapter). Security lies in keeping the private key secret.

Asymmetric keys are randomly chosen from a set that has certain properties specific to the asymmetric algorithm, so that two users are unlikely to generate the same keys. Key sizes commonly range from 512 to 4096 bits. Asymmetric cryptographic algorithms, such as RSA, encrypt symmetric keys in key exchange protocols and in hybrid cryptographic systems.

Asymmetric Signing Algorithms

You can also reverse the one-way relationship between asymmetric keys to sign data with a private key and verify the signature with the public key. This is because the signature could only have been feasibly generated with its associated private key. Asymmetric cryptographic keys are used for digital signatures and Challenge-Response authentication. Some common asymmetric algorithms include RSA and Digital Signature Algorithm (DSA).

Asymmetric Key Exchange

Some public key algorithms, notably Diffie-Hellman, can directly generate a shared secret, given two private-public key pairs. This is in contrast to exchanging a previously generated secret by protecting it with an asymmetric cryptographic algorithm.

As with asymmetric keys, these keys are randomly chosen from a set that has certain properties specific to the asymmetric algorithm, so that two users are unlikely to generate the same keys. Key sizes commonly range from 512 to 4096 bits.

Hashing

A hash function is one-way transformation that efficiently turns arbitrary-length data into fixed-length data, and given some data or its hash value, it is computationally infeasible to find some other data that will hash into the same value. Some applications also require the hash function to be collision-resistant, so that it is hard to find any two inputs with the same hash value.

Therefore, if two documents hash into the same value, we can be certain that they are identical. So when we want to efficiently or privately compare two pieces of data, we can compare their hash values. For example, we can verify that a message was delivered intact by comparing its hash value before and after delivery. And we can securely compare two secrets by comparing their hash values.

Hash algorithms are commonly used for digital signatures, passphrases, integrity protection (for tasks such as software distribution), and Challenge-Response authentication. Hash algorithms such as MD5 and SHA-1 commonly use hash values from 128 to 160 bits long.

Cryptographic Services

Windows 2000 combines the cryptographic building blocks to provide cryptographic services to applications. When more than one entity is involved, you can assume that shared and public keys have been exchanged.

Hybrid Encryption

Applications frequently employ hybrid or bulk encryption when they are required to apply a confidentiality service to shared data. This protocol assumes that the receiver has a private-public key pair and that the sender has obtained the public key.

A typical example is that of the SSL/TLS protocol used in secure Web browsing: The browser software (the initiator) is preloaded with some CA public keys, and the Web server (the receiver) has an asymmetric key pair and a certificate issued to itself from one of those CAs.

The browser then can generate a random symmetric key, encrypt it with the public key, and send it to the server. This is now a shared secret key, and the operation is essentially a key exchange. Either party can now use the key to encrypt data with a symmetric encryption algorithm and send the data to the other party.

The symmetric encryption is used because asymmetric algorithms are many times slower than symmetric algorithms and therefore not typically used for bulk encryption of data.

SSL/TLS, S/MIME, secure e-mail in Microsoft Exchange, and EFS all use hybrid encryption to provide a confidentiality service.

Digital Signatures

Digital signatures offer a data authentication service, ensuring that a message did indeed originate from an entity, and that it is unaltered.

Digital signatures are also hybrid in nature, again for efficiency reasons: A hash function is first applied to the data to be signed, producing a hash value or message digest. Then an application applies the asymmetric signing algorithm to the digest, using the signer's private/signing key. The digital signature consists of this signed hash, and is appended to the message.

The verifier repeats the first step to obtain the hash of the message he or she received, and then applies the asymmetric signing algorithm to the digital signature, using the signer's public/verifying key, which yields the original hash, and compares the two.

Any changes to the received message will change its hash. Also, any intentional changes to the signed hash are computationally infeasible without access to the private/signing key.

Digital Signatures offer data authentication services to Authenticode, S/MIME, and secure e-mail in Microsoft Exchange.

Message Authentication Codes

Message Authentication Codes, or MACs, offer a data authentication service similar to digital signatures, but use a shared symmetric key. MACs are only meaningful to those who possess the signing/verifying key.

One category of MACs called HMACs uses keyed hashes. HMACs concatenate a symmetric key with the message before hashing. Therefore, only the key holders can compute the message digest.

Another method for calculating MACs involves symmetrically encrypting the message with a block cipher in cipher block chaining (CBC) mode. In that mode, each plaintext block is combined (XORed or binary added) with the previous ciphertext. The final ciphertext is the MAC. The most common implementation uses the DES algorithm in CBC mode.

MACs provide data authentication services to SSL/TLS and IPSec.

Challenge-Response Authentication

Challenge-Response authentication mechanisms offer an entity authentication service. They authenticate one entity to another by proving knowledge of a credential (shared secret or private-public key pair) while keeping that credential private.

The authenticator challenges the authenticated party with a challenge, or nonce. The authenticated party responds with a cryptographic function of both nonce and the credential. The authenticator can then verify the response using the shared secret or corresponding public key.

When the credential is a shared secret, the cryptographic function can be a symmetric encryption algorithm or a hash function (or a MAC). If the credential is a private-public key pair, an asymmetric signing algorithm is used.

Challenge-Response authentication protocols include NTLM, SSL/TLS client authentication, digest authentication in Microsoft Internet Explorer and Microsoft Internet Information Services (IIS), and Point-To-Point Tunneling Protocol (PPTP).

Certification and Key Exchange

To use any kind of cryptographic services with more than one entity, these entities first need to share a secret or each other's public keys to authenticate one another.

Note: Authentication is necessary to protect against active "man-in-the-middle" attacks, in which an attacker masquerading as one of the legitimate parties can insert messages into the communications channel. Without authentication, it is still possible to preserve confidentiality and integrity, assuming only passive (eavesdropping) attacks are possible.

If only one entity makes a public key available to the other, only that entity can be authenticated—not the other. This is sufficient in some scenarios, such as a Web server proving its identity to Web browsers.

Windows 2000 actually has a native "secret-key" infrastructure (based on the user and computer passwords stored in Active Directory) and can also run and make use of a PKI. These two infrastructures complement each other and solve different problems, as discussed in the Microsoft PKI section earlier in this chapter.

Secrets are shared in the following ways:

Long-term secrets are typically established out-of-band (for example, outside the untrusted communication medium over which applications apply cryptographic services) between entities and central authorities. A typical example of this is the logon password that users share with Active Directory.

Short-term secrets are intended to protect the contents of a session. They can be established through the process of key exchange if long-term secrets or public keys are already shared. (This process is described in the following section.)

Public keys are shared in the following manner:

Users and computers obtain the public keys of certification authorities they trust in an out-of-band manner or over a secure channel. For example, in Windows 2000 public keys are either preloaded into the operating system or securely propagated in the Group Policy.

Users can now obtain the public keys of other entities over untrusted channels, packaged in certificates issued by those certification authorities. The certificates allow them to trust that the public keys belong to the named entities.

Key Exchange

Key exchange, or key agreement, is a category of protocols that allows two entities that share a long-term secret or at least one public key to establish a short-term shared secret.

Key exchange protocols make use of the symmetric and asymmetric protocols described earlier in this chapter. Some Windows 2000 protocols that perform key exchange are Kerberos v5, SSL/TLS, and IPSec. For further information about these protocols, see Chapter 5, "Authentication."

Certification

Certification is the basis of a PKI. Certification binds a public key with the key holder's name and the intended key usage for a period of time. It is performed by a CA, and provides assurance (to entities who trust it) that the public key does indeed belong to the named entity. The resultant certified public key is called a digital or public key certificate, or simply a certificate. Certificates are sometimes published in a directory or distributed by their owners.

Users and computers who trust a CA and have its certificate can verify the certified public keys of other entities that have registered with it. Services (typically Web services such as IIS) can use certificates to identify users, map them into Windows accounts, and give them access to resources. The discretionary access control lists (DACLs) on the resources determine the users' authorization.

CAs can also set up trust relationships with each other. In a hierarchical CA model, such as the one in Windows 2000, the child (subordinate) authority would obtain its certificate from its parent CA. End users who trust a parent CA trust all its subordinates' CAs.

We'll discuss the hierarchical model further in the Microsoft PKI section later in this chapter. At this point it is worth mentioning that CAs at the top of hierarchies are called root, and only issue certificates to subordinate CAs, not to end users. Root CAs have by necessity self-signed certificates—in other words, they issue certificates to themselves by signing their public keys with their own private keys. By trusting a few root CAs, therefore, users and computers can efficiently verify the certificates of millions of other entities.

End users can also generate self-signed certificates when the users generate a key pair and no CA is available to enroll with. This typically happens when EFS is used in the absence of a Windows 2000 Enterprise CA. Such certificates are of value only to their owners, since other users cannot trust or verify them.

Technically, certification is performed by digitally signing the end user's public key together with identifying information (for example, name and e-mail address), using the CA's private/signing key. The CA's public key is widely distributed; users who choose to trust the public key can use it to verify its digital signatures on certificates.

Thus CAs are trusted for a number of things, including properly identifying key holders before issuing them a certificate, revoking this certificate when it is no longer valid, and keeping their own private/signing keys confidential. You need to document these issues in the CA's certificate practice statement (CPS), especially if you use its certificates to communicate with other organizations.

The next section describes why and how certificates are revoked.

Certificate Revocation

Revocation is the act of canceling a certificate, effectively recalling the issuer's signature on the combination of public key and user name.

The following situations can result in certificate revocation:

The user changes his or her name.

The user's private key is compromised; the user will enroll separately for a new certificate under a new key pair.

The issuer's signing key is compromised. If other parties can now issue certificates on behalf of the issuer, all issued certificates are now invalid.

The user leaves the organization or the part of the organization for which the CA is responsible.

The computer owner of the certificate (computer owners can have keys, too) is replaced, compromised, or decommissioned.

Technically, revocation is performed by publishing the certificate's serial number in a CRL signed by the issuing CA.

A CA's certificate is revoked if its private key is compromised, because now other parties can issue certificates on its behalf. Therefore, all its certificates, including ones issued to subordinate CAs and their issued certificates, are also considered revoked.

Certificate Renewal

Renewal is the act of issuing a new certificate using the same name, a new serial number, and perhaps (but not necessarily) a new key pair. Renewal does not affect the validity of the old certificate.

You should renew user and computer certificates just before they are about to expire. For CA certificates, renewal should happen earlier, because for a certificate to be valid at any given time, the certificates of the issuing CA and its parents must also be valid. It would be unfortunate if a CA certificate expiration caused any issued certificates to expire. Therefore, Microsoft CAs implement time nesting, meaning that they will not issue certificates that will expire later than their own certificates. This time-nesting policy can cause problems toward the end of a CA's certificate lifetime. For example, if a CA issued certificates one month before its certificate expired, those issued certificates would need to have an expiration period of less than one month.

Therefore, you should renew a CA certificate when its remaining lifetime approaches the longest validity period of certificates it issued. For example, a CA that issues certificates valid for two years should have a lifetime of four years, and renew its certificate every eighteen months.

After renewal, an entity uses the new certificate and key pair, if any. The old set is archived to decrypt and verify old and even new documents.

Top Of Page

Microsoft PKI

The Windows 2000 PKI consists of a number of components:

The public key–enabled applications and services. These are IIS, IPSec, smart card logon, EFS, Internet Explorer, Outlook, and Outlook Express. These components interact with each other, and they make use of the cryptographic security services. Some of them also perform key management. They are all standards-based and can interoperate with non-Microsoft entities. They obtain the keys or certificates they need from their own user's or host's store, Active Directory, and Exchange.

The user and host certificate stores. These store the entity's own certificate, if any, and a pointer to the cryptographic service provider that holds the private key. They also store the certificates of trusted CAs and other entities. These certificate stores are made available to the PK-enabled applications.

The Certificates MMC Snap-In for certificate management. This snap-in allows users to browse the certificate stores, export private certificates and private keys, and perform certificate enrollment with Microsoft enterprise CAs.

The Public Key policies. These policies specify which CA certificates populate the user and host stores and how these certificates are trusted. They also define automatic certificate enrollment and renewal behavior for hosts. PK policies are defined in the Group Policy objects.

The Certificate Services. These services allow you to implement your own PKI using the enterprise and standalone Microsoft CAs. Enterprise CAs issue certificates to domain users and hosts and publish them in Active Directory; standalone CAs are generic CAs that can issue any type of certificate to anyone, including non-Windows entities.

Active Directory. Active Directory is a certificate publication point for Microsoft CAs.

Behind the scenes you will also find the cryptographic service providers (CSPs), which are accessible through the Microsoft CryptoAPI. CSPs offer key generation and other crypto services to the PK-enabled client software and the Microsoft CAs. CSPs also provide an interface to smart cards.

The next section will concentrate on the Windows 2000 Certificate Services, key management for users and hosts, and Public Key policies. First we will explain the purpose of a PKI in Windows.

Why Use a PKI?

Both Windows NT and Windows 2000 have a secret key infrastructure of sorts. All domain users and workstations have a shared secret key (password) relationship with the domain controllers (DCs). Those passwords are typically used with Kerberos and NTLM to authenticate users to services and DCs, as well as to authenticate hosts to DCs. The passwords can also derive cryptographic keys that offer link confidentiality (with PPTP, for example) and integrity (for example, SMB signing).

The secret key infrastructure is well-suited to offer authentication services to the Windows 2000 domains found within a corporation. However, this model encounters trust and scalability problems as soon as you need other security services or your network needs to communicate with external users.

As we explained in the beginning of this chapter, the PKI enables entities across organizational boundaries to trust each other's credentials in an efficient manner. The PKI also enables end-to-end security services to be used between entities, and offers strong entity authentication. A PKI complements the Windows NT and Windows 2000 secret key infrastructure and allows you to exploit more security services across a more distributed environment.

Note that even if a Windows environment does not implement a PKI, the Windows 95, Windows 98, Windows NT, and Windows 2000 clients already participate in some Internet-wide, commercial PKIs. Those clients come preloaded with a number of commercial CA certificates, allowing them to authenticate other participating entities. This is how Internet Explorer and other Web browsers can establish secure SSL/TLS connections with Internet Web servers or verify signed code (for example, ActiveX components and other software) downloaded from the Internet and your intranet. Users can also verify signed e-mail sent to them, and if they enroll with a commercial CA and obtain their own certificates, they can also send and receive signed and encrypted e-mail. Windows 2000 enables the management of this trust in external CAs through the Group Policy.

Certificate Services

Certificate Services allows you to implement your own PKI. This section describes their components and installation.

Microsoft Certificate Services

Microsoft Certificate Services is the certification authority service. Its job is to accept certificate requests, issue certificates, and publish the CRL.

There are two kinds of Microsoft CAs: enterprise and standalone. An enterprise CA is meant to issue certificates to domain users and computers according to some ACLs. Windows 2000 services, such as EFS and interactive logons with smart cards, can use these certificates, and they can be published to Active Directory. A standalone CA is meant to issue certificates to entities outside your Windows 2000 domains, such as customers and users of other organizations.

Some of the differences between the two CAs are evident in the way their policy and exit modules work. You can actually replace those modules with your own in a standalone CA. For example, you might want to define a policy that automatically issues certificates according to certain rules.

Since standalone CAs can issue certificates to any kind of entity—even non-Windows 2000 entities—they are more suited to be your root CAs. They are capable of operating offline, as they don't need to automatically authenticate the requestors like the enterprise ones do. You'll find more information on this topic later in the chapter.

Certificate Templates

Templates are profiles that define the contents of certificates issued by Microsoft enterprise CAs. Those contents include user information such as name and e-mail address obtained from Active Directory, expiration time, and intended certificate usage.

Each template is defined by its intended usage. For example, the user template called "User" allows its holder to use EFS, to encrypt e-mail, to sign e-mail, and to authenticate himself or herself to Web servers. The computer template called "WebServer" allows its holder to authenticate itself to Web browsers. Table 6-1 provides a list of templates.

Table 6-1 Certificate templates.

Certificate template name

Certificate purposes

Issued to users or computers

Administrator
Code signing, certificate trust list (CTL) signing, EFS, secure e-mail, client authentication
Users
Authenticated session
Client authentication
Users
Basic EFS
EFS
Users
Computer
Client authentication, server authentication
Computer
Code Signing
Code signing
Users
Domain Controller
Client authentication, server authentication
Computers
EFS Recovery Agent
File recovery
Users
Enrollment Agent
Certificate request agent
Users
Enrollment Agent (Offline request)
Certificate request agent
Users
IPSec (Offline request)
Internet Protocol security
Computers
IPSec
Internet Protocol security
Computers
Router (Offline request)
Client authentication
Computers/routers
Smart Card Logon
Client authentication
Users
Smart Card User
Client authentication, secure e-mail
Users
Subordinate certification authority
All
Computers
Trust List Signing
CTL signing
Users
User
EFS, secure e-mail, client authentication
Users
User Signature Only
Secure e-mail, client authentication
Users
Web Server
Server authentication
Computers
Each domain forest has a single set of certificate templates stored in Active Directory. You can examine them with the Active Directory Sites And Services Snap-In. To do so, start the Active Directory Sites And Services Snap-In, choose Show Service Node from the view menu, expand the Services node, expand the Public Key Services node, and then select the Certificate Templates, as shown in Figure 6-1.

Each template has an attached ACL that specifies which users and computers can enroll for it or access it otherwise. For example, Figure 6-2 shows that all authenticated (domain forest) users can enroll for certificates of the User template. You cannot edit templates through the user interface.

Figure 6-1: Certificate Templates in Active Directory.

Figure 6-2: Access control on Certificate Templates.
You can configure each enterprise CA to issue only certificates of certain templates. For example, you might want to designate a CA to issue only Administrator certificates.

Standalone CAs also have certificate types, but they are not called templates, they cannot be examined through the user interface, and no ACL is attached to them.

Policy Module

The CA calls the policy module to decide whether a certificate should be issued, denied, or marked as pending for the CA administrator to review.

On an enterprise CA, the module provided with Windows 2000 will accept certificate requests from users with read and enroll access to the CA. The defining characteristic of an enterprise CA is that it authenticates the requesting entities using their domain accounts. By default, all authenticated (domain forest) users have such access, as indicated in Figure 6-3.

Figure 6-3: Access control on an Enterprise Certification Authority.
The module will then verify that the template against which the request was made is actually available for issuing by this CA, and then check that the user has enroll access to the template.

On a standalone CA, the policy module will accept requests from users with similar access to the CA, which by default is everyone, authenticated or not. It will then mark the requests as pending by default, or you can also configure it to issue them automatically. Templates are not defined for standalone CAs.

On both types of CA, the module will also add two X.509v3 extensions to the certificate with the following:

CRL distribution point (CDP) records. These point to where the CA publishes its CRL.

Authority information access (AIA) records. These point to where the CA's certificate is published.

Those pointers are in the form of a URL, and can point to Active Directory (LDAP), to the CA's Web interface (http) or to the CA's shared folder (file), if one is specified during installation. When forming those URLs, use the replaceable parameter syntax shown in Table 6-2.

Table 6-2 CA replaceable parameters.

Variable

Value

%1
DNS name of the certification authority server
%2
NetBIOS name of the certification authority server
%3
Name of the certification authority
%4
Renewal extension of the certification authority
%5
Location of the domain root in Active Directory
%6
Location of the configuration container in Active Directory
%7
The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end
Exit Module

The CA calls the exit module after it issues a certificate. The module's job is to publish the certificate in the location specified in the certificate request, typically Active Directory for enterprise CAs and the file system for standalone CAs. The module is also responsible for publishing the CRL.

Certification Authority Snap-In

The Certification Authority Snap-In—shown in Figure 6-4—allows you to view and manage certificates and requests, configure the CA, and manually publish the CA CRL.

Figure 6-4: The Certification Authority Snap-In.
This snap-in allows you to do the following:

View the revoked certificates and manually publish the CRL.

View and revoke issued certificates.

View, issue, and deny any pending requests. Such requests are only possible on standalone CAs.

View failed requests. Requests can be failed by the policy module if the requestor is not authorized to enroll in the CA's ACL or by the CA administrator who reviews the pending requests.

For enterprise CAs only: view,

Identify Your Certificate Requirements

Your certificate requirements are driven by the Public Key–enabled applications you use or plan to use. Identifying those requirements will let you decide which users and computers need what type of certificates. For each set of users you should identify the following criteria:
1. Which certificates are needed 2. Private key size 3.Cryptoalgorithms allowed 4.key lifetime 5. Private key storage (on smart cards, for example) 6. Private key exportability

Then you can identify how many and what kind of CAs you need. Your options include:

Microsoft enterprise CAs, which can automatically issue a certificate to a user or computer with a Windows 2000 domain account.

Microsoft standalone CAs, which typically require an administrator to manually issue certificates.

Third-party CA software.

Commercial CA services on the Internet, such as those provided by VeriSign and Thawte. These have the advantage of preloaded certificates in most client software, and can be a common point of trust among organizations. The downside to these services is that the private key that directly or indirectly signs your certificates is not under your direct control—a private key compromise at the commercial CA also compromises all of your certificates.

CAs issue certificates for users and computers. If you have any number of CAs, it is likely that you will want to organize them into a hierarchy. This organizing is done by introducing root and intermediate CAs (also chosen from the preceding list), whose job is to certify the intermediate and issuing CAs, respectively. For an explanation of why and how to achieve this, see the information on trust strategies later in this section.