15.2 Certificate enrollment

Certificate enrollment enables a user, machine, or service to participate in and use PKI-enabled applications (PKA) or processes. Certificate enrollment consists of a cycle of events: key generation, certificate request, identification, certificate generation, publishing, and encryption key archival.

Certificate enrollment can be started manually by a user or an administrator. In some PKI-enabled applications, it requires an initiative from both the user and an administrator. A good example is the scenario in which a Windows enterprise CA is issuing certificates. In this case the administrator first must authorize which users the machines can enroll for a particular certificate type. The latter can be done by setting access control permissions on the certificate templates.

In most cases, a user (whether a user, machine, or service account) initiates certificate enrollment. In Windows 2000 and Windows Server 2003, there is one exception to this rule: smart card enrollment. In this enrollment model an administrator who has a special smart card enrollment agent certificate^[1] is allowed to enroll for a certificate on a user’s behalf. He or she can also load the user’s certificate on its smart card. We will return to smart card enrollment in the chapter on PKI-enabled applications.

For a user to enroll for a certificate from a Windows 2000 or Windows Server 2003 stand-alone CA, only enroll permission on the AD CA object is required. Before a user can enroll for a certificate from a Windows 2000 or Windows Server 2003 enterprise CA, the following conditions must be met:

• The user must have read and enroll permission on the enterprise CA level. This permission must be set on the AD CA object.

• The appropriate permissions must be set on the certificate template (enroll and read).

• The right certificate template must be configured on the CA.

Enrollment can also be initiated automatically for both user and machine accounts that are part of a Windows domain environment. This feature is known as certificate autoenrollment. Autoenrollment will be explained in more detail next.

In the following sections, we look in more detail at the following key elements and aspects of the Windows certificate enrollment process:

• Certificate autoenrollment

• Enrollment interfaces

• Key and certificate request generation

• Requestor identification

• Certificate generation, distribution, and publication

15.2.1 Certificate autoenrollment

Certificate autoenrollment is the Windows 2000, Windows XP, and Windows Server 2003 OS capability to automatically enroll users and machines for certificates. Windows 2000 PKI only supports certificate autoenrollment for machines and Encryption File System (EFS) user certificates. Windows Server 2003 PKI extends certificate autoenrollment to users and all certificate types, greatly enhancing the PKI’s ease of use. Compared to the feature set of other PKI products on the market, certificate autoenrollment is also a unique feature that gives Windows Server 2003 PKI an important advantage over other PKI products.

Certificate autoenrollment not only handles certificate enrollment: It also automates certificate renewal and certain certificate housekeeping tasks. The latter include removing revoked certificates from a user’s or machine’s certificate store, or downloading the trusted root CA certificates and cross-certificates from AD.

The following are some typical examples of how certificate autoenrollment is or can be used:

• Every Windows 2000 and Windows Server 2003 domain controller automatically gets a domain controller certificate when the machine joins a domain in which an enterprise certification authority is defined.

• An administrator can set a GPO setting that automatically enrolls machines for an IPsec or SSL certificate.

• An administrator can set a GPO setting that automatically enrolls a number of users for a user or secure mail certificate.

• When the CA administrator wants to change a property (e.g., the lifetime) of a particular certificate type, he or she can duplicate the old certificate template to create a new certificate template and let the new one supersede the old one. Autoenrollment will then automatically distribute a new certificate based on the new template to the concerned PKI users.

Certificate autoenrollment for users requires extra client-side code that at the time of this writing was only bundled with XP and Windows Server 2003 clients. Autoenrollment requires both the machine and the user to be part of a Windows Active Directory domain. Also, autoenrollment properties can only be set on version 2 certificate templates. Remember that only a domain with a Windows Server 2003 schema supports version 2 templates and that only a Windows Server 2003 Enterprise Edition or Datacenter Edition AD-integrated CA can issue certificates that are based on version 2 certificate templates.

Setting up machine autoenrollment

As in Windows 2000, in Windows Server 2003 you enable machine certificate autoenrollment from the GPO Public Key Policies’ Automatic Certificate Request Settings container. If you right-click this container and select New\Automatic Certificate Request…, the Automatic Certificate Request Setup Wizard (illustrated in Figure 15.2) will start and will guide you through the machine certificate autoenrollment process.

Figure 15.2: Automatic Certificate Request Wizard.

Setting up user autoenrollment

To set up user certificate autoenrollment, you must make configuration changes in both the MMC Certificate Templates and Group Policy snap- ins.

• To enable autoenrollment at the template level, open the Certificate Templates snap-in, open the template, go to the Security tab, and set the appropriate ACL settings to give users or groups the Autoenroll permission (as illustrated in Figure 15.3(b)).

  

  
  Figure 15.3: Setting autoenrollment permissions on the certificate template level.

  These user autoenrollment properties can only be set on version 2 certificate templates. Only a domain with a Windows Server 2003 schema supports version 2 templates and only a Windows Server 2003 Enterprise Edition or Datacenter Edition AD-integrated CA can issue certificates that are based on version 2 certificate templates.

  If you want autoenrollment to occur without any user intervention, leave the default settings on the Request Handling tab unchanged (as illustrated in Figure 15.3(a)). If you want to prompt the user to start the autoenrollment process, select the “Prompt the user during enrollment” radio button. User input is required when enrolling smart card certificates.^[2] Requiring user input on machine certificate templates will make machine autoenrollment fail.

• To enable autoenrollment at the GPO level, open the Group Policy snap-in, go down to Computer Configuration\Windows Settings\ Security Settings\Public Key Policies, and then open the Autoenrollment Settings Properties dialog box, which is shown in Figure 15.4. In this dialog box, check the “Enroll certificates automatically” radio button and check the “Update certificates that use certificate templates” checkbox.

  
  Figure 15.4: Setting autoenrollment properties at the GPO level.

  If you want the autoenrollment process also to take care of certificate renewal and other certificate housekeeping tasks, make sure that you also check the “Renew expired certificates, update pending certificates, and remove revoked certificates” checkbox.

When user autoenrollment occurs and it has been set up to occur without user input, everything will happen automatically without user intervention. If it has been set up to occur with user input, a warning balloon will appear in the user’s taskbar tray (illustrated in Figure 15.5). After approximately 15 seconds, the warning balloon is replaced by a certificate icon. When the user clicks the balloon or the certificate icon, a dialog box appears and prompts the user to choose whether to start the autoenrollment process (illustrated in Figure 15.6). If the user clicks the Remind Me Later pushbutton in this dialog box, the warning balloon will reappear at the next group policy refresh interval or at the next interactive logon.

Figure 15.5: Autoenrollment text balloon.

Figure 15.6: Forcing user certificate autoenrollment.

The warning balloon appears with a delay of 60 seconds after the inter- active logon sequence. If you want the balloon to appear immediately after the interactive logon sequence, make the following registry hack on the user’s machine. Set the HKEY_CURRENT_USER\SOFTWARE\Microsoft\ Cryptography\AutoEnrollment\AEExpress registry key to value 1 (REG_ DWORD).

Forcing automatic enrollment and renewal

You can force certificate enrollment to occur without waiting for the next logon or automatic GPO refresh.

• To force automatic certificate enrollment for both user and machine certificates, you can manually force a group policy update using the gpupdate.exe command-line utility. Triggering a GPO update will in turn trigger an autoenrollment event.

• To force automatic certificate enrollment for user certificates only, open the MMC Certificates snap-in and open your personal certificates container. Then right-click the Certificates—Current User container and select All Tasks\Automatically Enroll Certificates… from the context menu (as illustrated in Figure 15.7).

  
  Figure 15.7: User autoenrollment confirmation dialog box.

You can also force renewal of specific user or machine certificate types. To do so, in the Certificate Templates MMC snap-in, right-click the template and select “Reenroll All Certificate Holders Certificate”—as illustrated in Figure 15.8. When you select this option the version number of the certificate template is increased. This version number update will actually trigger the autoenrollment event.

Figure 15.8: Forcing user certificate autoenrollment.

To manually force a download of the root CA and cross-certificates stored in AD that are downloaded as part of the autoenrollment process, you must delete the following registry key and all subordinate keys on the client machine: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Cryptography\AutoEnrollment\AEDirectoryCache.

Advanced autoenrollment options

Next we discuss some of the advanced autoenrollment options: the requirement for certificate manager approval, the selfRA feature, the concept of superseding certificate templates, and the meaning of the “Do not automatically reenroll if a duplicate certificate exists in Active Directory” certificate template property. All of these options are only available on version 2 certificate templates.

Version 2 certificate templates have a property called “CA certificate manager approval” (on the Issuance Requirements tab—illustrated in Figure 15.9). If this property is set, CA manager approval is required before the CA will actually issue the certificate. Until the CA manager approves the request, it is added to the CA’s pending requests container. This feature works in conjunction with certificate autoenrollment. The autoenrollment process will periodically check the CA for approved requests and automatically install the certificates on the client machine.

Figure 15.9: Issuance requirements in certificate template properties.

SelfRA is a new Windows Server 2003 PKI feature that allows you to set special enrollment requirements on version 2 certificate templates. It requires the presence of an existing—previously issued—certificate and its associated private key to sign a new certificate request. SelfRA is also configured from the Issuance Requirements tab in the certificate template properties. SelfRA can work in conjunction with autoenrollment. However, autoenrollment cannot deal with requests that require more than a single signature to authorize the enrollment request. The following selfRA-related properties can be set (they are illustrated in Figure 15.9):

• The number of signatures required to authorize the certificate request. Remember, when using autoenrollment, the number of signatures is limited to 1.

• The content of the application and/or issuance policy fields in the X.509 certificates extensions of the authorization certificate

• The requirements for automatic reenrollment: Use the same criteria as the ones used for the original enrollment (these are the ones listed in the upper part of the Issuance Requirements tab) or just check whether a valid certificate of the type mentioned in the certificate template is present in the PKI user’s certificate store.

Superseding certificate templates allow CA administrators to automatically reenroll users for certain certificate types. This allows you, for example, to change a property of a particular certificate type (e.g., the lifetime or the content of an X.509 extension) by issuing a new one. To set up superseding templates, use the Superseded Templates tab in the properties of a version 2 certificate template (as illustrated in Figure 15.10).

Figure 15.10: Setting up superseding certificate templates.

Another very useful certificate template property related to autoenrollment is “Do not automatically reenroll if a duplicate certificate exists in Active Directory” (which is available from the General tab of a version 2 certificate template). When this property is enabled, autoenrollment will not enroll a user for a certificate, when a similar certificate exists in the AD object of the user—even if a certificate does not exist in the “My” container of the user’s certificate store. In this case the autoenrollment process will query AD to determine whether the user should be enrolled. This is an interesting option for users who do not have roaming profiles and log on to multiple machines. Without this setting, these users would be automatically enrolled for a certificate on every machine to which they are logging on.

How autoenrollment works

Certificate autoenrollment (or the autoenrollment event as we call it in the following explanation) is triggered by the winlogon process. The latter is initiated every time an interactive logon is performed and every time machine- or user-based group policies are applied. By default, group policies are applied every 8 hours. As mentioned above GPO updates can also be triggered manually. Unlocking a workstation does not trigger a certificate autoenrollment event.

Here is what happens following an autoenrollment event:

• The client OS queries AD to download the content of a set of predefined certificate stores to the local store on the client machine. These stores include the NTAuth, the trusted root CA, certificate templates and AIA (for cross-certificates) AD containers.

• The autoenrollment process processes the certificate templates, analyzes their properties, and creates a list—referred to as the requirements list—of tasks to be done during the autoerollment event. The requirements list includes:

  • Certificate enrollment tasks. All templates that have autoenroll and read permission set for the current machine or user will be added to the requirements list.

  • Certificate renewal tasks. The autoenrollment process processes the user or machine’s My certificate store container to look for expired certificates or certificates that are about to expire and will add these certificates to the requirements list. Automatic certificate renewal starts when 80% of the certificate lifetime has passed, or when the renewal interval period specified in the certificate template has been reached. The latter is specified on the General tab of a version 2 certificate template.

  • Certificate enrollment tasks based on template supersede rules. The autoenrollment process evaluates certificate template supersede rules and makes the appropriate additions and deletions to the requirements list.

• The autoenrollment process then searches AD for an enterprise CA that can issue the certificates.

• If a CA is found, the autoenrollment process will pass the requirements list to the CA using certificate enrollment and renewal requests.

• The CA will process the certificate enrollment and renewal requests.

• If a certificate is issued from the CA, the autoenrollment process will install the certificate in the My container of the user’s or machine’s certificate store. If the certificate’s state is set to pending (for certificate requests that require administrator approval), the autoenrollment process will save the certificate request information in the request container of the user or machine’s certificate store.

• At the end of the autoenrollment process, the outcome (success or failure) of the process will be logged in the local system’s application event log. If the autoenrollment failed, a summary dialog box will appear. See the following sidebar to set up verbose autoenrollment logging.

• For requests that were set to pending, the autoenrollment process will regularly query the CA to check whether the request has been approved. This will happen every time the group policies are refreshed. Autoenrollment will even retrieve pending certificates that were enrolled manually through the CA web interface.

As pointed out earlier, the autoenrollment event triggers more than just certificate autoenrollment:

• Trusted root CA certificates are downloaded from the AD-based Certification Authorities and NTAuth stores to the local machine’s “Trusted Root Certification Authorities” certificate store container. The autoenrollment process doesn’t download the complete NTAuth store: only the deltas between the content of the user certificate and the NTAuth store are downloaded.

  Setting up verbose logging for certificate autoenrollment events The auto- enrollment process can be configured to log more verbose information and events in the application event log by setting the AEEventLogLevel key (REG_DWORD) in the following registry containers to value 0:

• HKEY_CURRENT_USER\Software\Microsoft\Cryptography\Autoenrollment (for user autoenrollment)

• HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Autoenrollment (for machine autoenrollment)

• Cross-certificates are downloaded from AD to the local machine certificate store. Like for trusted root CA certificates only the deltas are downloaded.

• The autoenrollment process enumerates the pending certificate requests in the request container of the user’s certificate store. It downloads the certificate, once it has been issued, from the issuing CA and installs it in the user’s certificate store. If the request has been pending for more than 60 days, the autoenrollment event removes it from the request container in the user’s certificate store.

• The autoenrollment process also deletes expired and revoked certificates in the userCertificate attribute of the user’s AD object and in the user’s local certificate store. The latter only occurs if the “Delete revoked or expired certificates” property has been set on the Request Handling tab of the certificate template properties.

15.2.2 Enrollment interfaces

Both Windows 2000 and Windows Server 2003 PKI can support four different certificate enrollment interfaces: a Web interface, a GUI interface, a command prompt interface, and a scripting interface:

• Web interface: To enroll for certificates from an enterprise or a stand- alone CA using a Web browser, the user can go to the following URL: http://<CAservername>/certsrv. The latter is the default URL—you can change it using the IIS Manager MMC snap-in.

• GUI interface: A user can enroll for certificates from an enterprise CA or a stand-alone CA using the certificate request wizard (illustrated in Figure 15.11) that’s available from the MMC Certificates snap-in. GUI-based enrollment will only work if the client-side PKI logic can find a CA object in AD and if the user’s machine is joined to an AD domain. A message like the one illustrated in Figure 15.12 will be displayed.

  
  Figure 15.11: Certificate Request Wizard.

  
  Figure 15.12: Certificate Request Wizard error message.

• Command line interface: A user can enroll for certificates from an enterprise CA using the command prompt utility certreq. He or she can also use certreq to retrieve approved pending certificate requests from a CA. To do so, use the following certreq syntax:

  CertReq [-Submit] [Options] [RequestFileIn [CertFileOut [CertChainFileOut [FullResponseFileOut]]]] CertReq [-Retrieve] [Options] RequestId [CertFileOut [CertChainFileOut [FullResponseFileOut]]] 

• Scripting interface: You can use CAPICOM (explained in Chapter 13) in conjunction with the xenroll.dll dynamic link library to create custom certificate enrollment interfaces. The latter is explained in more detail next.

Web based enrollment Interface

The Web based enrollment interface (illustrated in Figure 15.13) is made available through the Certificate Services Web Enrollment Support, an installation option that is selected by default when installing a CA on a server that has IIS installed. The Web server hosts the Certsrv virtual directory and application and the Certcontrol and CertEnroll virtual directories. All of them are automatically created during the Web interface installation process. You can also create the CA virtual directories manually using the certutil.exe command line tool with the -vroot switch.

Figure 15.13: Web enrollment interface.

The CA with which the Web interface is communicating should not necessarily be on the same machine as the Web interface itself. When installing the Web interface on a server that does not have a CA installed, the installation program will prompt you for the name of a CA server to which the interface must point. This means you can deploy multiple CA Web interfaces on the same or on a different machine that are pointing to the same certificate server. This gives you an elegant way to deal with, for example, the different language requirements of your PKI clients: Just deploy one Web interface per language that you need to support.

The CA Web interface is built on ASP pages that detect the client’s browser type. If they detect Internet Explorer, they will use the Certificate Enrollment Control (CEC) and its ActiveX controls (explained later). If it detects a Netscape browser it will generate a key and request through the Netscape specific KeyGen method.

When using the Web enrollment interface in Windows Server 2003, you will notice that the inclusion of the IE Enhanced Security Configuration^[3] in Windows Server 2003 brings along some interesting error and warning messages (like the one illustrated in Figure 15.14).

Figure 15.14: Web enrollment warning message (following the IE enhanced security configuration).

Table 15.1 shows the certificate enrollment choices that are available from the Web interface. There are slight differences in the options available from the Web interface of a stand-alone CA and an enterprise CA.

Table 15.1: Windows Server 2003 CA Web Interface Options

Windows Server 2000 CA Web Interface Options	Remarks
1. Request a certificate
1.1 User certificate 1.1.1 Stand-alone CA: Web browser certificate or e-mail protection certificate 1.1.2 Enterprise CA: User certificate	Stand-alone CA: Fill in name, e-mail, company, department, city, state, country/region (all filled in except for name e-mail) Enterprise CA: Identification data retrieved automatically from AD
1.1.3 More options 1.1.3.1 Select a CSP 1.1.3.2 Enable strong private key protection 1.1.3.3 Request Format	Supported Request formats: CMC or PCKS10
1.2 Advanced certificate request
1.2.1 Create and submit a request to this CA	Stand-alone CA: Fill in name, e-mail, company, department, city, state, country/region (all filled in except for name e-mail) Enterprise CA: Identification data retrieved automatically from AD
1.2.1.1 Certificate template	Enterprise CA only
1.2.1.2 Type of certificate needed	Stand-alone CA only Client authentication certificate… other (given OID)
1.2.1.3 Key options 1.2.1.3.1 Create new key set Use existing key set 1.2.1.3.2 CSP 1.2.1.3.3 Key usage (exchange) 1.2.1.3.4 Key size 1.2.1.3.5 Automatic key container name User specified key container name 1.2.1.3.6 Mark key as exportable Export keys to file 1.2.1.3.7 Enable strong private key protection	Supported key sizes: Minimum: 384 Maximum: 16,384
1.2.1.3.8 Store certificate in local computer certificate store	Storing the certificate in the local computer store requires local administrator rights.
1.2.1.4 Additional options 1.2.1.4.1 Request Format 1.2.1.4.2 Hash algorithm 1.2.1.4.3 Save request to a file 1.2.1.4.4 Attributes 1.2.1.4.5 Friendly Name	Supported Request formats: CMC or PCKS10 Supported Hash algorithms SHA-1, MD2, MD4 or MD5
1.2.2 Submit a cert request by using a base64-encoded CMC or PKCS10 file, or submit a renewal request by using a base64-encoded PKCS7 file 1.2.2.1 Base64-encoded request 1.2.2.2 Certificate Template 1.2.2.3 Additional Attributes
1.2.3 Request a certificate for a smart card on behalf of another user by using the smart card certificate enrollment station 1.2.3.1 Certificate Template 1.2.3.2 Certification Authority 1.2.3.3 CSP 1.2.3.4 Administrator signing certificate 1.2.3.5 User to enroll	Enterprise CA only
2. View the status of a pending certificate request
3. Download a CA certificate, certificate chain, or CRL
3.1 To trust certificates from this CA, install this CA certificate chain.
3.2 To download a CA certificate, certificate chain, or CRL, select the certificate and encoding method. 3.2.1 CA certificate Select CA 3.2.2 Encoding method Select DER or Base64 Then select: Download CA certificate Download CA certificate chain Download latest base CRL Download latest delta CRL	Downloaded files are using the following format: *.cer format (for certificates) *.p7b format (for certificate chains) *.crl format (for CRLs and delta CRLs)

Scripted enrollment options for custom enrollment interfaces

In case your organization has special enrollment requirements, Windows 2000 and Windows Server 2003 make it relatively easy for a developer to modify existing or to develop custom certificate enrollment interfaces.

You can use the CAPICOM automation object. CAPICOM can be used for signing enrollment requests or adding multiple signatures to a CMC- formatted enrollment request. CAPICOM is not installed by default on a Windows Server 2003 platform. You can download CAPICOM version2.0.0.3 (cc2rinst.exe) from the Windows Platform SDK Redistributables Web site at http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=860ee43a-a843-462f-abb5-ff88ea5896f6.

Windows 2000 and Windows Server 2003 also come with two reusable software modules that can be called from any customized certificate enrollment application: the Certificate Enrollment Control (CEC) and the Smartcard Enrollment Control (SEC). The certificate request wizard, discussed earlier, uses the CEC.

Both modules are located in the %windir%\system32\certsrv\certcontrol\x86 directory on the server side and in the %windir%\system32 directory on the client side. A client-side copy of the controls is needed to enable the module to write to the local certificate stores. The CEC and SEC are extensively documented in the Windows 2000 security platform SDK.

The SEC module (scrdenrl.dll) enables an administrator who has an enrollment agent certificate to request certificates on behalf of other users, and to store them on a smart card.

15.2.3 Key generation

Certificate enrollment starts with key generation. During the key generation process, an asymmetric key pair or a private and public key are generated. Most PKI-enabled applications use a single key pair; some use a dual key pair or even a triple key pair. Secure mail applications that are providing key recovery, for example, use a dual key pair to enable both the support for encryption key recovery and nonrepudiation services based on the user’s signing key. Both services have different requirements. Nonrepudiation and digital signatures require that the access to and the use of the signing private key is strictly limited to a single user. Key recovery, on the other hand, requires the private decryption key to be archived in some centralized database. In a triple key pair model, one key pair is used to identify a user, one is used for digital signatures, and another one is used for data encryption.

Remember from Chapter 13 that once the private key has been generated it must be stored in a secure place. The latter can be a secure file system location (e.g., a DPAPI-secured part of the user profile) or in the best case a smart card.

In Windows 2000 and Windows Server 2003 the tasks of key generation, secure private key storage, and embedding the public key in a certificate request are all performed by the CEC (xenroll.dll) and SEC (scrdenrl.dll). Both modules were explained in the previous section. Certificate request generation is covered next.

15.2.4 Certificate request creation

When the public key is prepared for certification, it is embedded in a certificate request. A certificate request contains besides the public key also the identity of the certificate requestor, the location (read: certificate store) where the certificate must be published, and some other request attributes that depend on the type of CA to which the request is sent. A commonly used certificate request format that is supported in both Windows 2000 and Windows Server 2003 PKI is PKCS10, which defines the certificate request syntax. More information on PKCS10 is available from http:// www.rsasecurity.com/rsalabs/pkcs/pkcs-10/index.html. Windows Server 2003 PKI also supports the CMC syntax. CMC stands for Certificate Management messages over CMS and is defined in RFC 2797 (available from http://www.ietf.org/rfc/rfc2797.txt). CMS stands for Cryptographic Message Syntax. CMS is defined in PKCS7 (more information on PKCS7 can be found at http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html).

There are two ways to look at the content of a Windows 2000, Windows XP, or Windows Server 2003 certificate request as it is submitted to a CA:

• On the PKI user side: Open the Certificate Enrollment Requests certificate container in a user’s certificate store. When you open a certificate request, you will see properties similar to the ones illustrated in Figure 15.15. Note that the General tab of the certificate request properties shows an integrity error.

  

  
  Figure 15.15: Content of a certificate request.

• On the CA side: Open the Pending Requests container, right-click a pending request in the right pane of the Certification Authority MMC snap-in, and select All Tasks\View Attributes/Extensions...

Windows 2000 and Windows Server 2003 also support the Simple Certificate Enrollment Protocol (SCEP), a certificate enrollment protocol developed by Verisign and Cisco. The support for SCEP enables, for example, a Cisco router to enroll for an IPsec certificate with a Windows 2000 or Windows Server 2003 CA. More information on SCEP can be found at http://www.cisco.com/warp/public/cc/pd/sqsw/tech/scep_wp.htm. The SCEP support add-on for Windows Server 2003 can be downloaded from the following URL: http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=9f306763-d036-41d8-8860-1636411b2d01.

To enable a Windows 2000 or Windows Server 2003 CA to support SCEP, you must install the mscep.dll (an ISAPI filter) coming with the Windows 2000 or Windows Server 2003 resource kit. A detailed procedure on how to set this up is also available in the resource kit and in the Q249125 Microsoft Knowledge Base article titled “Using Certificates for Windows 2000 and Cisco IOS VPN Interoperation” that is available at http://support.microsoft.com/?kbid=249125.

15.2.5 Requestor identification

Before the certificate is actually generated by the CA, the CA will validate the certificate request (this includes the validation of the request format) and identify the requesting user. Identification is an often forgotten, critical step of certificate enrollment. Identification means that the CA will check whether the entity requesting the certificate is really the one that is mentioned in the request message and whether the requesting entity possesses the private key corresponding to the public key in the certificate request.

In Windows 2000 and Windows Server 2003, the identification method depends on the enrollment interface the PKI user uses to enroll for a certificate. When users enroll for certificates using the certificate enrollment wizard, the CA authenticates users using the Kerberos protocol. The CA will use the NTLM protocol to authenticate clients when the client does not support Kerberos or when there is no Kerberos KDC available. The NTLM authentication protocol is explained in Chapter 4; Kerberos authentication is explained in Chapter 5.

The authentication protocol that is used when enrolling through a Web interface depends on how authentication has been configured on the CA Web directory (certsrv). For more information on the IIS authentication options, see Chapter 6.

CA administrators that want to use user identification methods other than the ones that are rooted on the Windows and IIS authentication protocols can configure the Windows CA to require CA certificate manager approval before the certificate is actually issued—this means that the request will go to a pending state when it arrives at the CA. As part of the CA certificate manager approval process, the manager can then identify the user using a custom method (e.g., face-to-face identification or identification based on the user’s driver’s license). After the user is uniquely identified using the custom method, the manager can then manually issue the certificate. When using an enterprise CA, certificate manager approval can be configured on the certificate template level. A stand-alone CA by default puts all incoming requests in a pending state. The latter can be changed from the policy properties of the CA object (as illustrated in Figure 15.16).

15.2.6 Certificate generation

During certificate generation the CA will sign the certificate content using its private key. The content of a certificate depends on the content of the certificate request. In the case of an Enterprise CA, some of the requestor-specific data are retrieved from the Active Directory. The layout of the certificate is defined in certificate templates that the CA retrieves from the AD or the registry.

Figure 15.16: Changing a stand- alone CA’s policy properties.

15.2.7 Certificate distribution and publication

Once a certificate has been generated, it can be distributed and published. Most PKI systems publish the certificate in a directory. In Windows 2000 and Windows Server 2003, certificate publication to AD depends on a certificate template setting.

• On version 1 certificate templates the AD publication behavior cannot be changed. For an overview of which V1 certificate templates publish certificates to AD, see “Certificate templates” in Section 13.4.4.

• On version 2 certificate templates AD publication depends on a changeable template property: Publish certificate in Active Directory. This property can be changed from the General tab of the certificate template properties (as illustrated in Figure 15.17).

  
  Figure 15.17: Certificate template property for certificate AD publication.

To publish certificates to other locations than AD (e.g., other LDAP directories or Web sites), you can develop custom exit modules that can be plugged into the Windows CA architecture. For more information on exit modules, see Chapter 13. In case you want to do this, remember that no matter what exit modules you create and install, certificates will not be published unless the publication location is specified in the certificate request.

To distribute the certificate back to the user, a Windows enterprise CA sends a copy to the user using a CMC- or PKCS7-formatted message. Certificates returned from the CA are then automatically installed in the user’s certificate store. When requesting a certificate using the Web enrollment pages, the user also has the option to store the returned certificate in the local machine’s certificate store. This way the certificate becomes available to all users logging on to that system. A stand-alone CA stores the newly generated certificate on the CA’s Web site, from which it can then be retrieved by the user.

An interesting detail related to certificate publication is that the machine account of the server hosting the CA must be a member of the Cert Publishers global group of every domain in the forest. Members of this group are the only ones who can write certificates to the usercertificate attribute of AD user objects.

^[1]It is not required that the enrollment agent’s proper certificate and private key are stored on a smart card for this enrollment model to work.

^[2]Enrolling for certificates that must be stored on a smart card requires the user to enter a smart card in the smart reader. In most cases it also requires the user to enter a PIN code.

^[3]The IE Enhanced Security Configuration basically locks down the security settings of the IE Web content zones.