Udostępnij za pośrednictwem

Installing and configuring a certification authority

  • Artykuł

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Installing and configuring a certification authority

This section will give you additional information you need to install and configure a certification authority (CA).

Planning the installation of a certification authority

Before installing Certificate Services, you should plan the deployment of certification authorities (CAs) and Deploying a Public Key Infrastructure in your organization.

For more information about deploying a PKI, see Certificates Resources in public key infrastructure and Microsoft Windows Deployment and Resource Kits.

Ways to install Certificate Services to create a certification authority

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

  • After base setup has completed:

    To install Certificate Services on a server that already has Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition installed, open Add or Remove Programs in Control Panel. (To open a Control Panel item, click Start, click Control Panel, and then double-click the appropriate icon.) 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) as part of the base setup, see Set Up a Certification Authority.

  • As part of Windows Server 2003 family base setup:

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

    To install Certificate Services during the initial base installation of the Windows Server 2003 family, 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 setup has completed. Then, a message will prompt you to complete the setup of the CA.

    This feature is not included on computers running the Microsoft® Windows Server® 2003, Web Edition, operating system. For more information, see Overview of Windows Server 2003, Web Edition.

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 Type Description

Enterprise root CA

An enterprise root CA is a top-level CA in a certification hierarchy. An enterprise root CA requires the Active Directory directory service. It self-signs its own CA certificate and uses Group Policy to publish that certificate to the Trusted Root Certification Authorities store of all servers and workstations in the domain. Normally, an enterprise root CA does not directly provide resources for user and computer certificates, but is the foundation for a certificate hierarchy. 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 use enterprise subordinate CAs when you want to take advantage of Active Directory, certificate templates, and smart card logon to Windows XP and computers running Windows Server 2003 family operating systems

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 for publishing certificates and certificate revocation lists. Since a stand-alone root CA does not require Active Directory, it can easily be disconnected from the network and placed in a secure area, which is useful when creating 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 for publishing certificates and certificate revocation lists. It must obtain its CA certificate from another CA.

Note

  • Certificate Services should not be installed on any node in a server cluster as this configuration may not allow Certificate Services to run properly and is therefore not supported.

Installing Web enrollment support

You may want to install a certification authority infrastructure within a defined security boundary and only allow specific computers to communicate with your certification authority. This means clients cannot connect directly to a CA to request and retrieve certificates. Or you may want to set up a CA that supplies certificates to Internet-based subjects. You may want to place a layer of insulation between these clients and the CA. Web enrollment allows these scenarios to be implemented easily.

Web enrollment is the component of a Microsoft CA that allows clients to submit certificate issuance and retrieval requests based on Web pages. It is installed when you install a Microsoft CA. It can also be installed on a non-CA computer to provide a Web front-end to your CA infrastructure on the back-end. In this configuration, clients make requests with the Web pages and only the computer that has Web enrollment installed needs to communicate with your CA.

For more information on installing Web enrollment, see Set up certification authority Web enrollment support.

Public and private key pair: cryptographic service providers, key lengths, hash algorithms

If you select the Use custom settings to generate the key pair and CA certificate check box 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.

You 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 more time to generate during setup and longer to transmit on the network when building certificate trust lists.

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.

Note

  • A CA may be installed using a smart card CSP. Once a CA is installed using a smart card CSP, the smart card must be available and inserted with the personal identification number (PIN) in order for the CA to start and perform its operations. This is a higher security option for CA operations than other options, but a disadvantage of using smart card CSPs is that CA performance may be slower and key length may be smaller.

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 any Unicode 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 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 Lightweight Directory Access Protocol (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. The distinguished name suffix field is automatically filled with the distinguished name of the Active Directory domain. If you edit this distinguished name, you must conform with the LDAP standard.

Type certutil.exe at a command prompt without arguments to see the sanitized name for all of the published CAs. Type 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 object'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.

Distinguished name suffix

The X.500 distinguished name suffix that will be appended to the CA name.

Validity period

The length of time the CA's certificate should be valid. The CA will obtain a certificate that is valid for this length of time and use that certificate's private key for signing issued certificates and certificate revocation lists.

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

For best performance, the database and log files should be kept on separate physical disk drives, preferably on separate disk controllers. This will maximize disk throughput and allow the CA to perform better.

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 use 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.

Note

  • It is considered unsafe to install Certificate Services on an FAT file system because FAT does not support domain-based security. Always install Certificate Services on a NTFS file system to take advantage of support for a variety of features including Active Directory, which is needed for domains, user accounts, and other important security features.

(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 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 Extensions tab. 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. To see the syntax for replaceable parameters, see Specify certificate revocation list distribution points in issued certificates.

  • 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 (also known as an OID) 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:

    [LegalPolicy]

    **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:

    [LegalPolicy]

    **OID=**1.1.1.1.1.1.1.1.1

    URL="https://CompanyWebSite/CAPolicy/default.asp"

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

    In addition:

    • 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:

    [LegalPolicy]

    **OID=**1.1.1.1.1.1.1.1.1

    **URL = "https://**http.microsoft.com/somewhere/default.asp "

    URL = "ftp://ftp.microsoft.com/somewhere else/default.asp"

    Notice = "Legal policy statement text."

  • 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="https://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="https://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 Enhanced Key Usage extension object identifiers (also known as OIDs).

    • Multiple object identifiers 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 Enhanced Key Usage 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 the certificate revocation list (CRL) validity period for a CA that is being renewed or installed.

    An example would be:

    [certsrv_server]

    **RenewalKeyLength=**2048

    **RenewalValidityPeriod=**Years

    **RenewalValidityPeriodUnits=**5

    **CRLPeriod=**Days

    **CRLPeriodUnits=**2

    **CRLDeltaPeriod=**Hours

    **CRLDeltaPeriodUnits=**4

    • 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.

    • CRLPeriod and CRLPeriodUnits establish the validity period for the full CRL, while CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period for the delta CRL.

    • RenewalKeyLength, RenewalValidityPeriod and RenewalValidityPeriodUnits are only processed when the CA is being renewed.

    • LoadDefaultTemplates is not processed when the CA is a subordinate CA.