Revoking certificates and publishing CRLs
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Revoking certificates and publishing CRLs
You can use the Certification Authority snap-in to revoke a certificate, to administer certificate revocation list (CRL) publication, and to specify the CRL Distribution Points (CDPs) published in every certificate issued by the certification authority (CA).
Revoking a certificate
To help maintain the integrity of an organization's public key infrastructure (PKI), the administrator of a CA must revoke a certificate if the subject of certificate leaves the organization, if the certificate subject's private key has been compromised, or if some other security-related event dictates that it is no longer desirable to have a certificate considered "valid." When a certificate is revoked by a CA, it is added to that CA's certificate revocation list (CRL). This may take the form of a new CRL or a delta CRL, which is a small CRL that lists the certificates that have been revoked since the last full CRL.
For conceptual information about the role of certificate revocation and revocation checking in a PKI, see Certificate revocation. For the procedure to revoke a certificate, see Revoke an issued certificate. For instructions on how to display the current CRL, see View the certificate revocation list.
Scheduling certificate revocation list (CRL) publication
One of the features of Certificate Services is that every CA automatically publishes an updated CRL after an interval of time specified by the administrator of the CA. This interval of time is known as the CRL "publish period." After the initial setup of a CA, the CRL publish period is set to one week (based upon the local computer's time, starting from the date when the CA is first installed). For the procedure to change a certification authority's CRL publishing interval, see Schedule the publication of the certificate revocation list. The CRL and delta CRL publish periods can be scheduled independently.
A CA administrator should understand that there is a difference between a CRL publish period and the validity period of a CRL. The validity period of a CRL is the period of time that the CRL is considered authoritative by a verifier of a certificate. As long as the verifier of a certificate has a valid CRL in its local cache, it will not attempt to retrieve another CRL from the CA which publishes it.
The publish period of a CRL is established by the CA administrator. However, the validity period of the CRL is extended from the publish period to allow for Active Directory replication. By default, Certificate Services extends the publish period by 10% (up to a maximum of 12 hrs) to establish the validity period. So, for example, if a CA is publishing a CRL every 24 hours, the validity period is set to 26.4 hours.
Additionally, there is a clock skew of an additional 10 minutes added to the validity period on either side of the publish period, so a CRL will be valid 10 minutes before the beginning of its publish period to account for variances in computer clock settings.
There are registry entries which allow an administrator to control the variance between publish period and validity period to allow for slower directory replication. For information about these registry entries, see the Microsoft Windows Deployment and Resource Kits.
When determining the schedule for CRL publishing, there is a trade-off between performance and security. The more often CRLs are published, the more current clients can be with the list of revoked CRLs and the less likely they are to accept recently-revoked certificates. However, frequent publishing can negatively impact network and client performance. To help mitigate this trade off, delta CRLs can be used if the environment supports them.
Using delta certificate revocation lists
CRLs can become very long on large CAs that have experienced significant amounts of certificate revocation. This can become a burden for clients to download frequently. To help minimize frequent downloads of lengthy CRLs, delta CRLs can be published. This allows the client to download the most current delta CRL and combine that with the most current base CRL to have a complete list of revoked certificates. Because the client will normally have the CRL cached locally, the use of delta CRLs can potentially improve performance.
To use delta CRLs, the client application must be aware of and explicitly use delta CRLs for revocation checking. If the client does not use delta CRLs, it will retrieve the CRL from the CA every time it refreshes its cache, regardless of whether a delta CRL exists or not. For this reason, you should verify that the intended applications use delta CRLs and configure the CA accordingly. If the clients do not support the use of delta CRLs, you should either not configure the CA to publish delta CRLs or configure it so CRLs and delta CRLs are published at the same interval. This would still allow future applications that support delta CRLs to use them, while providing current CRLs to all applications. Note that all applications that use CryptoAPI in Windows XP and the Windows Server 2003 family use delta CRLs.
Publishing a CRL before the next scheduled publish period
You can also publish a CRL on demand at any time, such as when a valuable certificate becomes compromised. Choosing to publish a CRL outside the established schedule resets the scheduled publication period to begin at that time. In other words, if you manually publish a CRL in the middle of a scheduled publish period, the CRL publish period is restarted.
It is important to realize that clients that have a cached copy of the previously published CRL will continue using it until its validity period has expired, even though a new CRL has been published. Manually publishing a CRL does not affect cached copies of CRLs that are still valid; it only makes a new CRL available for systems that do not have a cached copy of a valid CRL.
For the procedure to force the immediate publication of a CRL or delta CRL, see Manually publish the certificate revocation list.
CRL distribution points and the CRL file name
Every certificate that is issued by a Microsoft certification authority has CRL distribution points as part of its content. A CRL distribution point provides a certificate verifier with the network location where it can retrieve the current copy of the CRL or delta CRL. For procedures to designate the certificate revocation list distribution points in certificates, see Specify certificate revocation list distribution points in issued certificates.
By default, CRL and delta CRL files are published on the CA in the following location:
Systemroot\System32\Certsrv\Certenroll
The format of the CRL file name is the "sanitized name" of the CA plus, in parentheses, the "key id" of the CA (if the CA certificate has been renewed with a new key) and a .crl extension. Refer to the table for some sample CRL file names based on sample renewal histories of a CA:
| Scenario | Name of CRL file |
|---|---|
A certification authority named "MyCA" that has never had its CA certificate renewed |
myca.crl |
A certification authority named "MyCA" that has been renewed once with the same key |
myca.crl |
A delta CRL for a certification authority named "MyCA" that has been renewed once with the same key |
myca+.crl |
A certification authority named "MyCA" that has been renewed once with a new key |
myca(1).crl |
A certification authority named "MyCA" that has been renewed twice with a new key |
myca(2).crl |
See Installing and configuring a certification authority for information about a CA's "sanitized name."
See Renewing a certification authority for more information about CA renewal.
Enabling Netscape-compatible Web-based revocation checking
To enable Netscape-compatible Web-based revocation check extensions to be added to every certificate, run the following certutil command from the command prompt on the certification authority:
certutil -SetReg Policy\RevocationType +AspEnable
Then, stop and start the Certification Authority service. Certificates issued by the certification authority after it is restarted will contain the extension.
Important
- Because clients that use this type of revocation checking will access the CA through Web pages, Internet Information Services must have access to read the revocation information from the CA. If IIS does not have at least read-only access to the CA, access is denied by the CA and the revocation information will not be available.
For more information on the certutil command, see Certutil.