CA Maintenance

Applies To: Windows Server 2003 with SP1

Setting up the PKI is a small step compared to the management and operational tasks that are associated with the public key infrastructure.

CA Remote Maintenance

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

If the Certificate Services MMC Snap-In should be used for remote administration, see Users Allowed to Manage the CA Cannot Access It Remotely [271470] to take the appropriate steps to make the CA remotely accessible.

Even if it is technically possible, a CA should not be maintained through a Terminal Server session because it increases the attack spectrum, and because some administration tools—like certutil.exe—do not work properly if used in a Terminal Server session.

Note

A Windows 2000 CA may not be managed using the Windows Server 2003 version of the Certification Authority MMC snap-in, or vice-versa.

Publish the CRL of an Offline CA

The actual offline CRL publication should be performed at a minimum of several days before the actual expiration of the previously issued CRL. This should be performed to provide a safety factor in case the offline root CA has a hardware or publication failure. Adequate time should be allotted to ensure that any errors or failures can be corrected and to enable actual publication and replication of the CRL to all CDP locations.

Once the CDP extensions have been updated on the CA, new CRL(s) should be published so that all clients who download the CRL have the latest download information (for example, Delta CRL URL).

To manually publish a CRL on an offline CA

1. Select the Revoked Certificates node of the certification authority MMC snap-in.

2. Right-click, select All Tasks, and then click Publish.

   A new base and delta (if configured) CRL will be published.

   

   A prompt will be displayed asking to confirm which type(s) of CRL(s) should be published with this request. Since only base CRLs are being published from the offline root CA, only the New CRL option will be available.

3. Click OK.

   

4. Root CA certificates may be published manually to Active Directory using the Windows Server 2003 version of the certutil.exe –dspublish command from the command line if logged in as an account that is a member of the Enterprise Admin Group or a domain admin from the root (first) domain in the forest.

   The equivalent command in Windows 2000 is called dsstore.exe. For more information about pushing CA certificates manually into Active Directory, see the following Knowledge Base article:

   • HOW TO: Use the Directory Services Store Tool to Add a Non-Windows 2000 Certification Authority (CA) to the PKI in Windows 2000 [313197]

CRL Re-Sign

In some scenarios, it may not be possible to publish a CRL from an offline CA. In this case, with Windows Server 2003, the old CRL may be re-signed without using the certification authority. This process assumes the availability of the CA private key(s) outside of the CA to actually sign the CRL. To update an expiring CRL, the old CRL file will need to be retrieved first. It will be available in Active Directory if the CA is an Enterprise CA or if Active Directory was accessible when the CA was installed, or in the %windir%\System32\CertSrv\CertEnroll directory on the CA computer itself.

The simple syntax for re-signing a CRL is

certutil -sign <existing CRL file name> <resigned CRL file name> 

You can also add or remove serial numbers, or remove extensions, or change the length of time the CRL will be valid through the certutil.exe –sign command.

The default is to re-sign the CRL to be valid starting 10 minutes prior to the signature (to allow for clock skew), and a lifetime (NextUpdate) equal to the old CRL. Use the following command to publish the CRL to Active Directory. Certutil will state whether the object in Active Directory was updated or if it was already up-to-date.

certutil -dspublish <resigned CRL file name> 

Publishing to a file://, ftp:// or an https:// location can be done by copying the CRL file manually to that location. The following command executed on the CA computer should display the next time the CA expects to wake up and publish the next CRL:

certutil -getreg ca\CRLNextPublish 

Dumping the CRL with the certutil command will display the 1.3.6.1.4.1.311.21.4 (Next CRL Publish) extension, which should be equivalent to the CRLNextPublish registry value (but the syntax of the two displays is different). Certutil -sign strips this extension out of re-signed CRLs, because the next issue date is misleading at best after re-signing. Dumping a certificate issued by the CA with the certutil command will display the ldap:///, https://, and file:// URLs where the CRL is stored.

Administrative Process for Offline CRL Publication

The following is a sample process outline that may be followed for publishing an offline CA's CRL:

Several days before the current CRL is due to expire, the offline Root CA system is removed from its protected location (usually in secured storage such as double-locked closet, combination safe, or other physically well-protected locations); normally two or more staff are present (for example, one IT administrator as well as a supervisory manager).

The root CA computer is powered up and logged on with an account with appropriate permissions.

The MMC is started and the CA's CRL is published to the local drive.

The CRL is copied to a disk or other removable media.

The offline Root CA server is logged out and shut down, and placed into a secured storage.

The removable media is taken to the publishing or staging servers, and the CRL is copied to the appropriate location(s), according to the current CDP locations published in non-expired certificates from the CA.

Important

It is extremely important for administrators to perform regular (test) restores of their offline CAs to see if the procedure for backup/restore performs as expected. Disaster recovery procedures and testing are paramount in operating a public key infrastructure.

Certification Authority Renewal

Best Practices for Renewing CAs

Certification authorities are renewed or replaced for a multitude of reasons. The following are the most common reasons for CA renewal:

• Increase the lifetime of the CA

• Change the key used by the CA

• Increase the key size of the CA

• Add certificate policies to the CA (qualified subordination)

• CRL partitioning

The first three reasons may be performed by using a capolicy.inf file when renewing the CA. If renewing a root CA, it is important to understand that the root CA certificate will need to be re-distributed to all clients that will trust the root CA. Otherwise, existing clients will only be aware of the exiting root CA certificate and will have no mechanism for discovery of the renewal event.

When a CA is renewed, various objects and attributes will be updated or changed. If the CA is an Enterprise root or subordinate CA, the following objects in Active Directory will be updated:

The updated CA certificate (cACertificate) and cross-certificate (CrossCertificatePair if renewal with a new key pair is performed) will be published to the AIA container.

A new CRL will be published for every key pair the CA has used.

The new certificate will be published to the NTAUTH object.

The new certificate will replace the existing certificate in the enrollment services container.

Note

If the enrollment services container had been previously deleted, it will be replaced on renewal and the default templates will be re-installed as well, if they have been deleted.

CRL Partitioning

CRL partitioning is another main reason why administrators often renew an issuing CA. When a CA is renewed with a new key, a new key and certificate are generated for that CA. When a new key and certificate are generated, the CA will use the new key as well as any unexpired previous keys corresponding to previous certificates when generating revocation information. Therefore, a CA may be using multiple keys at the same time and will publish multiple CRLs corresponding to those keys. This may be seen in the Certification Authority MMC snap-in by selecting the CA properties.

The renewal status of the CA may also be determined by examining the CA certificate itself. The CA version extension will identify how many times a CA has been renewed and how many times with a new key. In this case, the CA has been renewed three times and with each instance, a new key, hence the 3.3 version number as displayed in the following screen.

Once a CA has been renewed with a new key, only the new key will be used in signing new certificates. The unexpired previous key(s) will continue to be used to sign CRLs for certificates that were signed using 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 using the Microsoft CA.

Automatic RootCA Cross-Certificate Generation

Windows Server 2003 has introduced the capability for Microsoft root certification authorities with access to Active Directory to automatically issue and publish a cross-certificate 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 will cross-certify the renewed root CA certificate as being a qualified subordinate to the old root CA certificate. For more information about qualified subordination, see the Planning and Implementing Qualified Subordination for Using Windows Server 2003 Enterprise Server white paper.

This functionality is especially important to customers who have had an existing root CA trusted by other organizations, bridge CAs, or cross-certified by other organizations. To configure or disable this functionality, the following commands may be performed on the root CA.

• To force the root CA to use the CrossCA certificate template, the following command should be run. Otherwise, without this flag, the CA will never use the CrossCA certificate template (even if it is available), and will fall back to generating a certificate without the template, using predefined extensions:

  certutil -setreg ca\CRLFlags +CRLF_USE_CROSS_CERT_TEMPLATE 
  

• To disable automatic CrossCA certificate generation, run the following command:

  certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS 
  

• To enable automatic CrossCA certificate generation again, run the following command:

  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, run the following command. Without this flag, the CA will use the CAExchange cert template when available, and fall back to generating a certificate without the template, using predefined extensions.

  certutil -setreg ca\CRLFlags +CRLF_USE_XCHG_CERT_TEMPLATE 
  

Key Backup

If you are using a smartcard or other hardware key and the computer fails, you will need to move the smartcard or key device to another computer, install the CA certificate, and possibly add the KeyProvInfo property to the CA certificate, so the private key's CSP and container name, and so on, will be available. This may be accomplished using the certutil.exe –repairstore command (see below). This is usually done automatically when a smart card is inserted into a reader.

If you are using a software-based CSP and the computer fails, it is necessary to use the certutil -backupkey command prior to the hardware failure to save the CA's keys and certificates in a PFX file (PKCS #12) encrypted with a password, and use certutil -restorekey on the second computer.

To add the KeyProvInfo property, use the following command. Include the -user option if the certificate may have been imported into the HKEY_CURRENT_USER personal store.

certutil -repairstore my CACertSHA-1Hash  

or

certutil -repairstore -user my CACertSHA-1Hash  

If necessary, dump the certificate with certutil.exe –dump <file name> to display the SHA-1 certificate hash.

Backup/Recovery

Best practice Backing up the certification authority database, the CA certificate, and the CA keys is essential to protect against the loss of critical data. The CA should be backed up on a regular basis (daily, weekly, monthly) based on the number of certificates issued over the same interval. The more certificates issued, the more frequently the CA should be backed up.

For additional information, see the Microsoft Knowledge Base:

Certificate Server Does Not Create Backups of Installed Keys [216922] (This article applies to Windows 2000 only.)

Removing a CA from Active Directory

Removing a CA from any public key infrastructure or Active Directory environment may have a significant impact on applications and services. Therefore, careful planning is always recommended before removing a CA. Always perform a complete backup and maintain that backup for a period of time should a restore be required at a later date.

Uninstalling an Enterprise Certification Authority

To decommission a root certification authority, all outstanding certificates issued by that CA should be revoked. After revocation, the Certificate Revocation List (CRL) should be published.

1. Revoke all issued certificates.

   • Start the Certification Authority MMC snap-in.

   • Click the Issued Certificates folder.

   • Highlight one of the issued certificates, and then press CTRL+A to select all issued certificates.

   • Right-click the highlighted certificates, select All Tasks, and then click Revoke Certificate.

   • In the Certificate Revocation dialog box, select Cease of Operation as the reason for revocation.

   • Click OK.

2. Increase the CRL publication interval.

   • In the Certification Authority MMC snap-in, right-click the Revoked Certificates folder.

   • Select Properties.

   • Increase the Publication Interval to a suitably long value (5 years).

     The lifetime of the CRL should be longer than the remaining lifetime of the certificates that have been revoked.

   • Clear the Publish Delta CRLs check box if it is selected.

   • Click OK.

3. Publish the new CRL.

   • In the Certification Authority MMC snap-in, right-click the Revoked Certificates folder.

   • Select All Tasks, and then select Publish.

   • Choose New CRL as the type of CRL to publish.

   • Click OK.

4. Stop Certificate Services.

   • At the command prompt, type

     certutil –shutdown
     

5. List all the key stores for the local computer.

   • At the command prompt, type

     certutil –key
     

   This will display the names of all the installed Cryptographic Service Providers (CSP) and the key stores associated with each provider. Among the listed key stores, you will see the name of your CA listed several times. The following is the sample output.

   Microsoft Strong Cryptographic Provider: 
     Enterprise Root CA 
       AT_SIGNATURE 
     Enterprise Root CA(11) 
       AT_SIGNATURE 
     Enterprise Root CA(13) 
       AT_SIGNATURE 
     Enterprise Root CA(4) 
       AT_SIGNATURE 
     Enterprise Root CA(14) 
       AT_SIGNATURE 
     Enterprise Root CA(9) 
       AT_SIGNATURE 
     Enterprise Root CA(7) 
       AT_SIGNATURE 
     Enterprise Root CA(6) 
       AT_SIGNATURE 
     MS IIS DCOM Server 
       AT_SIGNATURE, AT_KEYEXCHANGE 
     Enterprise Root CA(2) 
       AT_SIGNATURE 
     Enterprise Root CA(12) 
       AT_SIGNATURE 
     Enterprise Root CA(16) 
       AT_SIGNATURE 
     Enterprise Root CA(1) 
       AT_SIGNATURE 
     Microsoft Internet Information Server 
       AT_SIGNATURE, AT_KEYEXCHANGE 
     Enterprise Root CA-Xchg(7) 
       AT_KEYEXCHANGE 
     Enterprise Root CA(5) 
       AT_SIGNATURE 
     Enterprise Root CA(8) 
       AT_SIGNATURE 
     Enterprise Root CA(15) 
       AT_SIGNATURE 
     Enterprise Root CA(3) 
       AT_SIGNATURE 
   

6. Delete the private keys associated with the CA.

   • At the command prompt, type

     certutil –delkey <CA Name> 
     

   If your CA name contains spaces, enclose it in quotation marks.

   Note

   Repeat this step for all the key containers of your CA. You will need to do this if your CA has multiple certificates.

7. List the key stores again to verify that the private key for your CA has been deleted.

8. Use Add or Remove Programs to uninstall Certificate Services.

Active Directory Objects

When Microsoft Certificate Services is installed on a server that is a member of a domain, several objects are created in the Configuration container in Active Directory. These objects are

• certificateAuthority object

  • Located in CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=

  • Contains the CA certificate for the Certification Authority

  • Published Authority Information Access location

• crlDistributionPoint object

  • Located in CN=<servername>,CN=CDP,CN=Public Key Service,CN=Services,CN=Configuration,DC=

  • Contains the CRL periodically published by the certification authority

  • Published CRL Distribution Point location

• certificationAuthority object

  • Located in CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=

  • Contains the CA certificate for the certification authority

• pKIEnrollmentService object

  • Located in CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=

  • Created by Enterprise CAs. Contains information about the types of certificates the CA has been configured to issue. Permissions on this object can control which users are allowed to enroll against this CA.

• msPKI-PrivateKeyRecoveryAgent object

  • Located in CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=

  • Contains the Key Recovery Agent certificate(s)

When the CA is uninstalled, only the pKIEnrollmentService object is removed. The other objects are left in place because there are likely still outstanding certificates issued by the CA. In order for clients to successfully process these outstanding certificates, they need to locate the AIA and CDP paths in Active Directory. Good practice is to revoke all outstanding certificates (Reason: Cease of Operation), extend the lifetime of the CRL, and publish it in Active Directory. When those outstanding certificates are processed by the various clients, validation should fail and those certificates will not be used.

If maintaining the CDP and AIA in Active Directory is not a priority, these objects can be safely removed.

To remove all Certification Services objects from Active Directory

1. Start Active Directory Sites and Services.

2. Click the View menu option, and select Show Services Node.

3. Expand the Services, and then expand Public Key Services.

4. Select the AIA node.

5. In the right-hand pane, locate the certificateAuthority object for your Certification Authority. Delete the object.

6. Select the CDP node.

7. In the right-hand pane, locate the Container object for the server where Certification Services is installed. Delete the container and the objects it contains.

8. Select the Certification Authorities node.

9. In the right-hand pane, locate the certificateAuthority object for your Certification Authority. Delete the object.

10. Select the Enrollment Services node.

11. In the right-hand pane, verify that the pKIEnrollmentService object for your Certification Authority was removed when Certificate Services was uninstalled. If not, delete it.

12. Select the Certificate Templates node.

13. In the right-hand pane, delete all the Certificate Templates.

    Warning

    Delete all the Certificate Templates only if no other Enterprise CAs are installed in the forest. If the templates are inadvertently deleted, restore the templates from backup.

14. Click the Public key Services node and locate the NTAuthCertificates object.

15. If there are no other Enterprise or Stand-alone CAs installed in the forest, delete the object, otherwise leave it alone.

CA Database

When Certification Services is uninstalled, the CA database is left intact in case the CA is to be recreated on another server.

To remove the CA database

• Delete the %systemroot%\system32\certlog folder.

Domain Controller Cleanup

Once the CA has been taken down, the certificates that have been issued to all the domain controllers need to be removed. This can be done quite easily using DSSTORE.EXE from the Resource Kit.

To remove old domain controller certificates

1. At the command prompt on a domain controller, type

   certutil -dcinfo deleteBad 
   

2. Certutil.exe will attempt to validate all the DC certificates issued to the domain controllers. Certificates that fail to validate will be removed.

At this point, you can reinstall Certificate Services. After the installation is finished, the new root certificate will be published to Active Directory. When the domain clients refresh their security policy, they will automatically download the new root certificate into their trusted root stores.

To force application of the security policy

• At the command prompt, type

  gpupdate /target:computer 
  

Best Practices for CRLs

Certificate Revocation List Defaults

Certificates that are revoked prior to expiration will remain in a published base CRL for one full base CRL period (defined by CA) after they expire. Certificates that expire will no longer be included in published CRLs after one additional base CRL is expired.

Note

The CRL table for the CA can be exported and converted to a tab-separated file for Microsoft Excel or other programs using the following commands:

certutil –view <name of CRL file> > crl.txt 

The following registry setting may be enabled on a CA to ensure that revoked certificates that have now expired are not removed from the CRL. Although most applications do not check CRLs for certificates that have expired, it is sometimes desirable in specific scenarios to maintain a public list of signing certificates that have been revoked.

To enable this option on the CA, use the following command:

certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS 

Application Reliability

Many applications rely on the availability of the certificate revocation list (CRL) and will fail completely should the CRL be inaccessible or out of date. One such example is the smartcard logon process. During smartcard logon, the client validates the domain controller certificate and the domain controller validates the user (client) certificate. If either validation fails, the smartcard logon process will fail. Therefore, it is highly desirable to keep the following best practices in mind when publishing CRLs:

1. The CRL should be valid for a reasonable period of time that would allow recovery of the CA should hardware or software failures occur. For example, a one-hour CRL publication period is most likely not adequate time to perform a hardware or software restoration in case of failure.

2. Set a reasonable CRL overlap period to dampen and overcome CRL publication or replication issues. For CRL overlap settings, see the next section. The CRL schedule for frequently publishing issuing CAs must be able to survive network and server downtime as well as take the replication latency of Active Directory into consideration. The CRL publication schedule must be longer than the maximum replication latency. In addition, the validity of a certificate must allow enough time to repair a broken network connection or to restore a down system. To enable this, the publication schedule must be shorter than the validity period of the CRL.

3. The private key of the CA and a copy of the CRL may be kept securely offline to manually sign and publish a valid CRL through certutil.exe when a catastrophic failure occurs.

4. For immediate denial of logon certificates, the account in Active Directory should be disabled. It is more efficient to delete or disable user accounts when a certificate should be revoked when a user should be denied access immediately.

5. CRLs should be published using Active Directory methods whenever possible for highest availability and best network performance. Always consider the expected propagation delay with a minimum replication time of 10 minutes.

6. CRLs should not be published to Active Directory when the CRL publication period is shorter than the replication convergence time for the Active Directory forest.

Revoking Large Numbers of Certificates

When a large number of certificates are revoked, such as during an employee layoff, the Delta CRL size may increase significantly due to the large number of entries, and almost all clients will refer to the older Base CRL. This situation will happen even if a new base CRL is published right after the revocation of the certificate until the new base is fully propagated.

To overcome this particular scenario where the Delta CRL is very large, perform the following steps on the CA:

1. Modify the registry values under the following registry key:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Name of CA>

   - Set the CRLOverLapPeriod to minutes. The default is hours.

   - Set the ClockSkewMinutes to 1minute. The default is 10.

2. Restart the CA.

3. Publish a new Base CRL. The Base CRL will have a CRLPropagationComplete time that will be just two minutes and any subsequent Delta CRLs will refer to this base CRL.

Once this has been completed, you can then restore the CRLOverLapPeriod and ClockSkew to the default values.

Controlling CRL Size

Often, it may be necessary to perform CRL partitioning to control the size of a Base CRL that is published from the CA. This is especially important for controlling both the data size that is replicated to Active Directory as well as the size of the data object downloaded by clients when performing revocation checks on certificates. CRL partitioning may be performed through CA key renewal which effectively creates a partitioned CRL for all subsequently issued certificates. For more information about this process, see the section on CA renewal.

Depending on the revocation reason chosen, the CRL will grow linearly in size by 29 bytes for every certificate that is revoked and added to the CRL. Accordingly, revoked certificates will be removed from the CRL when the certificate reaches its original expiration date. CAs may consider renewing the CA with a new key every 100-125K certificates to maintain a reasonable CRL size. This issuance number is based on the assumption that approximately 10 percent of the issued certificates will be revoked prior to their natural expiration date. If the actual or planned revocation rate is higher or lower for your organization, adjust the key renewal strategy accordingly.

Important

The more keys and certificates used by a CA will affect its performance in service restarts as each certificate and key must be validated before the CA will be operational.

Note

Windows 2000 and Windows Server 2003 do not support the issuance of the IDP extension for partitioned CRLs; however, Windows XP and Windows Server 2003 clients may use a partitioned CRL (using IDP extension). This is technically different from the method identified previously.

Remove Expired CRLs

By default, a CA will maintain an expired CRL in the database and will keep this CRL also in the directory at the last known CDP publication point for historical purposes. Once the key of a CA expires, the CRL is published one final time and no additional changes are made to that CRL. A best practice is to maintain this CRL in the CA database for long-term validation and audit purposes. However, it may be removed by using the following command:

certutil –setreg ca\CRLFlags + CRLF_DELETE_EXPIRED_CRLS  

For more information about how CRL checking and revocation status works see Windows XP: Certificate Status and Revocation Checking and How Certificate Revocation Works

See Also

Other Resources

Large CRLs: What is added to a Certificate Revocation List (CRL)?