Example Scenario for Contoso

Applies To: Windows Server 2003 with SP1

Since a lot of planning considerations and best practice approaches are covered in the previous section, here is a real world example of PKI topology. The example describes the best practices that are mentioned earlier in this document and also describes most of the options of a complex PKI. By leaving out distinct components (like the HSM or the intermediate CA level), you can also adjust the topology to environments for smaller organizations.

The fictitious organizations name is Contoso Company. Contoso is an international company that has already deployed Active Directory and is introducing a Windows Server 2003 PKI. The planning for the project is already finished. Besides other preparation work, the parameters as listed in Appendix B, which will drive the PKI configuration.

Use the following installation instructions to set up a PKI that is similar to the Contoso PKI.

Platform Decision

The Contoso Corporation has decided to deploy a Windows Server 2003 PKI hierarchy. The organization recognizes ease of deployment, benefits of strengthened security, security-integrated applications, and the Active Directory-integrated management infrastructure that is in their current Active Directory infrastructure.

Because Contoso wants to benefit from all PKI improvements to the Windows Server 2003 family, they have prepared Active Directory to run in a Windows Server 2003 forest and in Windows Server 2003 domain functional mode. For more information about how to raise the domain functional level on a computer running a member of the Windows Server 2003 family, see the article "How to raise Active Directory domain and forest functional levels" on the Microsoft Knowledge Base.

The Contoso company has a mix of clients that are running a member of the Windows 2000 family or Windows XP Professional and uses a number of integrated applications that can take advantage of the Windows Server 2003 PKI, including Secure/Multipurpose Internet Mail Extensions (S/MIME), encrypting file system (EFS), L2TP or IPsec VPN connections, 802.1x wireless access, and SSL-enabled Web servers. Smart cards are used for user logon.

PKI Design

Contoso has decided that a three-tier PKI topology is most suitable for their organization. If an organization wants to benefit from a two-tier PKI topology, the implementation guidelines that are outlined in this documentation can also be applied.

The Contoso PKI consists of different certificate servers. Every CA will be implemented with Certificate Services as implemented in Windows Server 2003, Enterprise Edition. The following figure illustrates the Certificate Services architecture for Contoso Corporation.

Figure 5: CA Hierarchy for Contoso Corporation

Root CA

The Contoso stand-alone root CA is never connected to a network and remains offline and physically secured. The root CA issues and revokes certificates for intermediate CAs in the hierarchy. To raise the security level of the CAs private key, an HSM extends the root CAs hardware configuration. The CA certificate and the CRL are manually published and made available through an HTTP and an LDAP distribution point.

Intermediate CAs

The intermediate CAs are physically secured and operated offline. Contoso has decided to operate two intermediate CAs. The separation of intermediate CAs allows the organization to set different CRL distribution points and CRL publishing intervals. Since intermediate CAs are also treated as sensitive components in the organization's PKI, they are also equipped with HSMs.

Issuing CAs

The issuing enterprise CAs are responsible for certificate enrollment to end-entities. These CAs are distributed to different geographic locations to allow local availability. Physical security, however, has to take precedence over close proximity of the servers. These CA servers are online and available to service requests at any time. You can improve availability in the future by deploying more issuing CAs.

Contoso Environment Summary

The following list describes the Contoso environment:

• A forest and domain environment with computers that run only members of the Windows Server 2003 family

• Clients that are running either Windows 2000 or Windows XP

• Three-tier PKI hierarchy

• Self-signed stand-alone offline root Windows Server 2003, Enterprise Edition stand-alone CA with HSM to support role-separation

• Intermediate offline stand-alone Windows Server 2003, Enterprise Edition stand-alone CA with HSM to support role separation

• Several online, Active Directory-integrated issuing Windows Server 2003, Enterprise Edition CAs to support auto-enrollment and V2 templates.

Stand-alone Offline Root CA

The following section describes the steps that you should use to install an offline root CA by using a computer running Windows Server 2003, Standard Edition. The installation procedure for a Windows 2000 CA is similar to the installation procedure for a computer running Windows Server 2003, Standard Edition, so you can also use the following installation procedure on computers running Windows 2000.

Installation Prerequisites

A server that is running Windows Server 2003, Standard Edition is installed with the base operating system and latest updates. Verify that you have the following information before you start to install Certificate Services:

• The CPS that has all of the parameters that are specific to the organization

• The Windows Server 2003 installation medium, such as the original CD-ROM

• Appropriate hardware with a floppy disk drive

• Both computer and CA naming conventions

• Directory and file paths to be used for CRL distribution point, such as AIA

• Other CA configuration information, such as CRL publication intervals

• HSM, if applicable

Install the Offline Root CA

To set up the root CA, use the steps in this section. Before you begin, verify that the following concepts have been reviewed and approved by your organization:

• Public key infrastructure concepts

• Requirements that describe the purpose of certificate usage and enrollment

• Details about CA configuration including the hierarchy of the PKI

• The renewal strategy that you are going to use for the root CA is planed

• Operational security procedures and policies

Workgroup Membership

The CorporateRootCA must be a workgroup member because it is not connected to the network and has no link to a domain controller. Nevertheless, the server name must be unique in your organization because the server name is part of the information that will be published in Active Directory.

Verify that the naming information is correct after you log on to the local computer by using the net config workstation command at a command prompt. (Note that the values that are in italics may be different for you, according to your configuration.) The following section is an example of how you can use the net config workstation command to accomplish this.

D:\>net config workstation
Computer name                        \\CONCORP-CA-00
Full Computer name                   concorp-ca-00
User name                             Administrator 
Workstation active on
        NetbiosSmb (000000000000)
        NetBT_Tcpip_{7CD8C0C6-02A5-4EB4-8081-5D1977FD0AA5}
(0008C75BDEC0)
Software version                     Microsoft Windows Server 2003
Workstation domain                    WORKGROUP 
Logon domain                          CONCORP-CA-00 
COM Open Timeout (sec)               0
COM Send Count (byte)                16
COM Send Timeout (msec)              250
The command completed successfully.

Verify that the logon domain name is the same as your server name.

For more information, see the following articles on Microsoft Web sites:

• "Checklist: Creating a certification hierarchy with an offline root certification authority" on the Microsoft Web site

• "HOW TO: Install a Windows 2000 Certificate Services Offline Root Certification Authority" on the Microsoft Knowledge Base

Installing an HSM on an Offline Root CA

Some organizations may choose to protect the root private key with additional hardware. Before you install and configure Certificate Services, verify that the HSM is correctly set up according to the manufacturer's installation instructions. For information about how to install an HSM on computers that are running either Windows 2000 or Windows Server 2003, see the following Web sites:

• Windows 2000 Server and PKI: Using the nCipher Hardware Security Module on the Microsoft Web site

• Deploying Certificate Services on Windows 2000 and Windows Server with the Chrysalis-ITS Luna CA3 Hardware Security Module on the Microsoft Web site

Prepare the CAPolicy.inf File for the Root CA

An issued certificate typically inherits properties (for example, certificate lifetime, the distribution point of the CRL, and other parameters) from a certificate template that is provided by the issuing CA. Since the root CA requires a certificate for itself, the root CA must self-sign the root CA certificate because there is no parent CA that could issue the CA certificate.

Before the CA certificate is generated, custom configuration of the CA that is relevant to the CA certificate is required. The CAPolicy.inf file has all configuration information that is required to generate the self-signed CA certificate according to the organizations needs.

To ensure that the CAPolicy.inf file is correctly processed:

• The ASCII text file must be available on the local computer before the CA setup procedure starts or before CA certificate renewal is attempted

• The file is placed in the %Systemroot% folder on the local computer on which the CA is installed

The syntax follows the specification that is described in the CAPolicy.inf syntax" section in the appendix of this document.

Also, during the installation procedure, you do not receive a warning message if the CAPolicy.inf file is not in the correct format because there is no syntax or error-checking mechanism. For setup logging and debug information, see the Systemroot\Certocm.log file.

To configure the CAPolicy.inf file:

1. Log on to the CorporateRootCA computer as an administrator.

2. Open a text editor, such as Notepad.

3. Copy the sample text file that is in the "Sample CAPolicy.inf file for the CorporateRootCA" section of this document as a template.

4. Paste the text into the file and then save it to %Systemroot%\CAPolicy.inf.

Installing the Offline Root CA Software Components

To install the offline root CA software components, use the following procedure.

1. Log on to the CorporateRootCA computer as an administrator. Note that this account will be permitted as a CA administrator during the CA installation procedure. You can delegate the CA administrator role to other user accounts after the setup and configuration procedures are finished. For more information about CA roles and permission, see Windows Server 2003 Server Help.

2. Use one of the following procedures to open Add/Remove Windows Components:

   To use a command prompt:

   1. Click Start, click Run, type cmd, and then click OK.

   2. At the command prompt, type sysocmgr /i:sysoc.inf and then press ENTER.

   To use Control Panel:

   1. Click Start, point to Settings, and then click Control Panel.

   2. Click Add or Remove Programs.

   3. In Add or Remove Programs, click Add/Remove Windows Components.

   Note

   To run Certificate Services, check for the following software components:

   • Certificate Services

   • Internet Explorer

   • (Optional) Certificate Services Web enrollment support

   • (Optional) Internet Information Services for Web enrollment support

   It is not recommended that you install any other Windows components on a Windows Server CA. If you install additional components, reliability or security of a root CA may be compromised if a secure configuration is required by the organization.

   An offline Windows 2000 CA requires Internet Information Services to support offline CA enrollment. Unlike Windows 2000 Server, a Windows Server 2003 certification authority can process offline certificate requests within the Certification Authority MMC

3. In the Windows Components Wizard, select the Certificate Services check box, and then click Next.

4. In CA Type, click Stand-alone root CA, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

   It is expected that the enterprise root CA and enterprise subordinate CA options are not available because the computer is not a member of an Active Directory domain.

5. Do one of the following:

   • If you installed an HSM, in CSP, select the CSP that you installed during the HSM installation procedure.

   • If you did not install an HSM, in CSP, click Microsoft Strong Cryptographic Provider.

6. In Hash algorithm, click the default hash algorithm, SHA-1.

   SHA-1 is the most common and interoperable hash algorithm that is used by applications and operating systems. For more information about CSP support on computers that are running Windows 2000, see "Microsoft Enhanced CSP Is Not Supported for Certificate Services Installations" on the Microsoft Knowledge Base.

7. In Key length, click 4096.

   If you choose a different key length, confirm that the key length is interoperable with organizational applications and other PKI components. There is no verification of the key length that you type into the box. If an HSM or smart card CSP is utilized, the CSP will be required to interact with the desktop.

8. Confirm that both the Allow this CSP to interact with the desktop check box and the Use an existing key check boxes are cleared, and then click Next.

9. On CA Identifying Information, in Common name for this CA, type a name that will identify the CA to you. In this example, use CorporateRootCA.

   As it is specified in the certificate practice statement, you must specify a common name (CN) for the CA. The CN cannot exceed 64 characters in length, however, it is recommended that you use a maximum length of 51 characters to prevent an encoding length rule violation.

10. (Optional) In Distinguished name suffix, type DC=concorp,DC=contoso,DC=com.

    If you type a name, confirm that you have typed it correctly so that it works in the context of the Active Directory domain name. In the Contoso scenario, the distinguished name is DC=concorp,DC=contoso,DC=com. If you install a CA on a computer that is a domain member with Enterprise Administrator privileges, the distinguished name suffix is automatically configured. You can also set the distinguished name suffix at a later time by using the Certutil.exe command.

11. In Validity period, select 10 years.

    Enter the validity time as defined in your organization's certificate practice statement. In this example, a validity period of 10 years is set for CorporateRootCA.

12. If you have uninstalled a CA on this computer already, you receive a warning message that confirms that you want to overwrite the private key from the previous CA installation. It is recommended that you ensure that the private key is never required again. If you make a backup copy of the system, it is more likely that you will not lose any data. (Instead of backing up the entire system, you can also make a backup copy of the private key. To do this, at a command prompt, type certutil –backupkey -?) If you are not sure if you want to overwrite the private key, click No to cancel the installation procedure. If you click Yes, a new key is generated and the new key replaces the existing key. Note that Windows 2000 CAs do not support the distinguished name suffix specification as part of the installation wizard.

    The public and private keys are then generated by the CSP. If you use the default CSP, the keys are written to the local computers key store. If you did not use an HSM, the key is generated by CryptoAPI and is stored in the profile of the system account on the local computer. The length of time that is required to generate the key depends on both the size of the key that is generated and the CPU performance of the local computer. If an HSM is installed and selected, the key is generated in the HSM and stored according to the HSM specific architecture. Since no certificate templates are available on a stand-alone CA server that is a member of a workgroup, the CA certificate needs to be built from configuration information in the registry. The following default key usage extension values are added to the CA certificate:

    • Digital signature

    • Certificate signing

    • Certificate offline CRL signing

    • Certificate CRL signing

    However, if a root CA is installed on a computer that is running either a member of the Windows 2000 family or a member of the Windows Server 2003 family, and that computer is a domain member, the CA inherits the Enhanced Key Usage extension settings from the CA template in Active Directory, even if the CA is installed as a stand-alone CA. If no Active Directory is available, the Enhanced Key Usage settings are also taken out of the configuration that is available in the registry.

13. In Certificate database and Certificate database log, enter the locations of the certificate database and the log files for the certificate database.

    The certificate database and the certificate database log must be saved to a local NTFS hard disk.

    On a stand-alone CA that is expected to infrequently issue CA certificates, you can retain both the certificate database and the certificate database log on the local computer's hard disk. To ensure that the CA is reliable and available, schedule backup operations of the computer. Backup may be performed even if the CA service is not running. For more information about CA backup and recovery, see "Certification Authority backup and recovery" in this document.

14. (Optional) To install a CA in the same location as a previously installed CA, select the Preserve existing certificate database check box.

    If you select this option, the new CA will use the existing database and preserve the certificates in the database. If you do not select this option, the existing database will be deleted. You should use this option only when you are trying to restore a CA from a backup or for CA migration.

    You can move both the database and log files to a different location. For more information, see HOW TO: Move the Certificate Server Database and Log Files on the Microsoft Knowledge Base.

15. Select the Store configuration information in a shared folder check box and, in Shared folder, enter a local pathname as the name for the shared folder, such as C:\CAConfig, and then click Next.

    The CA setup procedure cannot detect if the computer is supposed to run as either an online or offline CA. For an offline CA, the shared folder is not necessary, but must still be specified. If the CA is connected to the network, clients can gain access to the CA certificate through the shared folder.

    Depending on the name of the shared folder, a new share is created on the CA server computer. The path to the shared folder can be either a universal naming convention (UNC) path such as the default, \\Localhost\CAConfig, or a local path, such as C:\CAConfig. If the server does not have network cards installed or has all network interfaces disabled, you must choose a local path.

    Some information that is stored in the CAs configuration directory must be published to the organization's Active Directory at a later stage. For more information, see "Import parent CA certificates and CRLs into Active Directory" later in this document.

    When the Windows Components Wizard completes the Certificate Services configuration, you may be asked for the server's installation media to finish the installation.

    Because you do not need to install IIS on this computer, you may receive a warning message that states that the Certificate Services Web Enrollment Support is unavailable. If you receive this message, click OK and complete the installation procedure.

    Figure 6: IIS Installation Warning

Verify the Root CA Configuration

The next procedure helps you to ensure that the root CA is correctly configured ready for production operations.

Verify the Root CA Certificate

Because the CA certificate is mandatory for a reliable certificate validation of all certificates that have been issued by your PKI, it is important to ensure that this certificate has all of the necessary information before proceeding with the installation of a CA hierarchy.

1. On the local root CA computer, at a command prompt, type:

   certutil –ca.cert corporateRootCA.cer

2. View the CA certificate to validate the information that is in the CA certificate. To do this, at a command prompt, type:

   certutil.exe corporateRootCA.cer

3. Verify that the italicized parameters are the same parameters that you noted in the configuration document in the previous section. In addition, make sure that the certificate lifetime is set to a period of 10 years.

   Signature Algorithm:
       Algorithm ObjectId: 1.2.840.113549.1.1.5  sha1RSA 
   Issuer:  CN=CorporateRootCA 
   NotBefore: 6/5/2002 7:47 PM
   NotAfter: 6/5/2012 7:54 PM
   Subject:  CN=CorporateRootCA
   

Verify the CorporateRootCA Configuration Information

Use the steps in this section to verify the CA configuration:

1. At a command prompt, type certutil –cainfo and verify the CA type. The result will be similar to the following:

   CA type: 3 -- Stand-alone Root CA
       ENUM_STANDALONE_ROOTCA -- 3
   

2. At a command prompt, type certutil –getreg | find /I Directory to verify the database settings. Verify the following italicized output:

   ConfigurationDirectory   REG_SZ =  \\concorp-ca-00\CertConfig 
     DBDirectory              REG_SZ =  C:\WINDOWS\system32\CertLog 
     DBLogDirectory           REG_SZ =  C:\WINDOWS\system32\CertLog 
     DBSystemDirectory        REG_SZ =  C:\WINDOWS\system32\CertLog 
     DBTempDirectory          REG_SZ =  C:\WINDOWS\system32\CertLog
   

Offline Root CA Configuration

After the stand-alone offline root CA is installed, you must configure the properties of the offline root CA for certificates that are subsequently issued from the CA. These extensions are necessary to ensure correct revocation and chain building.

You can perform all of the steps that are described in this section by using one batch script. For more information, see Sample script to configure CorporateRootCA in this document.

Map the Namespace of Active Directory to an Offline CA's Registry Configuration

Because the offline root CA is not connected to the domain and does not automatically publish the CRL to Active Directory, you must set a key in the registry. To do this, at a command prompt, type the following command and then stop and start the CA service:

certutil.exe –setreg ca\DSConfigDN CN=Configuration,DC=concorp,DC=contoso,DC=com

where DC=concorp,DC=contoso,DC=com is the namespace of the forest root domain. This setting is primarily required for CRLs and CA certificates (AIA) that are published in Active Directory.

This registry value sets the %6 replacement token that is required for the CRL location extension, as well as the CRL and AIA distribution points that are described in "Configure CorporateRootCA distribution points for CRL and AIA. For more information about the %6 replacement token, see CRL distribution point replacement token in this document.

Configure CorporateRootCA Distribution Points for CRL and AIA

The CRL and AIA distribution points must be set before any certificates are issued from the new CA.

This configuration step ensures that the correct information is embedded in each of the issued certificates so that the certificate's signature and revocation status can be verified. For additional information about certificate status and chain building, as well as how the AIA and CRL distribution point extensions are used by CryptoAPI, see Certificate Revocation and Status Checking (https://go.microsoft.com/fwlink/?LinkID=27081).

For all CA types (online or offline, root or subordinate, enterprise or stand-alone), the configuration of the AIA extension and the CRL distribution point extension is critical. If they are not configured correctly or if they contain invalid extensions, there may be unexpected problems. For example, smart card login attempts may not work, there may be invalid e-mail digital signatures, or there may be Web sites that are not trusted.

Configure CorporateRootCA Distribution Points for CRL and AIA by Using the User Interface

CRL distribution point and AIA extension changes take effect only after the CA is restarted and the extensions appear in certificates issued only after the changes are applied.

On computers that run a member of the Windows 2000 family, the CRL and AIA configuration process is different than on computers that are running a member of the Windows Server 2003 family.

Before changing the CRL configuration, verify the default settings.

Log on to the computer with an account that has Certification Authority Administrator permissions.

Type the following at a command prompt:

certutil -getreg ca\CRLPublicationURLs

The following report of the default CRL distribution points is displayed. Note these settings if you need to change the CRL configuration to its original state.

CRLPublicationURLs REG_MULTI_SZ =
    0: 65:C:\WINDOWS\system32\CertSrv\CertEnroll\%3%8%9.crl
    CSURL_SERVERPUBLISH -- 1
    CSURL_SERVERPUBLISHDELTA -- 40 (64)
 
    1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
    CSURL_SERVERPUBLISH -- 1
    CSURL_ADDTOCERTCDP -- 2
    CSURL_ADDTOFRESHESTCRL -- 4
    CSURL_ADDTOCRLCDP -- 8
    CSURL_SERVERPUBLISHDELTA -- 40 (64)
 
    2: 6:https://%1/CertEnroll/%3%8%9.crl
    CSURL_ADDTOCERTCDP -- 2
    CSURL_ADDTOFRESHESTCRL -- 4
 
    3: 0:file://\\%1\CertEnroll\%3%8%9.crl

As it is specified in the CPS, you must configure the CRL and AIA distribution point for certificates issued by this CA. To configure these extensions in a Windows Server 2003 CA, perform the following steps:

1. Log on to the computer running certificate services with an account that has Certification Authority Management permissions.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Certification Authority.

3. In the console tree, right-click the name of the CA that you want to work with, and then click Properties.

4. Click the Extensions tab.

Configure CorporateRootCA Distribution Points for the CRL

1. First, remove all of the CRL distribution point locations, except for the local CRL distribution point.

   Warning

   Do not remove the local CRL distribution point location. The local distribution point will look similar to the following path: C:\Windows\System32\CertSrv\CertEnroll<EM>CorporateRootCA.crl The CA must publish the CRL to the file system because all of the other distribution points are not accessible for this offline CA. The CA uses the local CRL to validate all certificates that are generated before the certificates are issued to users. The local path is not included in the CRL distribution point extension of issued certificates.

2. On the Extensions tab, in Select extension, select CRL Distribution Point (CDP).

3. In Specify location from which users can obtain a certificate revocation list (CRL), click the default LDAP location, click Remove, and then click Yes.

4. Repeat Step 2 for all CRL distribution point locations except for the local CRL distribution point.

After you remove all of the appropriate locations, the remaining list of CRL distribution points will be similar to the following figure.

Figure 7: CRL Distribution Point Locations

Now, you will add the desired CRL distribution point locations to the list.

To provide multiple access protocol methods for CRL retrieval, different distribution points are provided to facilitate heterogeneous environments. Note that the LDAP path that is listed in the following table contains information about the organization's Active Directory namespace. If the certificate will be exchanged with external parties, define a neutral namespace. The example in this section uses the following CRL distribution points in the following order.

Table 14 List of CRL Distribution Points for CorporateRootCA

The [local] path should be the current Windows installation directory.

The order in which you should choose the access protocols is based on the type of certificates that are issued by a CA. A CRL distribution point with HTTP as the first protocol in the list is recommended for environments where CRL distribution without latency is critical or where most clients are not joined to an Active directory domain. HTTP locations generally do not replicate and do not have latency issues whereas an LDAP distribution point might be located in a distributed directory service, like Active Directory. The CRL distribution points that are listed in the table use the replacement tokens that are described in CRL distribution point Replacement Token in this document. For more information about CRL naming, see the chapter CRL Best Practices.

1. Click Add, and in Location, type the appropriate CRL distribution point path from the previous table, and then click OK.

   You can also copy and paste the path from the table.

2. Repeat Step 1 for each type of access protocol.

   Next, you must set the configuration parameters that dictate how the CRL will be published by the CA. The properties must be set for every CRL distribution point path.

3. In Specify locations from which users can obtain a certificate revocation list (CRL), click one of the paths.

4. While still on the Properties tab, select or clear the check box that is listed in the previous table, depending on the type of path, and then click Apply.

5. Repeat steps 3 and 4 for each path.

   Table 15 CRL Distribution Point Properties

   CRL distribution point property	File	HTTP	LDAP
   Publish CRLs to this location check box	Select	N/A	Clear
   Include in all CRLs check box	N/A	N/A	Select
   Include in CRLs check box	N/A	Clear	Select
   Include in the CDP extension of issued certificates check box	N/A	Select	Select
   Publish delta CRLs to this location check box	Clear	N/A	Clear

   Note

   In Publish CRLs to this location, since the CorporateRootCA computer is not attached to the network, the CA cannot automatically publish the CRL to the LDAP CRL distribution point. By default, this option is chosen on an enterprise CA to automate the CRL publishing to the LDAP CRL distribution point. In Publish CRLs to this location, a UNC file path can be specified to publish to clustered Web servers using IIS for CRL fault tolerance. If the Publish Delta CRLs to this location check box is selected, make sure that the delta CRL is also published. For more information, see "Configure CRL publication interval via the user interface" in this document.

   For a description of CRL properties, see CRL publishing properties in this document.

Configure CorporateRootCA Distribution Points for AIA

1. In CorporateRootCAProperties, on the Extensions tab, select Authority Information Access (AIA).

2. In Specify locations from which users can obtain the certificate for this CA, click the default LDAP location, click Remove, and then click Yes.

3. Repeat the previous step to remove all of the entries except for the local entry.

   You can also clear the check boxes for all AIA publishing options instead of removing the AIA path from the list.

4. Click Add, and in Location, type one of the AIA distribution points from the following table, and then click OK.

5. Repeat the previous step for each AIA distribution point in the table below.

   Note that the LDAP path can expose internal namespace information if the certificates will be exchanged with external parties. Change the LDAP CRL distribution point to a permanent and publicly-available distribution point if certificates are exchanged with external parties.

   Table 16 List of AIA CRL Distribution Points for Contoso

   Access protocol	AIA Distribution Point
   [local]	D:\WINDOWS\system32\CertSrv\CertEnroll\%1_%3%4.crt
   HTTP	https://www.contoso.com/pki/%1_%3%4.crt
   LDAP	ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11

6. In Specify locations from which users can obtain the certificate for this CA, click one of the locations, and then select or clear the check boxes according to the following table.

   These configuration parameters control how the AIA extension is used by the CA in issued certificates. You must set the properties for every AIA path that is specified on the Extensions tab.

   Table 17 AIA Properties

   AIA property	FILE	HTTP	LDAP
   Include in the AIA extension of issued certificates check box	N/A	Select	Select
   Include in the online certificate status protocol (OCSP) extension check box	N/A	Clear	Clear

7. Repeat the previous step for each location, except for the file locations.

8. Click OK, and then click Yes to apply the changes you have made and restart the computer.

Configure the CorporateRootCA CRL and AIA CRL Distribution Point From a Batch File

The CRL distribution point path is stored as a multivalued extension in the registry. You can also set the appropriate value with the Certutil.exe utility. This procedure is similar to the steps that are outlined in "Configure CorporateRootCA distribution points for CRL and AIA by using the user interface" earlier in this document. To configure both the CRL distribution point and AIA paths for a Windows Server 2003 CA with Certutil.exe, follow the steps that are described in this section.

Certutil.exe interprets a multivalued extension when you use \n as part of the value string. If a multivalued extension consists of only one value, verify that \n is appended as the last character in the value string. Otherwise, you create a string value that might be not recognized by the CA. For more information, type certutil.exe –setreg -? at a command prompt.

1. On a server that is running one of the appropriate members of the Windows Server 2003 family, open a text editor, such as Notepad, and then copy the following text as two separate rows into the text editor.

   certutil -setreg CA\CRLPublicationURLs
   "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:https://www.
   contoso.com/pki/%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN
   =Public Key Services,CN=Services,%%6%%10"
   certutil -setreg CA\CACertPublicationURLs
   "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:LDAP:///CN
   =%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:https://www
   .contoso.com/pki/%%1_%%3%%4.crt"
   

   If a Windows 2000 Server is used, the following commands perform the same function as above:

   certutil -setreg policy\RevocationCRLURL
   "https://www.contoso.com/pki/%%3%%8.crl\n"
   certutil -setreg policy\LDAPRevocationCRLURL
   "ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key
   Services,CN=Services,%%6?certificateRevocationList?base?objectclass=
   cRLDistributionPoint\n"
   certutil -setreg policy\FileRevocationCRLURL "\n"
   certutil -setreg policy\IssuercertURL
   "https://www.contoso.com/%%1_%%3%%4.crt\n"
   certutil -setreg policy\LDAPIssuercertURL
   "ldap:///CN=%%7,CN=AIA,CN=Public Key
   Services,CN=Services,%%6?cACertificate?base?objectclass=
   certificationAuthority\n"
   certutil -setreg policy\FileIssuercertURL "\n"
   

2. Save the text file as %temp%\MyCRLCDP.cmd.

3. Close the text editor.

4. At a command prompt, type %temp%\MyCRLCDP.cmd to execute the commands from the text file.

5. At a command prompt, type net stop certsvc to stop the certificate server, because you must restart the computer to apply the change.

6. At a command prompt, type net start certsvc to restart the certificate server.

Verify the CorporateRootCA CRL and AIA Configuration

Because the configuration of CRL and AIA distribution points is very important, verify your configuration:

1. Do one of the following:

   If your CA is running	Do this
   A member of the Windows 2000 Server family	At a command prompt, type the following commands, pressing ENTER after each line: certutil –getreg policy\RevocationCRLURL certutil –getreg policy\LDAPRevocationCRLURL certutil –getreg policy\FileRevocationCRLURL
   A member of the Windows 2003 Server family	At a command prompt, type the following command, and press ENTER: certutil –getreg ca\CRLPublicationURLs

2. Verify that the output is similar to the values you have configured in the previous section.

3. Do one of the following:

   If your CA is running	Do this
   A member of the Windows 2000 Server family	At a command prompt, type the following commands, pressing ENTER after each line: certutil –getreg policy\IssuerCertURL certutil –getreg policy\LDAPIssuerCertURL certutil –getreg policy\FileIssuerCertURL
   A member of the Windows 2003 Server family	At a command prompt, type the following commands, pressing ENTER after each line: certutil –getreg ca\CACertPublicationURLs

4. Verify that the output resembles the following output and contains the proper organizational naming information.

   CACertPublicationURLs REG_MULTI_SZ =
       0: 1:D:\WINDOWS\system32\CertSrv\CertEnroll\%1_%3%4.crt
       CSURL_SERVERPUBLISH -- 1
       1: 2:ldap:///CN=%7,CN=AIA,CN=Public Key
   Services,CN=Services,%6%11
       CSURL_ADDTOCERTCDP -- 2
       2: 2:https://www.contoso.com/pki/%1_%3%4.crt
       CSURL_ADDTOCERTCDP -- 2
   

Configure CRL Publication Interval By Using the User Interface

After the CRL distribution point is set, you must configure the CRL publication interval. To configure the publication schedule, use the following procedure.

1. Click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

   This opens the Certification Authority MMC Snap-in.

2. In the console tree, right-click Revoked Certificates, and then click Properties.

3. In CRL publication interval, type a number for the CRL publication interval according to your CPS.

   For planning information, see Best practices for CRL publication in this document. Note that publishing by using minute-based intervals is available only through the registry and is not recommended for most installations.

4. Verify that the Publish Delta CRLs check box is not selected.

   The Publish Delta CRLs setting is not available on computers running a Windows 2000 CA.

Configure CRL Publication From a Batch File

You can configure the CRL publication schedule information in the registry by using the Certutil.exe utility. To configure the CRL publication schedule information by using Certutil.exe, use the steps in this section. Note that these steps work on a Windows 2000 CA.

1. Start a text editor, such as Notepad, and then copy the following text into a text file:

   certutil -setreg CA\CRLPeriodUnits 180
   certutil -setreg CA\CRLPeriod "Days"
   net stop certsvc & net start certsvc
   

2. Save the text file as %temp%\MyCRLPeriod.cmd, and then close the text editor.

3. At a command prompt, type %temp%\ MyCRLPeriod.cmd, and then press ENTER.

Instead, use these steps on a Windows Server 2003 CA.

1. Start a text editor, such as Notepad, and then copy the following text into a text file:

   certutil -setreg CA\CRLPeriodUnits 180
   certutil -setreg CA\CRLPeriod "Days"
   certutil -setreg CA\CRLDeltaPeriodUnits 0
   net stop certsvc & net start certsvc
   

2. Save the text file as %temp%\MyCRLPeriod.cmd, and then close the text editor.

3. At a command prompt, type %temp%\ MyCRLPeriod.cmd, and then press ENTER.

Set the Validity Period for Issued Certificates at the Offline Root CA

The lifetime of certificates that are issued by a Windows stand-alone CA is set to one year by default. Because these values might not match the organization's requirements, you must set a registry key to adjust this default value.

1. Start a text editor, such as Notepad, and then copy the following to a text file:

   certutil -setreg ca\ValidityPeriodUnits 10
   certutil -setreg ca\ValidityPeriod "Years"
   net stop certsvc & net start certsvc
   

2. Save the text file as %temp%\MyVP.cmd, and then close the text editor.

3. At a command prompt, type %temp%\MyVP.cmd.

For more information about allowing certificate requests to control the certificate validity time, see Control certificate validity time by certificate request in this document.

For more information about how to change the expiration date of certificates that are issued by a Windows 2000 CA, see HOW TO: Change the Expiration Date of Certificates Issued by a Windows 2000 Certification Authority in the Microsoft Knowledge Base.

Republish the CorporateRootCA CRL

After the CRL distribution point extensions are updated on the CA, new CRLs must be published to ensure that all of the clients will be able to gain access to the most current revocation list information. The publishing can be done through the MMC or by using Certutil.exe at a command prompt with the same results.

Republish the CRL by Using the MMC

Use the steps in this section on either a Windows Server 2003 CA or a Windows 2000 CA to republish the CRL. It is important to republish the CRL because adapted configuration parameters such as DSConfigDN are included as extensions in the CRL. Also, CRL properties affect the publication of the CRL.

1. Log onto the CA server with CA Manager permissions.

2. Open the Certification Authority MMC. To do this, click Start, point to All Programs, point to Administrative Tools, and then click Certification Authority.

3. Right-click Revoked Certificates, point to All Tasks, and then click Publish.

   A new base CRL is published. A delta CRL is published only if you have also set the CRL delta publication schedule.

4. When you are prompted to confirm the type of CRL that should be published with this request, click New CRL.

   Because only base CRLs are published by the offline root CA, only the New CRL option is available.

Republish the CRL from a Command Prompt

To publish the CRL, at a command prompt, type certutil -CRL, and then press ENTER. When you do this, the CRL is published to the location that you configured.

Verify the Published CRL

There are two extensions that you should verify after the CRL is published: the publication time and the Published CRL locations extension. When you verify the publication time for the CRL, you are also verifying whether the correct CRL publication is set on the configured schedule. You also need to verify that the DSConfigDN registry value is set correctly and that the DSConfigDN registry value is in the CRL.

Determine the Name of the Most Current CRL

1. At a command prompt, type certutil –dynamicfilelist, and note that the CRL path name that is displayed.

2. At a command prompt, type certutil, and use the CRL path and file name from the previous step as the command-line parameter. For example, you can type the following:

   **certutil %systemroot%\System32\CertSrv\CertEnroll\**CorporateRootCA.crl

   where CorporateRootCA.crl is the file name of the current CRL.

3. Verify that the Effective date extension has the same time as the expected CRL publishing time.

4. Verify that the Published CRL Locations extension does not have a DC=UnavailableConfigDN namespace.

   The Published CRL Locations extension is used when publishing the CRL to Active Directory using Certutil -DSPublish. If the namespace is set not defined, the extension is set to UnavailableConfigDN, when the CRL is created. Certutil -DSPublish will not work unless you specify the appropriate Configuration container on the command line.

   Published CRL Locations
    [1]Locations
     Distribution Point Name:
      Full Name:
       URL=ldap:///CN=CorporateRootCA,CN=concorp-ca-
   00,CN=CDP,CN=Public%20Key%20Services,CN=Services,DC=Unavailable
   ConfigDN?certificateRevocationList?base?objectClass=cRLDistributionPoint
   

If the output has a DC=UnavailableConfigDN, to resolve this behavior, see Map the namespace of Active Directory or Republish the CorporateRootCA CRL, earlier in this document.

A CRL that is correctly configured should have the following output:

Published CRL Locations
 [1]Locations
  Distribution Point Name:
   Full Name:
     URL=ldap:///CN=CorporateRootCA,CN=concorp-ca-00,CN=CDP,CN 
=Public%20Key%20Services,CN=Services,CN=Configuration,DC=concorp, 
DC=contoso,DC=c 
om?certificateRevocationList?base?objectClass=cRLDistributionPoint

Finalize the CA Configuration

If you use the steps in the previous sections, the CA is operational and ready to issue certificates.

If you install a Windows 2000 CA instead of a Windows Server 2003 CA, it is recommended that you also apply the additional configuration steps that are explained in Disable issuer name and issuer serial number, later in this document.