Enrollment Processing

Applies To: Windows Server 2003 with SP1

Enabling Referrals Across Forests

Windows Server 2003 native Active Directory domains now support Kerberos trust and referrals across forests. By default, a Windows Server 2003 CA will not chase a referral for user or computer information in a trusted forest. When referrals are not chased and the user information is not available, the request will be denied if the user is enrolling from another forest. Referral chasing is not enabled by default as unintended template enumeration and enrollment may occur in some scenarios.

To enable referral chasing, use the following command on the certification authority and stop and start the service:

certutil -setreg policy\EditFlags +EDITF_ENABLELDAPREFERRALS 

Note

For this to work, you need to use Kerberos Forest Trust as opposed to normal External Domain Trust. For more information, see the Windows Server 2003 help files.

Enabling Netscape Browser Enrollment

The following configuration change must be made to a Windows Server 2003 CA to permit Netscape 6.2.2 and later browsers to perform enrollment through the Web enrollment pages.

To enable the parsing of request attributes for subject information, which is required for Netscape browser enrollment, use the following command:

certutil -setreg ca\CRLFlags +CRLF_ALLOW_REQUEST_ATTRIBUTE_SUBJECT 

The certification authority must be stopped and re-started for this change to take effect. If this is not enabled, Netscape clients will receive the following error in the event log when the enrollment fails: The request subject name is invalid or too long.

Adding CRL Information in an Authority Revocation List

Neither Windows clients nor Windows certification authorities use or process authority revocation lists. However, some manual steps may be followed to artificially create an ARL.

To place a CRL in the ARL attribute in the directory, use the following command where the CAName, MachineName, Domain information, and name of the CRL are specific to the PKI environment and must be specified by the administrator:

certutil -addstore "ldap:///CN=CAName(KeyIndex),CN=MachineName,CN=CDP,CN=Public Key 
Services,CN=Services,CN=Configuration,DC=Domain2,DC=Domain1,DC=com?auth 
orityRevocationList" <name of CRL file.crl> 

To delete an old CRL from the same attribute, use the same command, but use the –delstore instead of –addstore flag and specify the hash of the CRL instead of the CRL file as the last parameter. To display all CRLs with that attribute, use the –store flag and no ending parameter.

Allowing and Blocking Extensions in Certificate Requests

The template extension processing takes place *before* the three object identifier lists in the registry are processed.

The following configuration change must be made to a Windows Server 2003 CA to configure the CA to allow custom extensions to be added or blocked in certificates issued by the CA. Due to the fact that custom extensions comprise custom ASN.1 data, the CA is unable to parse and validate the information contained in the extension. If the certificate request contains the custom extension information properly encoded, the CA can be configured to pass the extension into issued certificates without validating the information. The extension must exist in the request as the CA will not generate this information. The request should be evaluated by a Registration Authority process before processing such requests.

To enable custom extension passing by using the object identifier of the custom extension defined by the organization, use the following command:

certutil -setreg policy\EnableRequestExtensionList +< object identifier of extension to be added>

The certification authority must be stopped and re-started for this change to take effect.

Example The Netscape certtype extension is not enabled by default on a Microsoft CA and must be enabled using the previous mechanism.

To accept the Netscape certtype revocation extension to be included in issued certificates, use the following command:

certutil -setreg policy\EnableRequestExtensionList +2.16.840.1.113730.1.1

To add a custom extension during CA installation through a capolicy.inf file or to submit a request using certreq.exe and a policy.inf file, the following information can be added to the extensions section of the *.inf file as an example. The object identifier of the extension must be specified followed by the Base64 representation of the value to be included in the extension. For example, AwIBBg== is the Base64 representation of the ASN.1 value: 03 02 01 06.

[Extensions]

1.3.6.1.5.5.7.1.3= AwIBBg==

To disable a certificate extension from being added to a certificate that is included by default in certificates issued by an enterprise CA, such as the S/MIME capabilities extension, use the following command, and then re-start the CA:

certutil -setreg policy\DisableExtensionList +< object identifier of extension to be added> 

Note

When encountering template extensions with conflicting object identifiers, an Enterprise CA will override the EnableRequestExtensionList and EnableEnrolleeRequestExtensionList registry value behavior. If the certificate request includes extensions whose object identifiers conflict with the template extensions, the template extensions will override the request extensions. The EnableRequestExtensionList and EnableEnrolleeRequestExtensionList registry values merely cause the disabled bit to be cleared for any extensions in the two registry object identifier lists that exist. Extensions supplied by the template will already have the disabled bit clear. The object identifier list in EnableEnrolleeRequestExtensionList is only processed for templates that are configured to allow the request supply subject information. The object identifier list in EnableRequestExtensionList is processed for all templates. The object identifier list in DisableExtensionList causes the disabled bit to be set for any extensions in the list that exist—without regard to the origin of the extension (request or template). This prevents the listed extensions from appearing in issued certificates. This object identifier list is also processed for all templates.

Adding an E-Mail Address to the SubjectAltName Extension

The following configuration option applies to stand-alone CAs only. Enterprise CAs may add e-mail address information to certificates automatically (if specified in the template) based on the user account information in Active Directory. One of the few configuration options that may be set for subject naming on a stand-alone CA is the ability for the CA to place the e-mail address of the requestor (authenticated user making the request) in the SubjAltName extension of an issued certificate.

To set the policy module to allow this option, perform the following steps using regedit.exe on the stand-alone CA:

Set the following REG_SZ value to Email in the registry, and then restart the CA:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\SubjectAltName2

The <CAName> is the name of the local CA.

Set the e-mail request attribute to the users e-mail name by specifying the following request attribute string in the Web enrollment pages: email:joe@northwindtraders.com. As an alternative, set the e-mail name as part of the subject name E= email:joe@northwindtraders.com as part of the full subject distinguished name, or just joe@northwindtraders.com if there is a separate e-mail text box on the Web page.

The following is the syntax for specifying a Subject Alt Name 2 extension as a request attribute; it will only work on a Windows Server 2003 CA server and requires enabling the flag to process this attribute in the registry:

SAN:1.2.3.4={asn}Base64String&email=sample@bar.com&dns=sample.bar.com&dn="CN=xxx,OU=xxx,DC=xxx"&url="https://sample.com/default.htlm"&ipaddress=172.134.10.134&oid=1.2.3.4&upn=sample@bar.com&guid=f7c3ac41-b8ce-4fb4-aa58-3d1dc0e36b39

To set the Subject Alt Name 2 extension to a specific UPN value:

SAN:upn=sample@bar.com

To set it to a specific DNS name:

SAN:dns=sample.bar.com

To set both:

SAN:upn=sample@bar.com&dns=sample.bar.com

To enable the registry flag for a CA:

certutil –setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

or certutil –setreg policy\EditFlags +0x40000

And restart the CA.

How to Change the Validity Period for Certificates Issued from a CA

Enterprise CAs set the validity of issued certificates through the settings on Active Directory-based templates. Stand-alone CAs enforce the validity period of issued certificates based on registry values. To change the default validity period intervals for all certificates that are issued by a stand-alone CA, set the following registry values:

HKLM\system\currentcontrolset\services\certsvc\configuration\<ca name>\validityperiod (=days/months/years)

HKLM\system\currentcontrolset\services\certsvc\configuration\<ca name>\validityperiodunits (=number of above)