Online Enterprise Issuing CAs (CorporateEnt1CA)
Applies To: Windows Server 2003 with SP1
The online enterprise issuing CA is also referred to as "CorporateEnt1CA" in this document. The purpose of an enterprise CA is to automate certificate enrollment without making compromises in the security and authentication of issued certificates.
Depending on the PKI topology that you implement, this CA might have at least one parent CA or, in a single tier topology, it might be a self-signed CA.
When you set up either a Windows Server 2003 Server enterprise CA or Windows 2000 Server enterprise CA, it is important to note that domain controllers in an Active Directory environment automatically request certificates when an enterprise CA) becomes available in the forest.
The automatic certificate request behavior is different between computers that are running Windows 2000 or Windows Server 2003 domain controllers. Windows 2000 domain controllers immediately start requesting certificates when the enrollment service is available; however, a Windows Server 2003 domain controller requests certificates according to the Autoenrollment configuration in Group Policy settings. Computers that are running Windows Server 2003 domain controllers and computers that are running Windows XP request certificates, according to the configuration of the Group Policy object (GPO). You must enable the request processing manually, by using the appropriate domain Group Policy. Note that domain controllers have their own GPO settings which are separate from the rest of the computers in the domain. To add an automatic request setting for Windows 2000 domain controllers, create a new request object in the following GPO path using the following procedure.
Click Start, click Run, type mmc, and then press ENTER
In the console tree, double-click the domain controller policy that you want to work with, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Public Key Policies, and then click Automatic Certificate Request Settings.
In the details pane, right-click a blank area, point to New, and then click Automatic Certificate Request.
Follow the instructions in the Automatic Certificate Request Setup Wizard.
For more information about configuring auto-enrollment for Windows Server 2003 domain controllers, see Certificate Autoenrollment in Windows XP on the Microsoft Web site.
Enterprise CA Installation Prerequisites
The following items are required to correctly install and configure the online enterprise CA:
The CPS that has all of the parameters that are specific to your organization. For more information, see "Certificate practice statement," earlier in this paper.
The Windows Server 2003, Enterprise Edition media
Appropriate hardware and a floppy disk drive
A floppy disk that is labelled Transfer-EnterpriseCA
The computer must be joined to a domain in the appropriate Active Directory forest
Local administrator, Enterprise Administrator and Root Domain Administrator permissions
File and print sharing is enabled on the CA. This is required to run the certification authority MMC snap-in on the CA.
If you are using a Windows 2000 Active Directory forest, the domain controllers must have Service Pack 3 (SP3) applied for computers that are running Windows 2000. It is also required to upgrade the schema to Windows Server 2003 functionality as previously described. For more information, see "HOW TO: Raise the Domain Functional Level in Windows Server 2003" on the Microsoft Web site.
You should also ensure that the following tasks have been completed:
A server running Windows Server 2003, Enterprise Edition should be set up and available to be used as the enterprise CA.
The server should have the latest service packs available and installed, if appropriate.
The server that is hosting the CA service must be joined to a domain in the Active Directory forest.
It is possible to install a CA as a multiservice server or as a domain controller, but this is not recommended for security reasons. A CA has high security requirements and should be accessed and maintained only as separate resource.
Prepare the Active Directory Environment
You can operate an Windows Server 2003 enterprise CA in a Windows 2000 environment if all domain controllers in the Active Directory are running Windows 2000 SP3 or later. Windows 2000 SP3 domain controllers are the minimum version required to support the schema upgrade for version 2 templates, as described in the previous chapter.
The schema upgrade, which does not cause a full replication in a Windows Server 2003 domain environment, is required to add additional template information, key archival information, cross-certificate objects, and object identifier (also known as OID) objects in the directory.
It is assumed that the schema upgrade is part of the organization change and management process as it can have an overall effect on the production environment.
To upgrade the schema:
Log on to the schema master domain controller as the Schema Administrator.
For more information regarding schema administrator roles, see "HOW TO: Find Servers That Hold Flexible Single Master Operations Roles" in the Microsoft Knowledge Base.
Make the Windows Server 2003, Enterprise Edition, installation media available to the server and, at a command prompt, type the following command, and then press ENTER.
adprep /forestprep
The Adprep.exe file is available from the \i386 directory on the original Windows Server 2003, Enterprise Edition, installation media: After you use this command, you receive an output that contains logging information about the schema-upgrade process. The output ends with the message "Adprep successfully updated the forest-wide information."
To enable the domain to benefit from the Windows Server 2003 schema extensions, you must perform the following procedure on each domain in the forest.
Log on to the domain as Domain Administrator.
At a command prompt, type:
adprep /domainprep
Repeat the previous two steps for each domain in the forest.
Depending on the replication schedule, the time required to apply the schema changes at each domain controller in the forest will vary.
Domain Membership
An enterprise CA can enroll any user or computer in the forest. To enable the CA to issue certificates to users and computers that are members of other domains than the domain where the CA is installed, see the Windows Server 2003 Server Help files or the following articles in the Microsoft Knowledge Base:
Windows 2000 Certification Authority Configuration to Publish Certificates in Active Directory of Trusted Domain on the Microsoft Knowledge Base
Enterprise CA May Not Publish Certificates from Child Domain or Trusted Domain on the Microsoft Knowledge Base
If the organization's Active Directory consists of several domains, you should plan where to put the enterprise CAs. There are three different approaches that you can take. Note that you must evaluate these approaches according to the requirements and the Active Directory design. Enterprise CAs can be:
Installed into each production domain.
Maintained in a separate PKI domain.
Maintained as members of the forest root domain.
When you run enterprise CAs as members of the forest root domain, isolation and logical grouping is ensured but might not be accepted by the forest root administrator group because of security considerations. All approaches are valid, but must be carefully considered for your environment.
Retrieve the Certificate and its CRL from CorporateRootCA and IntermediateCA1
Note
If you implement a single-tier topology, the steps in this section do not apply to your environment.
Both the certificate and CRL for all nodes in the PKI hierarchy are required during certificate validation.
Because all parent CAs of an issuing enterprise CA might be disconnected from the network (as in this sample scenario), you cannot automatically retrieve the CA certificates and the latest CRLs through the network when required. Because of this, you must make the CA certificates and the most current CRL available from all parent CAs before you can set up CorporateEnt1CA.
If the certificate of CorporateRootCA is not available on the Transfer-RootCA floppy disk, perform the steps that are outlined in "Obtain the certificate and its CRL from CorporateRootCA," earlier in this document.
You can retrieve the certificate and CRL for illustration purposes from IntermediateCA1 through Web enrollment support on the CA. Internet Information Services is not required to retrieve the CA certificate and CRL from the root CA as they may copied from the %systemroot%\system32\certsrv\certEnroll\ path on the local system. To retrieve the CA certificate and CRL through the web pages, perform the following steps:
Log on to the IntermediateCA1 computer.
If the CA is accessible from the network, you can use any other computer to download the CA certificate and the CRL; however, these tasks require an interactive local logon because the CA is disconnected form the network.
Click Start, and then click Internet Explorer.
In Address, type https://localhost/certsrv.
Localhost is an alias name for your current server. The Welcome page from IntermediateCA1 Web enrollment support is displayed.
Click Download a CA certificate, certificate chain or CRL
Insert the Transfer-IntermediateCA floppy disk into the disk drive.
Next, download the CA certificate chain.
Click Download CA certificate chain, and then click Save.
In Save As, type a file name (for example, type a:\IntermediateCA1.p7b), and then click Save.
Next, download the latest base CRL:
Click Download latest base CRL and then click Save.
In Save As, type a file name (for example, type a:\IntermediateCA1.crl), and then click Save.
If applicable to your environment, download the latest delta CRL:
If applicable, click Download latest delta CRL, and then click Save.
In Save As, type a file name (for example, type a:\IntermediateCA1+.crl), and then click Save.
Remove the Transfer-IntermediateCA disk from the disk drive.
Distribute a Root CA Certificate with Group Policy
Note
If you implement a single-tier topology, the steps in this section do not apply to your environment, because an enterprise CA that is configured as the root CA automatically publishes certificates to Active Directory.
If a single tier topology is implemented, the steps in this section do not apply because an enterprise CA that is configured as the root CA would publish its certificate automatically into Active Directory.
The validation of certificates requires the availability and explicit trust of the root CA certificate that has issued certificates within the certificate trust path. The root CA certificate provides the trust anchor from which PKI hierarchies are derived.
The easiest way to provide clients with the root CA certificate is through group policies. Trust of root certification authorities should be managed and controlled through Group Policy whenever possible. When a root CA certificate has been added to the Trusted Root certification authority's container that is part of the domain security settings, clients that are member of the domain will receive the root certificate automatically.
Warning
You must not publish subordinate (or intermediate) CA certificates through either the trusted root certification authorities in Group Policy or an enterprise trust. If a subordinate CA certificate is part of this list of certificates that is published with Group Policies, a Windows client will not build a certificate chain correctly.
The security portion of a domain Group Policy setting distributes the list of trusted root certificates to all computers that are Active Directory-aware and members of a domain. Because the root certificate becomes part of the computer policy, all domain-users inherit the root certificate trust from the computers to which they logon.
Note
It is recommended that you make a copy of the default domain policy and use a new policy specific to PKI to administer PKI policy in the domain. Modification of any of the default values requires more in-depth planning regarding certificate trusts and name constraints. Group Policy displays a slightly different view in a Windows 2000 environment. but it provides the same functionality.
To add the root CA certificate of CorporateRootCA through Group Policy to the list of trusted root CA certificates on all computers in the domain, use the following procedure.
Log on as the domain administrator to the domain where you want to deploy the root CA certificate.
Click Start, point to All Programs, point to Administrative Tools, and then click Domain Security Policy
You can also type Dompol.msc at a command prompt and then press ENTER.
In the console tree, double-click Default Domain Policy, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, and then click Public Key Policies.
Right-click Trusted Root Certification Authorities, click Import, and then click Next.
Insert the Transfer-RootCA floppy disk, and then click Browse.
Click Open to select the certificate file.
Click Place all certificates in the following store. After the certificate is placed in the Trusted Root Certification Authorities container, click Next.
After a report displays the options that you have selected in the wizard, click Finish to import the certificate.
You can configure additional PKI trust properties by using the Trusted Root Certification Authorities Properties page. To set these properties, right-click Trusted Root Certification Authorities, and then click Properties.
If you disable the default third-party root CAs and enterprise root CAs option, there may be unintended effects when you try to gain access to applications such as SSL secured Web sites on the Internet, and so on.
When only enterprise root certificates are trusted, only CA certificates that are installed in the following container in the configuration partition of Active Directory or through Group Policy are trusted: Domain Name\Configuration\Services\Public Key Services\Certification Authorities.
See the Sites and Services MMC to verify the certificates. You must make the services node visible to see the Services container.
Import ParentCA Certificates and CRLs into Active Directory
The following section outlines the procedures for publishing the CA certificates and CRLs of offline CAs (CorporateRootCA, IntermediateCA1, and CorporateSub2CA) into Active Directory.
Important
Do not use the information in this section if you are implementing a single-tier CA because a single tier enterprise root CA publishes its root Certificate automatically into Active Directory.
You must import offline CA certificates and their CRLs. Note that this import procedure for the publication of CA certificates must be repeated every time that the offline CA's certificate is renewed.
Also the CRL must be imported according to the CRL publication strategy. Every time that a new CRL is published by the parent CA, you must repeat the publication procedure. To prepare the environment for the enterprise CA installation, you must register the parent CA certificates and CRLs in Active Directory. For information about how to do this, see the following section in this document.
Get CA Sanitized Name and DNS Name
The configuration information that is part of the CRL in Windows Server 2003 is different from the configuration information that was included with versions of the Windows 2000 family. A CRL that was published by a Windows 2000 CA does not contain information about the publication location of the CRL. (For more information, see Verify the published CRL in this document.) However, you must know where you want to save the CRL during the import process into Active Directory.
A Windows Server 2003 CA stores this information in the optional Published CRL Locations attribute of a CRL if the corresponding CRL property was set. When you perform a CRL import procedure on a computer that is running a Windows 2000 operating system, you must manually set the path of the CRL publication location.
To display the CAs computer name and the CAs sanitized name, at a command prompt, type the following and then press ENTER.
certutil –cainfo
You can also use this command on a Windows 2000 CA that should be published to Active Directory. It is important that you note both the sanitized CA short name (DS name) and DNS name for each Windows 2000 CA. A sample output from the command is similar to the following output, where the items in bold are placeholders:
Exit module count: 1
CA name: IntermediateCA1
Sanitized CA short name (DS name): IntermediateCA1
CA type: 4 -- Stand-alone Subordinate CA
ENUM_STANDALONE_SUBCA -- 4
CA cert count: 1
KRA cert count: 0
KRA cert used count: 0
CA cert[0]: 3 -- Valid
CA cert version[0]: 0 -- V0.0
CA cert verify status[0]: 0
CRL[0]: 3 -- Valid
CRL Publish Status[0]: 5
CPF_BASE -- 1
CPF_COMPLETE -- 4
Delta CRL Publish Status[0]: 0xe (14)
CPF_DELTA -- 2
CPF_COMPLETE -- 4
CPF_SHADOW -- 8
DNS Name: connoam-ca-00
Advanced Server: 1
CertUtil: -CAInfo command completed successfully.
If either the CRL path that is specified in the CRL or the path where the CRL is physically published is not the same, an issuer distribution point (IDP) intersection error might appear when the CRL is verified by a client.
ImportCA Certificates and CRLs from CorporateRootCA and CoporateSubxCA
In order to continue the installation procedure, you must import CA certificates and CRLs from parent offline CAs into Active Directory. In general, this procedure is a common operation when the CA environment is set up. CRL publication and distribution with Active Directory is critical for a successful PKI in your organization. Importing root CA certificates into the Active Directory directly is preferred over using Group Policy to distribute root CA certificates, as this method provides for root CA trust throughout the entire forest instead of individual domains.
Both, the CA certificate and CRL are written by the Certutil.exe utility into Active Directory. Note that Certutil.exe replaces the Dsstore.exe utility that is available in the Windows 2000 Resource Kit. For more information, see "HOW TO: Use the Directory Services Store Tool to Add a Non-Windows 2000 Certification Authority (CA) to the PKI in Windows 2000" on the Microsoft Knowledge Base and "The Dsstore Tool May Not Work If the NetBIOS Name and the DNS Domain Name Are Different" on the Microsoft Knowledge Base.
Warning
Do not use the Dsstore.exe utility that is included with the Windows 2000 Resource Kit to import CA certificates and CRLs to a Windows Server 2003 environment.
To import CA certificates and CRLs from parent offline CAs into Active Directory, use the following procedure:
Log on to the CorporateEnt1CA computer as Administrator of the Root-Domain and also a member of the Enterprise Administrators group.
At a command prompt, use the following sample script to import CA certificates and CRLs from CorporateRootCA and CoporateSubxCA to Active Directory. Note that you must change the script so that both the CA certificates and CRLs correspond to your file names and CA names:
: : Root CA certificates : certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA : : Sub CA certificate : certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA : : Root CA CRLs : Since these are .NET CA CRLS that have the publication location as : part of the CRL, the publication location is optional : : |-- publication location ---| : certutil -dspublish -f CorporateRootCA.crl concorp-ca-00 CorporateRootCA : : Sub CA CRLs : certutil -dspublish -f IntermediateCA1.crl connoam-ca-00 IntermediateCA1
Note
The –f parameter is required because the container structure that is required to store the certificates and CRLs and might not exist. The –f parameter is not required if the container structure already exists.
Deploying the root CA certificate with Group Policy or Active Directory is not the only way that you can provide clients with certificates of trusted root CA certificates. You can also deploy root CA certificates by using the following methods:
The Internet Explorer Administration Kit (IEAK)
A CAPICOM script (For more information, see "CAPICOM Reference" on the Microsoft TechNet Web site.)
Set the Appropriate Permissions for Certificate and CRL access
The CA administrator must ensure that any client in the PKI can gain access to both the CRL distribution points and CA certificate.
For HTTP URLs, it is recommended that Internet Information Services (IIS) be set up and configured to allow anonymous access to the URLs that are set as CRL distribution points in issued certificates. When you do this, clients, regardless of their primary authentication mechanism, can retrieve the CRL.
For URLs that point to a CRL object in Active Directory, the Everyone group has read access by default. To allow clients that are not Active Directory members to gain access to CRL objects in Active Directory, you must add the Everyone group with read permissions to the domain objects ACL. A more restrictive method that you can use to configure anonymous access is to replace the Everyone built-in account with the Anonymous built-in account.
For more information about how to add Read access permissions to clients that are outside of the forest, see the following Microsoft Web sites:
"Anonymous Queries" in the Windows 2000 Resource Kit
"How to Use the RestrictAnonymous Registry Value in Windows 2000" in the Microsoft Knowledge Base
Publish CA Certificates and CRLs of CorporateRootCA and CoporateSub1CA
Publishing the CRLs using HTTP requires a Web server, such as IIS. To set up IIS to provide the CRL publishing point using HTTP, use the following procedure:
Log on as a local administrator to the computer that has IIS installed.
Click Start, click All Programs, point to Administrative Tools, and then click Internet Information Services (IIS).
Double-click the IIS server node, and then double-click Web Sites.
The organizational Web site that will host the CRL is displayed.
Right-click your Web site, point to New, click Virtual Directory, and then click Next.
The Virtual Directory Creation Wizard starts.
Type an alias name for your Web site (for example, type PKI), and then click Next.
Choose a path where the certificates and CRL will be stored on the a local storage device, and then click Next.
In this example, the CA certificates and CRLs are stored in C:\PKI.
Select the Read check box, clear all of the other check boxes, and then click Finish.
No other permissions are required.
Copy the CA certificate and CRLs from the Transfer-RootCA floppy disk into the C:\PKI folder. Repeat this step with the CA certificate and CRLs stored on the Transfer-IntermediateCA floppy disk.
Note
Make sure that the file names that are published with HTTP exactly match the CA certificate and CRL distribution point as defined as part of the CA configuration. If the file names do not match, clients will fail to retrieve the CRL with the URL that was specified as the CRL distribution point.
Verify that the Domain Controller Has Published the Certificates and CRL into Active Directory
After you import the list of CA certificates and CRLs into Active Directory, verify that the data is published to the correct location.
Note
In a distributed environment, a delay occurs before any domain controller has received the certificates and CRLs through Active Directory replication. The delay will vary depending on the Active Directory environment configuration.
You can verify that the CA certificates and CRLs are published to the correct location through the Active Directory Sites and Services MMC Snap-in.
Log on to the CorporateEntxCA computer as the administrator of the root domain and as a member of the Enterprise Administrators group.
Open the Active Directory Sites and Services MMC, by doing one of the following
To use the Windows interface, click Start, click All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
To use a command prompt, at a command prompt, type dssite.msc.
Click Active Directory Sites and Services.
On the View menu, click Show Services Node.
Click Services, and then click Public Key Services.
Verify that the AIA container has all parent CA certificates, and then verify that the CRL container has the CRL objects for each CA.
The AIA container has a flat object structure but the CRL distribution point container stores CRLs in a separate container for each CA.
If the AIA or CRL container do not have the proper objects, it may be necessary to manually republish the objects as described above.
To delete certificates or CRLs that are expired, revoked, or no longer required through the Active Directory Sites and Services MMC, click the certificate or CRL and then press DELETE. Keep in mind that clients will need CA certificates to verify end-entity certificates. Even a revoked or expired CA certificate can be required to verify a certificate chain!
Verify That the CA Certificate and CRL Are Imported into Active Directory
To ensure that the correct CRL and AIA information is published to Active Directory, verify the certificate of IntermediateCA1. If clients cannot retrieve a CRL from the CRLs distribution point or do not download a certain CA certificate from Active Directory, the client applications will generate an error when verifying a certificates status.
Note
If the verification procedure in this section does not work, it is important to investigate the cause of the failure. If the publication location in Active Directory is incorrect, correct the location by using the steps in the Publish CA certificates and CRLs of CorporateRootCA and CoporateSub1CA to a Web site section in this article.
To verify that the CA certificate and CRL were imported correctly into Active Directory:
Log on to a computer that is member of the organization's Active Directory. The user account that you use can be a domain user account because any user should have read permissions to both the CA certificate and CRL in Active Directory.
Insert the Transfer-IntermediateCA floppy disk into the floppy drive
At a command prompt, type the following, and then click Retrieve:
certutil.exe -url a:\IntermediateCA1.cer
The certutil.exe –url command works with any X.509V3 certificate. You can also use this command to verify user certificates. You can perform CRL and AIA distribution point verification by using the Certutil.exe utility only on certificate files that are Distinguished Encoding Rules (DER) encoded (*.cer file). If you discover that the CRL distribution point is incorrectly configured, you must correct the issue in the CA configuration to which the CRL belongs. The CRL distribution point is stored as an attribute in every issued certificate. Also, there may be an impact on certificates that are already enrolled if the CRL is not correctly configured.
When you click Retrieve, Windows performs a CRL or AIA download based on the certificate file that has been specified. The certificates name is displayed in Certificate Subject.
Windows lists the certificate's CRL distribution points that are specified in the CRL distribution point extension of the certificate and displays the verification status. The following figure is an example of a successful verification procedure.
.gif "Art Image")
Figure 8: URL Retrieval ToolIf the CRL verification procedure does not work, the CRL distribution point extensions may not be valid, or the locations of the CRLs have permissions set that do not allow the current user to retrieve the object.
In the Retrieve box, click Certs (from AIA), and then click Retrieve.
Since the root CA certificate has no CRL defined in this scenario, you receive a CRL status message saying No CRL. The missing CRL status is expected in this example, since the CRL distribution point was set to Empty in the root CAs CAPolicy.inf file.
Template Upgrade from Windows 2000
When you upgrade from Windows 2000 to a member of the Windows Server 2003 family, you must upgrade both the properties and security settings on existing version 1 (V1) templates.
To perform the upgrade to a Windows Server 2003, Enterprise Edition, CA environment, open the Certificate Templates MMC that is included with Windows Server 2003, Enterprise Edition, so that you can install and upgrade the template objects. It detects that templates are available from a previous Windows 2000 CA installation and automatically upgrades the templates.
The upgrade procedure also changes the permissions that are required for template administration. In Windows 2000, you must be a member of both the Enterprise Admins group and Root Domain Admins group to perform this operation. For more information about certificate templates, see "Implementing and Administering Certificate Templates in Windows Server 2003" on the Microsoft TechNet Web site.
Prepare the CAPolicy.inf File for the Issuing CA
If you apply an application or issuance policy at the level where end entity certificates are issued, you have precise control over policies. If more than one issuing CA exists in the PKI hierarchy, different policies can be applied to each CA to issue different certificate types. Nevertheless, policies can be applied at a parent CA level as well. Typically, in most deployments, policies are applied at an intermediate CA level than at the leaf node CA. When you define policies at a parent CA level, the policy applies to all of the subordinate CAs. This could have an impact on the CA topology design.
For an example of a CAPolicy.inf file with issuer policy, see "Sample CAPolicy.inf file for the IntermediateCA1" later in this paper.
Install the Online Issuing Enterprise CA
If you upgrade a Windows 2000 enterprise CA to a Windows Server 2003 CA, you must log on to the computer with an account that is member of both the root domain administrators group and the enterprise administrators group.
When you perform a clean installation of the first Windows Server 2003, Enterprise Edition CA in a new Windows Server 2003 forest, the installation account requires that you are a member of the Enterprise Admins group and the (root domain) Domain Admins group. After the first CA installation, (root domain) Domain Admins permissions are no longer required.
The installation procedure for an online enterprise CA is different form the installation procedure for the offline parent CAs. Use the following steps to set up CorporateEnt1CA:
Log on to the CorporateEnt1CA computer with Local Admin, Enterprise Admin, and (root domain) Domain Admin permissions.
The installation of an enterprise CA requires that you be able to gain access to the Active Directory configuration container. During the CA installation procedure, the account used to install the CA also becomes a CA administrator account which is a role that can be delegated to other user accounts, as appropriate.
Do one of the following:
To use the Windows interface, click Start, point to Settings, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
To use a command prompt, click Start, click Run, type cmd, press ENTER, type sysocmgr /i:sysoc.inf, and then press ENTER.
Select the Certificate Services check box.
To run Certificate Services, the following software components are required:
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.
After you select the Certificate Services check box, you receive a warning that states that you cannot change the NetBIOS computer name after you install Certificate Services. (Note also that you cannot change the computer's membership to a domain or workgroup.) Click Yes to continue with the installation procedure, and then click Next.
Note
IIS is not a required component on an enterprise CA, but it might be necessary to have IIS available for certificate Web enrollment, depending on the enrollment method that is used for clients. Windows 2000 and Windows XP clients typically request certificates by using distributed COM (DCOM) or auto-enrollment instead of HTTP. For more information, see "Authentication and authorization" in this document.
When you are prompted to choose the type of installation, do one of the following:
If you want this installation to be in a multi-tier PKI topology, click Enterprise subordinate CA.
If you want this installation to be an enterprise CA in a single-tier topology, click Enterprise Root CA. Also, verify that the Use custom settings check box is selected.
In this scenario, the enterprise CA is installed as a subordinate CA. Select Enterprise subordinate CA.
Note that, if the computer that is supposed to be an enterprise CA is a domain member, both the Enterprise Root CA and Enterprise Subordinate CA options may be unavailable. To find out why the options are unavailable, see the following table.
Table 20 Workarounds for Enterprise Root and Subordinate CA Unavailability
Reason Workaround No access to domain controller
The CA cannot gain access to the domain controller through the network. The nltest.exe /dsgetdc command might be helpful to ensure connectivity with your domain controller. To use Nltest.exe, install the support tools that are available on the Windows Server 2003 CD-ROM. For more information about nltest see Active Directory support tools in the Windows Server 2003 online help or on the Microsoft Web site.
Domain controller has not replicated
See "Verify that the domain controller has published the certificates and CRL in Active Directory" earlier in this article.
Configuration container does not exist
See "Verify that the domain controller has published the certificates and CRL in Active Directory" earlier in this article.
After you are done, click Next.
Do one of the following:
If an HSM was not installed, click Microsoft Strong Cryptographic Provider.
If an HSM was installed, you must click the CSP that was installed during the HSM setup procedure.
Select the SHA-1 hash algorithm.
SHA-1 is the most common and interoperable hashing algorithm that is used by programs and operating systems.
In Key Length, select the appropriate setting.
In this example, set a key length of 2048 for CorporateEnt1CA.
Confirm that the Allow this CSP to interact with the desktop and the Use an existing key check boxes are cleared, and then click Next.
If a CA is already installed on this server, the list of existing keys is created from the system certificates that are stored in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Certificates
Set the common name for this CA as specified in the CPS, and then click Next.
Because this CA is an enterprise CA, the distinguished name suffix is predefined to use the namespace of the existing Active Directory's (forest) namespace. It is recommended that this value not be changed.
The key pair is generated by the CSP and written to the local computers key store. If an HSM has been installed and selected, the key is generated in the HSM and stored accordingly. If you do not use an HSM, the key is generated by CryptoAPI and 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 key that is being generated and the CPU performance of the local computer.
Specify the location of the certificate database and the certificate database's log files, and then click Next.
Note
It is a good practice to place both the certificate database and certificate database log on a separate volume from the partition on which Windows is installed for issuing enterprise CAs. This provides increased disk input and output performance and provides sufficient storage space for the database as it becomes larger.
Because this in an online enterprise CA, the shared folder that stores configuration information is optional. The purpose of the shared folder is to serve clients that do not receive the CAs certificates through the Group Policy object (GPO) or that are not able to retrieve the CA certificates from Active Directory or through Web enrollment support. Any client that has access to the shared folder can import the CA certificates into its certificate store. Depending on the shared folders name, a new share will be created on the CA server computer. The default name for the shared folder is \\Localhost\CAConfig. If you do not need to publish the CAs certificate and configuration with a shared directory, do not create a shared folder.
If you are installing a CA in the same location as a previously installed CA, the Preserve existing certificate database option is enabled. Click this option if you want the new CA to use this database and preserve the certificates that are in the database; otherwise, the database will be deleted. Use this option only when you want to restore a CA from backup or for CA migration.
Click Save the request to a file, type a name for the request file, click Next, and then click OK.
For example, you can type a:\CorporateEnt1CA.req.
A subordinate enterprise CA needs to send the certificate request to its parent offline CA. Because the IntermediateCA1 computer is running without a network connection, the request file must be transferred on a floppy disk.
Important
Make sure that the Transfer-CorporateEnt1 floppy disk is available before you proceed to the next step. If Windows cannot access the floppy disk, you receive an error message appears and the CA setup process stops. Before you can reinstall the CA, you must uninstall the Certificate Services Web-Enrollment Support component if you selected it during setup.
The Windows Component Wizard continues the certificate services configuration.
When the Windows Component Wizard completes the certificate services configuration, you may need to provide the installation media to finish the installation procedure.
When the CA certificate has obtained a signed subordinate CA certificate from its parent CA, the installation wizard displays a final message that indicates that the installation procedure is finished. Before you click OK, verify that the Transfer-CorporateEnt1 floppy disk is available to save the request file.
Click OK to continue the installation.
(Optional) If IIS is installed as part of this configuration but ASP pages are not enabled by default, the CA setup procedure asks whether you want to automatically enable the ASP pages. Click Yes to enable ASP pages, because they are required for Web enrollment services.
If you click No because you do not want to enable ASP pages, you can enable ASP pages by using the certutil –vroot command at a later time
Click Finish to complete the installation procedure, and then click Close to close Add or Remove Programs.
Remove the Transfer-CorporateEnt1 floppy disk from the floppy disk drive, and then take the floppy disk to the parent CA computer (IntermediateCA1).
If this installation procedure is for an enterprise root CA, continue to "Configure the enterprise online CA" in this document.
Certificate Request Processing with the Offline Parent CA (IntermediateCA1) Through Web Enrollment Support
The following procedures are provided as an example and not necessarily as a security best practice.
You do not need IIS on a CA unless you need client support for enrollment on Windows clients earlier than Windows 2000 or non-Windows clients.
In a three-tier topology, the enterprise CA certificate request that is stored on the floppy disk must be issued by the IntermediateCA1 computer. In a two-tier topology, the certificate request must be issued by the root CA.
To Request a CA Certificate Through Web Enrollment Support
Log on to the CA computer that will issue the enterprise CA certificate with an account that has certificate enrollment permissions.
On the offline subordinate CA computer, open Internet Explorer.
In Address, type https://localhost/certsrv and then press ENTER.
On the Welcome page, click Request a certificate.
On the Request a Certificate page, click Advanced certificate request.
On the Advanced Certificate Request page, click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file or Submit a renewal request by using a base-64-encoded PKCS #7 file.
Open a text editor, such as Notepad, and open the CorporateEnt1CA request file.
On the Edit menu, click Select All, and then, on the Edit menu, click Copy.
In Internet Explorer, on the Submit a Certificate Request or Renewal Request page, in the Saved Request box, right-click a blank space, click Paste, and then click Submit.
The request is submitted to the CA and remains in the Pending Requests folder. Note the request ID number and the time that are supplied by the Web page. This information is helpful when you use the procedure to approve the request (by request number) and retrieve the certificate (by request time).
Click Home.
Note
A request must be retrieved by the same user account on the same computer from which it was submitted. The Web page uses a browser cookie to identify the pending request. If browser cookies are blocked or if you use a different computer, retrieve the certificate directly from the CA by using the Certification Authority MMC snap-in. For more information, see "Export the offline intermediate certificate at the root CA" in this document.
To Issue the Pending Request With the Certification Authority MMC
Open the Certification Authority MMC.
In the console pane, double-click Certification Authority (LocationOfCA), double-click the CA, and then click Pending Requests.
In the details pane, right-click the request, and then click Issue.
To Issue the Pending Request Through Web Enrollment Support
Open Internet Explorer.
In Address, type https://localhost/certsrv and then press ENTER.
On the Welcome page, click View the status of a pending certificate request.
On the View the Status of a Pending Certificate Request page, click the request you want to issue.
If there is more than one certificate available, click the certificate that corresponds to the time that you sent the request to the CA.
On the next page, choose a format for the newly issued certificate.
In a homogenous Windows environment, it is recommended that you use the DER-encoded format.
Unless the root CA has been previously installed on the computer account where the enterprise CA is installed (Group Policy, and so on), the root CA certificate must be trusted before the enterprise subordinate CA can start.
Click Download certificate chain, save the output to a .p7b file, and then save the file on a floppy disk.
For example, you can save the file as CorporateEntCA.p7b.
Note
There is no sensitive data on the floppy disk. A CA certificate is public information, however, the associated CA private key has been generated in the CA (or HSM). The private key does not leave the computer on which the certificate request was created.
Verify the EnterpriseSub1CA Certificate
To ensure that the certificate that you issued for the CorporateEnt1CA computer has the correct certificate properties, you should verify the certificate. Open the certificate and examine its certificate properties. To view the certificate, double-click the certificate file in Windows Explorer or use the Certificate Manager MMC. Make sure that the validity time, the key length, and certificate policies are shown correctly.
Install the Certificate at the CorporateEnt1CA Computer
The installation procedure for the enterprise CA certificate is very similar to the installation procedure for the IntermediateCA1 computer.
Insert the floppy disk that has the certificate file for the parent CA certificates into the floppy disk drive, and then, at a command prompt, type the following command, and then press ENTER:
certutil.exe –installcert CACertFile**.p7b**
For more information, see "Install the certificate at IntermediateCA1 at a command prompt," later in this paper.
Verify the CorporateEnt1CA Trust Chain
Only a valid trust chain ensures that the CA will operate as expected. If the trust chain is not correct or if the issuing CA cannot build the chain and check revocation status of parent certificates, the issuing CA will report and error when attempting to start. If the CA certificate verification fails, the following error message appears: The revocation function was unable to check revocation because the revocation server was offline (0x80092013).
To verify the trust chain of the CorporateEnt1CA computer in advance, at a command prompt, type run certutil –verify CertificateName**.crt**, and then press ENTER.
It is also recommended that you validate the CA certificate's CRL distribution points. To do this, at a command prompt, type the following command, and then press ENTER:
certutil –URL certificate-name.crt
The output of the script looks similar to the following figure:
.gif "Art Image")
Figure 9: Validated CRL Distribution Points
To view the CRL, in the Url column, double-click the CRL URL.
Note
You can verify a CRL or AIA according to the URL that is specified in a certificate. If a certificate and a URL are both provided, the CRLs and AIAs for all URLs that are specified in the certificate are requested and, additionally, the information from the location that is specified in URL to download is received.
For troubleshooting purposes, you may also be required to download the CRL to the local computer to examine the CRL. This procedure is easy for CRLs that you can gain access to by using HTTP, but this procedure is more difficult for CRLs that do have only an LDAP CRL distribution point.
You can download a binary copy of a CRL from an LDAP CRL distribution point by using the Certutil.exe command. To do this, type the following at a command prompt: Note that you should replace the items that are in italic text with your CRL destination and that you should verify that the correct search filter is added after the question mark.
certutil –store –split ldap:///CN=CorporateRootCA,CN=RootCA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?CertificateRevocationList?base?objectClass=cRLDistributionPoint
After you run the command, a new CRL file is available in the directory you used when you ran the Certutil.exe command. The file is named Blob0_0.crl. You can open the .crl file through Windows Explorer and display it as you would any other .crl file.
PKI Health Tool
You can also use the PKI Health tool (Pkiview.msc) to verify the CRL and AIA location. This tool is available from the Microsoft Windows Deployment and Resource Kits Web site.
The PKI Health tool is of value to CA administrators who maintain the enterprise. The tool enumerates all certification authorities (CAs) that are associated with the current forest, and then the tool displays status properties that are associated with those CAs.
Configure the Enterprise Online CA
The CorporateEnt1CA computer configuration is similar to the parent subordinate CA configuration, and you can quickly create this configuration with a batch script. The difference between the parent CA configuration and the CorporateEnt1CA computer configuration is the validity period for issued certificates—they are controlled by templates in the enterprise CA instead of by the registry. Further, delta CRLs are enabled for the enterprise CA. Delta CRL publishing is enabled by default with Windows 2003 Server. To configure the enterprise CA:
Open Notepad.
In this paper, go to Sample script to configure the EnterpriseSubCA and copy the script to the clipboard.
In Notepad, paste the script into a new file.
Save the file as %temp%\entcacfg.cmd, and then close Notepad.
At a command prompt, type %temp%\entcacfg.cmd and press ENTER.
Important
If you study the script that configures the enterprise CA, you may notice that the LDAP CRL publication property is different than the properties for the offline CAs. This behavior occurs because an online CA has the capability to publish its CA certificate and the CRL automatically to Active Directory. Therefore, it is recommended that you allow the CA to update the information that is stored at the CRL and AIA distribution point. An offline CA cannot use this setting, because it cannot reach a domain controller by using the network. Because of this, no publication is configured for either CRL or AIA CRL distribution points that are configured with offline CAs.
Verify the EnterpriseSubCA Configuration
The next sections help you ensure that the CA is correctly configured and is ready for production operations. It is recommended that you apply the verification steps that are described in the previous sections in this document:
Verify the root CA configuration
Verify the CorporateRootCA CRL and AIA configuration
Verify the published CRL
An enterprise CA automatically publishes the CA certificate and CRL into Active Directory. Because of this, you should also verify the CRL's availability in Active Directory. It is recommended that you use the certutil –URL command or the PKI Health tool that is described in the previous section.
Note
The output samples that are mentioned in the previous sections in this document are not the same as the IntermediateCA1 configuration. Verify the appropriate parameters according to the EnterpriseSubxCA configuration.