Certification Authority Maintenance

Applies To: Windows Server 2003 with SP1

CA maintenance and monitoring is an ongoing task after you set up the CA environment.

Some of the most important procedures for CA maintenance are:

• Correct configuration of the CAs

• CRL publication of offline CAs

• CRLs that are not manually published

• Renewal of CA certificates assigned to CA operations

• Backup and recovery

You can maintain the CA that is connected to the network locally or you can maintain the CA that is connected to the network through a remote connection; however, CA maintenance and administration tools are designed to work best for local operations because the CA administration is a sensitive operation and should be kept as secure as possible.

If you want to use the Certificate Services MMC for remote administration, for the appropriate steps to make the CA remotely accessible, see "Users Allowed to Manage the CA Cannot Access It Remotely" in the Microsoft Knowledge Base.

For more information about CA operations and custom configuration, refer to the Windows Server 2003 PKI Operations Guide on the Microsoft Web site.

Best Practices for CRL Publication

The following section provides information and best practices for managing and publishing certificate revocation lists.

CRL Partitioning

Administrators may renew an issuing CA with a new key to partition the CRL. When a new key and certificate are generated, the CA uses the new key as well as any unexpired previous keys that correspond to previous certificates when generating revocation information. Therefore, a CA may be using multiple keys at the same time and therefore publishes multiple CRLs that correspond to those keys. You can see multiple valid certificates that are assigned to the CA in the Certification Authority MMC if you click the General tab of the CA properties.

You can also determine the renewal status of the CA if you examine the CA certificate. The CA version extension identifies how many times a CA has been renewed and how many times it has been renewed with a new key. The following figure displays a CA certificate that has been renewed three times. Note that a new key was issued with each renewal, which is why CA Version is 3.3.

Figure 10: Renewed CA Certificate

After a CA is renewed with a new key, only the new key is used when signing new certificates. The unexpired previous keys continue to be used to sign CRLs for certificates that were signed with the previous keys. Therefore, a CA may publish multiple CRLs at the same time, each using a different key. This method of CA renewal may be an ideal method for CRL size control and effective CRL partitioning with the CA.

Automatic RootCA Cross-Certificate Generation

On computers that are running a member of the Windows Server 2003 family, Microsoft root CAs can automatically issue and publish cross certificates for a root CA that has been renewed. For example, when a Windows Server 2003 root CA is renewed with a new key, the root CA cross-certifies the renewed root CA certificate and it is considered a qualified subordinate to the earlier root CA certificate. This functionality is important if you have an operational root CA that is trusted by other organizations clients, bridge CAs, or if it is cross-certified by other organizations.

To force the root CA to use the CrossCA certificate template, at a command prompt, type the following command, and then press ENTER. If you do not use this command without this setting configured, the CA does not use the CrossCA certificate template (even if it is available). Instead, it generates a certificate using predefined extensions in the registry:

certutil -setreg ca\CRLFlags +CRLF_USE_CROSS_CERT_TEMPLATE

To disable automatic cross CA certificate generation, at a command prompt, type the following command, and then press ENTER:

certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

To force the root CA to use the CAExchange certificate template when generating CA encryption certificates on demand, use the following command. Without this flag, the CA uses the CAExchange certificate template, when available, and generates a certificate without the template by using pre-defined extensions.

certutil -setreg ca\CRLFlags +CRLF_USE_XCHG_CERT_TEMPLATE

Certification Authority Backup and Recovery

The CA stores information about certificates in its database and the log files that are bound to the database. The CA has to be able to gain access to its certificates and keys that are stored in the local computer's certificate store or on a hardware device. CA configuration information is stored in the registry.

You can back up the database and the log files only by using the certutil –backup command. You can individually back up the CA certificate and the keys by using the certutil –backupkey command. You can archive the database by using the certutil –backupdb command. These backup procedures are appropriate for a restore operation that repairs a damaged CA, assuming that the CA is correctly configured. However, neither of these commands will back up any of the CA configuration or role separation information in the registry. To back up the CA, including its configuration, use the ntbackup backup systemstate command.

Note

Backing up a CA includes the private key that is owned by the CA. The private key is the most sensitive CA information option. It becomes part of your backup data if you run certutil -backupkey or if you perform a system state backup. Handle the backup data with caution at all times. Store it securely if the private CA key is part of your backup. The organization's certificate policy and security policy must cover the handling of backup media.

A backup procedure may not work as expected, so it is recommended that regularly scheduled tests of restore operations be performed. For more information about CA backup, see the following Microsoft Knowledge Base articles:

• "How to Use Key and Certificate Backup/Restore Utility" on the Microsoft Knowledge Base.

• "Certificate Server Does Not Create Backups of Installed Keys" on the Microsoft Knowledge Base. (This article applies only to Windows 2000 Server.)

Repair the Certificate Store

When you restore a CA that maintains its CA certificate with a software CSP on a different computer, you must repair the CA configuration to allow the CA to gain access to the original CA certificate. When the CA software, the database, and CA configuration are restored, you need to install the CA certificate to the local computer's certificate store. You can also use the following command to share an HSM across multiple computers:

certutil -addstore my CA01.Contoso.com_CARoot.crt

After you use this command, use the following command to determine the certificate hash:

cerutil CA01.Contoso.com_CARoot.crt | findstr /c: Key Id Hash(sha1)

When you use this command, it displays the CACertSHA-1Hash value. Take the hexadecimal string representing the SHA-1 hash (known as the thumbprint property of a certificate) and use it as a parameter in the next command. For example, you might type the following command:

certutil -repairstore my "ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5 09 d9 b6 32 1b"