More Vocabulary

Chapters 18 and 19 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.

Policy Modules

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:

• Approves incoming requests or marks them as pending, depending on the CA type and the setting you specify
• Adds an optional extension to the certificate that specifies where the issuing CA's certificate can be obtained
• Adds an optional extension that specifies where certificate revocation lists (CRLs) for the issuing CA can be obtained

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.

Exit Modules

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 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.

Certificate Publishers

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.

Certificate Templates

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 21 certificate templates, listed in Table 20-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 template features listed in Table 20-2. You can't control the content of templates, so you must work with the attribute combinations hard coded into them by Microsoft.

Table 20-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 volumes	People who have access to EFS
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 Privileges	Recovers encrypted files when the original key material is unavailable	People who are designated EFS recovery Agents
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	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 20-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.

Certificate Authority Types

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 to whom you can issue a certificate and what it 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.

Enterprise CA

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:

• An enterprise CA is always trusted by all users and computers in its domain because the CA certificate appears in the Trusted Root Certification Authorities trust list in Active Directory.
• Certificates issued by an enterprise CA can be used to log on to Windows 2000 domains with smart cards (as discussed in Chapters 18 and 19).
• An enterprise CA publishes certificates and CRL information to Active Directory.

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 always either reject or approve a certificate request—they 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.

Stand-Alone CA

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 users 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:

• Requests sent to a stand-alone CA are automatically marked as pending because the CA has no way to use templates and Active Directory information to verify them. This lack of directory information also means that requestors must completely fill out all the information in their request, because the CA has no way to look it up.
• Certificates issued by a stand-alone CA can't be used for smart card-based logons, although you can store such certificates on a smart card.
• Certificates and CRLs generated by the stand-alone CA aren't published anywhere—you must manually distribute them.

You can install a stand-alone CA on a server that participates in an Active Directory organization. If you do, the CA is able to publish certificate information if its server is a member of the Certificate Publishers group.