The validity time of a certificate revocation list (CRL) is critical for every public key infrastructure. By default, most applications verify the validity of certificates against a CRL.
Two CRL types exist: base CRLs and delta CRLs. In case where no delta CRL is used, certificates are treated as invalid if the base CRL is not available or expired. If a delta CRL is in use, the delta and base CRL must be available and valid to succeed with certificate verification.
The information provided in this article applies for both, the base CRL and the delta CRL generation.
When you look at a CRL, there is information about the Next update , the Next CRL Publish and the Effective date of the CRL. The term Effective date is used in the Windows certificate dialog while certutil.exe and the RFC name this field thisupdate .
Effective Date (aka thisupdate ) - The date that a CRL became effective. The effective time, by default, is set to 10 minutes prior to the current date and time to allow for clock synchronization issues.
Next CLR Publish - This non-critical CRL extension indicates the date and time when a Windows CA will publish a new CRL. When a Windows computer uses a CRL for certificate verification it also examines the Next CRL Publish extension. If the Next CRL Publish date is already in the past, it connects to the CRL distribution points (referenced in the certificate) and attempts a download of a newer CRL. Note: If CRL is locally cached, and under certain conditions, download of new CRL might be skipped, even if Next CRL Publish date is already in the past. For more information, please see http://technet.microsoft.com/en-us/library/ee619723(v=ws.10).aspx. The time after the Next CRL Publish and before the Next Update is a buffer time to allow Windows computers retrieval of a CRL before the CRL has actually expired.
Next Update - The date and time that a Windows client considers as the expiration date of the CRL. From an operational viewpoint, this is the most critical information. If this date passes, Windows computers will invalidate certificates that are checked against this CRL.
As a next step, the smaller value of either the so far calculated OverlapPeriod or 12 hours is taken.
OverlapPeriod = min(OverlapPeriod, 12 hours)
If no CRLPeriodUnits or CRLDeltaPeriodUnits have been set, the OverlapPeriod is 0 at this point. As a next step, the ClockSkewMinutes parameter from the registry is taken into account. The ClockSkewMinutes are primarily used to mitigate time differences between a client computer and the CA. To further calculate the OverlapPeriod , the ClockSkewMinutes is multiplied by 1.5 and then compared with the calculated OverlapPeriod . The greater of both values wins.
Since you have understood the algorithm now, you may want to examine the CRL on your system and see what the dates are set to. If you open the certificate management MMC snap-in from a command-line, you can see a list of all CRLs that have been generated by the CA so far. At a command-prompt, perform the following command:
With the /e switch, an additional container is shown in the snap-in that lists all CRLs at a glance.