A CA is a fussily bureaucratic beast. It will not issue certificates to just anyone. A client must submit its certificate request in a special format so that its identity can be quickly and reliably verified before its public key can be incorporated into a signed certificate. This process is called enrollment.
The most popular format for submitting enrollment requests is the PKCS #10 Certification Request. See RFC 2986, "PKCS #10: Certification Request Syntax Version 1.7," for details about the contents of the request. (Documentation is also available at the RSA web site, www.rsalabs.com.) A PKCS #10 certificate request contains the following information:
Client's public key.
This is the key the client wants the CA to countersign. Including the public key in clear text is not a problem because the public key was designed to be transmitted in the clear.
Client's distinguished name.
This is the client's name in X.500 or LDAP format. For example, the DN of the Verisign trust network is OU = VeriSign Trust Network, OU = 1998 VeriSign, Inc. - For authorized use only, OU = Class 1 Public Primary Certification Authority - G2, O = VeriSign, Inc., C = US. An example of a DN for an Active Directory user would be a much less imposing cn=Jane User,ou=Phoenix,dc=Company,dc=com.
This is a hash of the certificate request encrypted with the client's private key. The private key itself is never transmitted on the wire. It stays securely situated in the user's local profile.
This is the hashing algorithm used to create the digital signature. Microsoft PKI using both MD5 and SHA-1.
When a CA receives a PKCS #10 certification request, it uses the public key in the request to decrypt the digital signature in the request. (Something encrypted with one half of a key pair can only be decrypted with the other half.) If the decryption fails, the CA is forced to assume that a bad guy has intervened and fiddled with the certificate request and the request is discarded.
If the CA can decrypt the digital signature, it then hashes the request using the same algorithm as that used by the client. If the resulting hash matches the hash in the decrypted signature, the user's identity is validated.
The CA then digitally signs the user's public key and incorporates it into an X.509 certificate, which it returns to the client. The client distributes copies of this certificate to other entities for use in encrypting data sent to the client. The other entities, when presented with client's X.509 certificate, validate it by checking the digita signature assigned by the CA.
Certificate Management Messages over CMS (CMC)
For a long time, RSA Security owned the intellectual property rights to PKCS technology, which caused the PKIX working group of the IETF to fork off a separate PKI standard called the Certificate Management Protocol, or CMP. This standard is documented in two RFCs: RFC 2510, "Internet X.509 Public Key Infrastructure Certificate Management Protocols," and RFC 2511, "Internet X.509 Certificate Request Message Format."
CMP is much more complex than the RSA key exchange method, but it also provides more features and corrects a couple of hypothetical vulnerabilities. The chief advantage of CMP, from a system administrator's perspective, is its support for the direct involvement of a Registration Authority that can hold copies of private keys in a secure form. In the event that a user loses his private keys, they can be re-issued.
From the vantage point of a crypto professional, CMP is an improvement over RSA because of the nature of the PKI protocols it uses. CMP uses the Cryptographic Message Syntax (CMS) as documented in RFC 2530, "Cryptographic Message Syntax."
Russ Housley and Tim Polk, the developers of CMS and CMP, have proposed a new protocol called Certificate Management Messages over CMS (CMC) that combines the best of RSA and CMP to produce a hybrid PKI solution. They document this protocol along with descriptions of the other major PKI components in RFC 2797 and in an outstanding book called Planning For PKI.
Windows Server 2003, Enterprise Edition and Datacenter Edition support CMC enrollment for XP and Windows Server 2003 clients and PKCS #10 enrollment for Windows 2000 and other downlevel clients. Windows Server 2003, Standard Edition supports only PKCS #10 enrollment.
Enrollment Functional Description
Windows Server 2003 and XP computers and users automatically enroll when they log on to a domain that contains a Windows Server 2003 Enterprise CA. Windows 2000 users transparently enroll for an EFS certificate when they encrypt a file in a domain with an Enterprise CA. Clients can also use an MMC-based snap-in called Certificates to request certificates. Clients that do not have direct access to a CA can enroll via the web. All these methods use an ActiveX control called Xenroll.dll to accomplish the enrollment. Here are details of the transactions.
Computers and users in a Windows Server 2003 domain are issued certificates automatically via group policies. This is configured using the Automatic Certificate Request Settings group policy located under Computer Configuration | Windows Settings | Security Settings | Public Key Policies.
The auto-enrollment feature is controlled by an Autoenrollment Settings object at the root of the Public Key Policies folder. Figure 18.20 shows the Properties window for this policy.
Figure 18.20. Autoenrollment Settings policy properties.
The main option for the policy is to Enroll Certificates Automatically. You can optionally choose to renew and revoke certificates automatically and you can choose to update certificate template types automatically. The option to update the template type is important in a mixed environment because Windows 2000 clients cannot obtain certificates derived from Version 2 templates through auto-enrollment.
Certificate Enrollment Using the Certificates Snap-In
Windows 2000 clients can enroll for a Version 1 certificate using the Certificates snap-in. Windows XP and Server 2003 clients can enroll for a Version 2 certificate directly using the Certificates snap-in.
For example, you can use the Certificates snap-in to obtain an Administrator certificate, which would permit you to do the following:
To request a new certificate, right-click the Personal | Certificates icon in the Certificates snap-in and select REQUEST NEW CERTIFICATE from the flyout menu. This opens a Certificate Request Wizard. Select the certificate type from the pick list. Figure 18.21 shows an example.
Figure 18.21. Certificate Request Wizard showing list of available certificates.
When the CA issues the certificate, a copy will be stored locally in the user's Registry and another copy stored in the user's Active Directory object.
If you put the focus of the Certificates snap-in on the computer rather than the user account when you load it into an MMC console, you can request the domain controller and domain controller email replication certificates required to use SMTP for replication between sites.
Any client can request a certificate from a CA by using a web browser. You must be running IIS on your CA and you must install the web request feature. This installs a set of virtual directories that clients use to download the ActiveX control for enrollment, Xenroll, and manages the enrollment process using either classic RSA PKCS #10 or the PKIX standard CMC protocol.
Web enrollment uses a virtual directory called CertSrv that points at Windows\System32\CertSrv. This directory holds ASP pages and other support files to aid in obtaining a certificate along with copies of the CA certificate for the server. Pending enrollment requests and issued certificates are stored securely in the CA database.
Two other virtual directories support certificate enrollment: CertEnroll and CertControl. The CertEnroll directory holds the Certificate Revocation List (CRL), a digitally signed list of the certificates issued by the CA that are no longer in force. The CertControl directory holds the ActiveX controls used for enrolling web clients.
An Enterprise CA server requires users to present domain credentials before permitting them to connect to the CertSrv web site. Standalone servers permit anonymous requests unless specifically configured to disallow them.
An Advanced option in the web enrollment process permits you to submit an existing certificate for certification or to request a smart card certificate. To obtain a certificate from a web server, follow Procedure 18.2.
Procedure 18.2 Enrolling for a Certificate Using the Web
Connect to the CA via Internet Explorer 5.0 or later. Use the URL http:// <server_name>/certsrv. You are greeted with a Welcome page that displays the request options (see Figure 18.22). The name of the CA server is displayed in the green bar at the top of the page.
Figure 18.22. Web enrollment Welcome page.
Click Request A Certificate. The next page lists one certificate option, a User certificate, with an Advanced Certificate Request option for obtaining a smart card certificate.
Click User Certificate. The User Certificate - Identifying Information page opens.
Click Submit. The CA processes the request then returns a Certificate Issued page.
Click Install This Certificate. When the certificate request has been processed, a Certificate Installed page opens. You can use the Certificates snap-in to check for the presence of the certificate.