Chapters 17 and 18 exposed you to most of the security vocabulary you'll need to work with Certificate Services, but you need to learn some additional terms, as defined in the following sections.
A policy module is a set of instructions that tells the CA what to do with incoming certificate requests. A policy module can automatically approve or reject a request, based on any criteria coded into the module; it can also mark a request as pending and leave it for a human administrator to handle. Policy modules can also modify the content of a certificate by adding or removing extensions; the standard policy module supplied with Windows 2000 does the following:
Other applications, notably Microsoft Exchange Server, can implement their own policy modules, which can replace or augment the standard policy behavior. Microsoft offers tools that allow you to develop your own policy module if you need to change the policy behavior to match your organization's security standards.
An exit module allows the CA to take some action after a certificate is generated. For example, an exit module might publish new certificates by putting them in the Active Directory directory service or mailing them to the original requestor. The standard Windows 2000 exit module performs two tasks: if the requestor specifies a file path, an Active Directory location, or both, the exit module publishes the new certificate to one or both locations; and it publishes CRLs for the CA to the location you specify.
A certificate publisher serves the same function as any other kind of publisher: it makes desirable information available to clients who want it. Specifically, certificate publishers make certificate and CRL information available to clients, using whatever mechanism they want. The default certificate publisher in Windows 2000 is Active Directory, although you're free to export certificates or store them in another type of directory or publishing system.
A certificate template defines a cookie-cutter set of attributes and extensions that a newly issued certificate will have. For example, the Administrator certificate template specifies different attributes from a Domain Controller certificate. The idea behind certificate templates is that the person requesting a certificate can just pick a template that embodies the attributes and extensions he or she needs the new certificate to have, instead of being required to pick and choose from dozens (or even hundreds) of arcane attribute names.
Windows 2000 supports 19 certificate templates, listed in Table 19-1. When you request a certificate using a particular template, the CA knows which attributes and extensions to populate the new certificate with; as an administrator, you can control which templates individual users and groups can use when requesting new certificates. (In fact, you can also control whether they can request certificates at all!)
Each template defines the content of the certificate, using some combination of the nine template features shown in Table 19-2. You can't control the content of templates, so you must work with the attribute combinations hard coded into them by Microsoft.
Table 19-1. Certificate templates
Template | Purpose | Recipient |
---|---|---|
Administrator | Signs code; signs certificate trust lists (CTLs); secures e-mail and EFS file systems; authenticates clients | People acting in an administrative role in the domain |
Authenticated Session | Allows signature-only operations for client authentication | Network clients |
Basic EFS | Encrypts EFS intermediate keys and files | People who have access to EFS volumes |
Code Signing | Signs executable code to assert its trustworthiness | People who are authorized to sign executables and controls |
Computer | Authenticates computers to servers and vice versa | Computers within a domain |
Domain Controller | Authenticates clients to servers; authenticates servers to clients | Computers that act as Active Directory controllers |
EFS Recovery Agent | Recovers encrypted files when the original key material is unavailable | People who have EFS recovery privileges |
Enrollment Agent | Requests certificates for users or computers | People who have certificate request authority |
Exchange Enrollment Agent (offline request) | Generates offline certificate requests for Exchange mailbox owners | Enrollment agents who can request new certificates for Exchange users |
Exchange Signature Only | Generates signature-only certificates for Exchange users | People who you want to allow to send signed messages with Exchange Server |
Exchange User | Generates signature- and encryption-capable certificates | People who you want to allow to send signed or encrypted messages |
IPSec | Allows the use of IPSec encryption and authentication | Computers that use IPSec security |
IPSec (offline request) | Allows computers that are not currently attached to the network to use IPSec when connected | Computers that use IPSec security |
Router (offline request) | Authenticates clients to a server | Computers or routers that are managed as part of a domain |
Smart Card Logon | Authenticates a client to a logon server | Smart card holders who use smart cards to log on; can t be used for secure e-mail or EFS security |
Smart Card User | Authenticates a client; provides e-mail security | Smart card holders who have permission to use their smart cards to log on and secure e-mail |
Subordinate Certification Authority | Issues and revokes certificates while acting as a subordinate CA | Subordinate CA computers |
Trust List Signing | Signs the CTL | Administrators who have authorization to change the CTL s contents |
User | Authenticates client-to-server messages; signs and encrypts e-mail; encrypts EFS data | Individual users with no other special privileges |
User Signature Only | Signs e-mail; signs client-to-server authentication messages | Individual users who don t have encryption capability |
Web Server | Authenticates server to clients | Web servers |
Table 19-2. Certificate template features
Attribute Type | Specifications |
---|---|
Basic constraints | Specifies whether this certificate can be used to sign other certificates and, if so, how many levels of nesting the resulting hierarchy can contain. |
Default CSP list | Provides a list of cryptographic service providers (CSPs) that can be used with this certificate type. For example, EFS requires certificates generated with the Microsoft RSA CSP. |
Display name | Displays the name when someone views the certificate s information; this is a friendly name that s less complex than the certificate s distinguished name (DN). |
E-mail name | Specifies the e-mail address associated with the holder of this certificate. |
Extended key usage | Specifies a list of extended functions (including signing a CTL, encrypting e-mail, and establishing secure network connections) for which this certificate can be used. The extended key usage information coexists with, and doesn t override, the standard key usage fields. |
Key usage | Specifies what combination of basic operations (digital signatures, encryption, and key exchange) this certificate can be used for. |
Machine certificate template | Specifies whether certificates that use this template are intended for use by people or by computers. |
Security permissions | Specifies who can request a particular kind of certificate. For example, the default permissions for the Administrator template allow only users with administrative access to request administrator-level certificates. |
Computers running Certificate Services can act as one of two distinct types of CAs: enterprise or stand-alone. Which type of CA you install determines who you can issue certificates to and what the certificate can be used for, so the distinctions between them are important. The only real difference between the two is which policy module is installed, but the operational differences between them are significant.
The enterprise CA is designed to act as part of an enterprise security infrastructure. In that job, it can issue and revoke certificates for end users and subordinate CAs, according to the active policy modules and security settings you apply to the CA. As befits anything saddled with the "enterprise" label, enterprise CAs require Active Directory access. Several key features distinguish the enterprise CA from the stand-alone CA:
Another important difference between enterprise CAs and stand-alone CAs is that enterprise CAs use certificate types and templates to construct the content of newly issued certificates. This capability leads to some useful features. First, because they use templates, enterprise CAs can stuff the newly formed certificate with the proper set of attributes. In addition, enterprise CAs automatically fill in the subject name for newly issued certificates. Enterprise CAs have the unique property that they will always either reject or approve a certificate request—they will never mark one as pending. Enterprise CAs make this go/no-go decision based on the security permissions set on the requested template type, as well as on the account's permissions and group memberships in Active Directory.
The stand-alone CA doesn't require Active Directory—it's designed to be a separate box that can issue certificates for extranet or Internet use. As such, its purpose is to issue certificates for people to use who aren't part of your core organization and who won't have Active Directory access. The basic mechanics of certificate issuance for a stand-alone CA are similar to those for an enterprise CA, with a few exceptions:
You can install a stand-alone CA on a server that participates in an Active Directory organization. If you do, the CA will be able to publish certificate information if its server is a member of the Certificate Publishers group.