Historical Content Alert

This is a historical content for Windows 2000 product and is presented for informative purposes only. All content on this page is copyrighted and owned by Microsoft.

Installing and configuring a certification authority

Planning the installation of a certification authority

Before installing Certification Services, you should plan the deployment of certification authorities (CAs) and public key infrastructure in your organization.

For more information about deploying a PKI, see Checklists, Resources: Public key infrastructure, Windows 2000 Resource Kits, and Microsoft Product Support Services.

Ways to install Certificate Services to create a certification authority

If you are installing Certificate Services on a Windows 2000 Server, there are a number of situations in which you may want to set up a CA. (The most typical is listed first here.)

After Windows 2000 Server base setup has completed:

To install Certificate Services on a server that already has Windows 2000 Server installed, double-click Add/Remove Programs in Control Panel. After you select Certificate Services for installation, the Certificate Services Installation wizard guides you through the installation process.

For the procedures to set up a certification authority (CA) on a server that already has Windows 2000 installed, see Set up a certification authority.
As part of Windows 2000 Server base setup:

Although Certificate Services is a Windows 2000 service and is included with Windows 2000 Server, it is not installed as part of the initial Windows 2000 Server installation process by default. (You would not want every file server to be a CA.)

To install Certificate Services during the initial base installation of Windows 2000 Server, you must select it from the optional components list that is displayed during setup. Certificate Services will not actually be installed until you log on to the server after the Windows 2000 setup has completed. Then, a message will prompt you to complete the setup of the CA.
Upgrading from Certificate Server 1.0:

See Upgrading Certificate Server 1.0.
As part of the unattended installation of a Windows 2000 Server:

Certificate Services can be installed as part of an unattended installation of a Windows 2000 server. For information about unattended installation of Windows 2000, see Planning for unattended setup.

Setup options and information

When you set up Certificate Services, you will be prompted for the following information:

Certification authority type selection

During the Certificate Services installation, you can choose to set up any of the following types of certification authority (CA):

Certification Authority (CA) Type	Description
Enterprise root CA	An enterprise root CA is a top-level CA in a certification hierarchy. An enterprise root CA requires Active Directory. It self-signs its own CA certificate and publishes that certificate to the Trusted Root Certification Authorities store of all Windows 2000 servers and workstations in the domain. For more information, see Enterprise certification authorities
Enterprise subordinate CA	An enterprise subordinate CA must obtain its CA certificate from another CA. An enterprise subordinate CA requires Active Directory. You would use enterprise subordinate CAs when you want to take advantage of Active Directory, certificate templates, and smart card logon to Windows 2000 computers
Stand-alone root CA	A stand-alone root CA is a top-level CA in a certification hierarchy. The stand-alone root CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists. Since a stand-alone root CA doesn't require Active Directory, it can easily be disconnected from the network and placed in a secure area, which is useful when deciding to create a secure offline root CA. For more information, see Stand-alone certification authorities
Stand-alone subordinate CA	A stand-alone subordinate CA must obtain its CA certificate from another CA. The stand-alone subordinate CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists. It must obtain its CA certificate from another CA.

Advanced Options: cryptographic service providers, key lengths, hash algorithms

If you enable advanced options when you choose the type of CA to install, you can select the cryptographic service provider (CSP) to use. The CSP generates the public key and private key pair and performs cryptographic operations on behalf of the CA.

In advanced options, you also can set the key length for the public key cryptographic keys that the CA uses to sign certificates. In general, the longer the key length, the more secure it is. Note that a longer key will take longer time to generate during setup.

In advanced options, you can also choose the message hash algorithm used by the CA, as well as specifying the use of existing cryptographic keys instead of generating new ones.

Certification authority identifying information

The following are some guidelines for completing the CA identifying information in Certificate Services setup:

Field	Description
CA Name	The name you want to give to the CA. You can enter a string using almost any character. The name of the CA will also be the common name of the CA's distinguished name in Active Directory. When special characters exist in the CA name, a sanitized CA name is used for operations that are unable to use the unmodified CA name. A CA's sanitized name is the name of the CA with all special characters encoded in a form that will allow them to be used for file names, CryptoAPI (CAPI) key container names, and Active Directory object names. Special characters are those characters that cannot be used in one or more of these names; the list includes all characters which are not ASCII characters and many ASCII punctuation characters. Further, Active Directory object names are limited to 64 characters by the LDAP standard. To accommodate this limit, Active Directory object names are constructed by truncating the sanitized name and appending a hash computed over the truncated part of the sanitized name. Run certutil.exe at a command line prompt without arguments to see the sanitized name for all of the published CAs. Run certutil.exe -v -ds to see all of the CA-related Active Directory names. The first column is a truncated CA name with the hash appended (the actual Active Directory objects's container name, with special characters reverted back to their original form). A second column is displayed only if the truncated, sanitized name does not match the truncated CA name, and it is the actual Active Directory object's container name.
Organization	The legal name of your organization that is registered with the appropriate state, country/region, or city authority.
Organizational Unit	Can be used to differentiate between different divisions within an organization, for example, Internet Security Unit or Human Resources. If your business has a different name from its parent organization, you can use that name here.
Locality	The city that the organization resides in.
State or Province	The physical location of the organization.
Country	A two-character country/region code, as required by the X.500 Naming Scheme standard. For example, the country/region code for the United States is US, and the code for Canada is CA.

Database and Configuration Storage

Certificate Services uses local storage for its database, configuration data, backup data and logging data. You can specify locations for the database and log during CA setup. By default, the certificates issued by a CA are stored in:

\Systemroot\system32\certlog

You also have the option of specifying a shared folder when setting up a CA. The shared folder acts as a location where computer users can find information about certification authorities. This option is only useful if you are installing a stand-alone CA and do not have Active Directory.

If the host computer for Certificate Services is a member of a domain, information about the CA is automatically published to the Active Directory. However, the Active Directory does not act as the database for Certificate Services. This function remains with the local computer.

(Optional) Creating an issuer policy statement for the CA

When you set up a CA, you can add a CA policy statement to the CA certificate that is created during setup or a CA certificate renewal, in the form of text or a pointer to a Web site. The CA policy statement gives legal and other pertinent information about the CA and its issuing policies, limitations of liability, and so on. An end user will see this CA policy statement when they view the CA certificate and click Issuer Statement.

Here are the steps you need to follow to attach a policy statement to a CA's certificate:

The policy statement file must be installed on the Windows 2000 server before you set up Certificate Services. This file, named CAPolicy.inf, must be placed in the systemroot directory. URLs in CAPolicy.inf should use the replaceable parameter syntax that also appears in the policy module configuration screen. If you don't use the replaceable parameter syntax, then CDP and AIA extensions in renewed CA root certificates may point to the same location that was specified in the previous CA root certificate. See Specify certificate revocation list distribution points in issued certificates to see the replaceable parameter syntax.
The first two lines of CAPolicy.inf must be:

[Version]
Signature="$Windows NT$"
The next two lines of the file list the name of the policies for this CA. Multiple policies can be listed in Policies= if they are separated by commas. The name LegalPolicy is used here as an example, but the name can be whatever the CA administrator chooses when creating CAPolicy.inf:

[CAPolicy]
Policies=LegalPolicy
For each policy, you need to provide a user-defined object identifier and either the text you want displayed as the policy statement or a URL pointer to the policy statement. (The URL can be in the form of an HTTP, FTP, file, or LDAP address.) Continuing on with the example, if you are going to have text in the policy statement, the next three lines of CAPolicy.inf will read:

[Legal Policy]
OID=1.1.1.1.1.1.1.1.1
Notice="Legal policy statement text"

If you are going use a URL to host the CA policy statement, the next three lines would instead read:

[Legal Policy]
OID=1.1.1.1.1.1.1.1.1
URL="http:://CompanyWebSite/CAPolicy/default.asp"

(Please note that the "OID=" entry used in this example is arbitrary and is shown only for illustrative purposes.)

Additional notes:
- Multiple URLs are supported
- Multiple notices are supported
- Mixed notices and URLs are supported
- URLs with spaces or text with spaces must be surrounded by quotes
An example of multiple notices and URLs in a policy section might be:

[Legal Policy]
OID=1.1.1.1.1.1.1.1.1
URL = "http://http.site.com/somewhere/default.asp"
URL = "ftp://ftp.site.com/somewhere else/default.asp"
Notice = "Legal policy statement text."
URL = "ldap://ldap.site.com/somewhere else again/default.asp"
You can specify CRL Distribution Points (CDPs) in CAPolicy.inf. Note that any CDP in CAPolicy.inf will take precedence for certificate verifiers over the CDP's specified in the CA policy module. If you want to specify the CDP using CAPolicy.inf, a sample of the syntax is:

[CRLDistributionPoint]
URL="http:://CompanyWebSite/Public/myCA.crl"

Some additional notes about the CRL section:
- Multiple URLs are supported.
- HTTP, file, FTP, and LDAP URLs are supported.
- This section can be used during CA setup or CA certificate renewal.
- This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA CRL distribution point extensions are determined by the CA which issued the subordinate CA's certificate.
- URLs with spaces must be surrounded by quotes.
- If no URLs are specified(in other words, if the [CRLDistributionPoint] section is empty), the default CRL Distribution point extension will be suppressed.
You can specify the authority information access points in CAPolicy.inf. The syntax is:

[AuthorityInformationAccess]
URL="http:://CompanyWebSite/Public/myCA.crl"

Some additional notes about the authority information access section:
- Multiple URLs are supported.
- HTTP, file, FTP, and LDAP URLs are supported.
- This section can be used during CA setup or CA certificate renewal.
- This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA authority information access extensions are determined by the CA which issued the subordinate CA's certificate.
- If no URLs are specified (in other words, if the [AuthorityInformationAccess] section is empty), the default authority information access extension will be suppressed.
Another optional section of CApolicy.inf is [EnhancedKeyUsage], which is used to specify EnhancedKeyUsage extension OIDs.
- Multiple OIDs are supported.
- This section can be used during CA setup or CA certificate renewal.
- This section is only used if you are setting up a root CA or renewing a root CA certificate. The EnhancedKeyUsage extension for a subordinate CA is determined by the CA which issued the subordinate CA's certificate.
An example of this section is:

[EnhancedKeyUsage]
OID=1.2.3.4.5
OID=1.2.3.4.6
Another optional section of CApolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and renewal validity period units for a CA that is being renewed.

An example would be:

[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=8
RenewalValidityPeriodUnits=Years
- RenewalKeyLength sets key size for renewal only. This is only used when CA renewal is generating new keys.
- RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of new root CA certificate when renewing the old CA certificate.
- [certsrv_server] is only used when renewing a root CA certificate.
If you upgrade a Windows NT 4.0 server that is running Certificate Server 1.0 to Windows 2000 Server, Certificate Server 1.0 will automatically be upgraded to the new version of Certificate Services. If the CA being upgraded is using a policy module other than the default policy module for Certificate Server 1.0, it will continue using its old policy module. Certificate Services will refer to it as the "Legacy" policy module. If the CA being upgraded uses the default policy module provided with Certificate Server 1.0, the upgraded CA will use the Certificate Services stand-alone policy.

The Certificate Server 1.0 database does not get upgraded automatically when you upgrade to Windows 2000 Server. The upgraded CA will have an empty database and an empty certificate revocation list (CRL). You must perform the following steps to import the old database information into the new database:
1. Stop Certificate Services
2. At the command prompt, run certutil -ConvertMDB
3. Start Certificate Services
4. Publish a new CRL
If you are not upgrading a Certificate Server 1.0 CA and, instead, are installing a separate Windows 2000 CA that will replace the old CA, you can find information about installing the policy module developed for Certificate Server 1.0 on a Windows 2000 CA in Configuring the policy and exit modules. This assumes that you want to use the older policy module instead of the default policy module that is provided with Certificate Services.