Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

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.

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