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.
.gif "Art Image")
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.
Note
The stand-alone offline root CA is also referred to as "CorporateRootCA" in this document.
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.
Warning
Configuring the CAPolicy.inf file is a very important step that you must finish before you set up a Windows Server 2003 root CA. If you do not use the CAPolicy.inf file for the offline root CA setup procedure, the CRL and AIA distribution points that become part of issued certificates are set to distribution points on the local computer. Because an offline CA is never accessible from the network, clients cannot resolve the CRL or AIA distribution point. To prevent this issue, you must explicitly add both the CRLDistributionPoint and AuthorityInformationAccess parameters to the CAPolicy.inf file. As noted in the "CRL Best Practices" section in this document, both the CRL and AIA CRL distribution point of a root CA need to be defined as empty.
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.
Note
After you use CAPolicy.inf on a CA, do not remove it from the computer because configuration parameters, like renewal key length, should be consistent during the life cycle of the CA.
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:
Log on to the CorporateRootCA computer as an administrator.
Open a text editor, such as Notepad.
Copy the sample text file that is in the "Sample CAPolicy.inf file for the CorporateRootCA" section of this document as a template.
Paste the text into the file and then save it to %Systemroot%\CAPolicy.inf.
Installing the Offline Root CA Software Components
Important
Perform any renaming operations before the CA services become part of the configuration. You cannot change the NetBIOS computer name or the computer's membership in a domain or workgroup after certificate services is installed, because the name is part of the Certification Authority configuration information.
To install the offline root CA software components, use the following procedure.
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.
Use one of the following procedures to open Add/Remove Windows Components:
To use a command prompt:
Click Start, click Run, type cmd, and then click OK.
At the command prompt, type sysocmgr /i:sysoc.inf and then press ENTER.
To use Control Panel:
Click Start, point to Settings, and then click Control Panel.
Click Add or Remove Programs.
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
In the Windows Components Wizard, select the Certificate Services check box, and then click Next.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
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.
(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.
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.
.gif "Art Image")
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.
On the local root CA computer, at a command prompt, type:
certutil –ca.cert corporateRootCA.cer
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
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:
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 -- 3At 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
Warning
Incorrectly editing the registry may severely damage your computer. Before making changes to the registry, you should back up any valued data on the computer.
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.
Important
After you use this command to change the registry key, a new CRL and any new CA certificates that are issued must be republished. Only new certificates that are issued after you use the previous command will have this information available. It is important to note that you must reissue and republish any subordinate CA certificate if it was issued before you changed the registry key.
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:
Log on to the computer running certificate services with an account that has Certification Authority Management permissions.
Click Start, point to All Programs, point to Administrative Tools, and then click Certification Authority.
In the console tree, right-click the name of the CA that you want to work with, and then click Properties.
Click the Extensions tab.
Configure CorporateRootCA Distribution Points for the CRL
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.
On the Extensions tab, in Select extension, select CRL Distribution Point (CDP).
In Specify location from which users can obtain a certificate revocation list (CRL), click the default LDAP location, click Remove, and then click Yes.
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.
.gif "Art Image")
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
| Access protocol | CRL distribution point |
|---|---|
[local] |
C:\WINDOWS\system32\CertSrv\CertEnroll\%3%8%9.crl |
HTTP |
https://www.contoso.com/pki/%3%8%9.crl |
LDAP |
Ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 |
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.
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.
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.
In Specify locations from which users can obtain a certificate revocation list (CRL), click one of the paths.
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.
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
Warning
In the procedure below, do not remove the local AIA path location. The local path will not be contained in the AIA extension of issued certificates.
In CorporateRootCAProperties, on the Extensions tab, select Authority Information Access (AIA).
In Specify locations from which users can obtain the certificate for this CA, click the default LDAP location, click Remove, and then click Yes.
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.
Click Add, and in Location, type one of the AIA distribution points from the following table, and then click OK.
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
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
Repeat the previous step for each location, except for the file locations.
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.
Important
Because percent character (%) variables are handled differently than the configuration UI in batch files and at a command prompt, you must use the %% notation if you want to run the example script in this section as a batch file. If Certutil is called from a command prompt, replace %% with a single %.
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.
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"Save the text file as %temp%\MyCRLCDP.cmd.
Close the text editor.
At a command prompt, type %temp%\MyCRLCDP.cmd to execute the commands from the text file.
At a command prompt, type net stop certsvc to stop the certificate server, because you must restart the computer to apply the change.
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:
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
Verify that the output is similar to the values you have configured in the previous section.
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
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.
Click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
This opens the Certification Authority MMC Snap-in.
In the console tree, right-click Revoked Certificates, and then click Properties.
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.
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.
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 certsvcSave the text file as %temp%\MyCRLPeriod.cmd, and then close the text editor.
At a command prompt, type %temp%\ MyCRLPeriod.cmd, and then press ENTER.
Instead, use these steps on a Windows Server 2003 CA.
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 certsvcSave the text file as %temp%\MyCRLPeriod.cmd, and then close the text editor.
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.
Note
The validity time of the root CA certificate is controlled at the setup and renewal of the CA certificate through the value that is specified in the CAPolicy.inf file. The registry value that is described in this section does not affect the validity time of the root certificate.
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 certsvcSave the text file as %temp%\MyVP.cmd, and then close the text editor.
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.
Log onto the CA server with CA Manager permissions.
Open the Certification Authority MMC. To do this, click Start, point to All Programs, point to Administrative Tools, and then click Certification Authority.
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.
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
At a command prompt, type certutil –dynamicfilelist, and note that the CRL path name that is displayed.
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.
Verify that the Effective date extension has the same time as the expected CRL publishing time.
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
Warning
Verify that the italicized text is the same as the value that is specified in DSConfigDN registry values. You should also verify that objectClass component of the LDAP path is correctly defined.
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.