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.

For more information about relation between the above three fields, see http://technet.microsoft.com/en-us/library/ee619723(v=ws.10).aspx.

Now we know the CRL attributes that control the CRL validity. The question is how these dates are calculated by a Windows CA. Read on to find out!

Under the Certification Services configuration hive in the registry two values control the overlap period for the base CRL and two registry values define the overlap period for delta CRL creation:

HLKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>:

CRLOverlapPeriod=REG_SZ:Hours|Minutes

CRLOverlapUnits=REG_DWORD:0x0

CRLDeltaOverlapPeriod=REG_SZ:Hours|Minutes

CRLDeltaOverlapUnits=REG_DWORD:0x0

You can verify the settings for the above registry keys on your CA computer with the following commands:

certutil -getreg CA\CRLOv*

certutil -getreg CA\CRLDeltaOv*

If the registry values are set and valid, the overlap period for a base or delta CRL is initially calculated by the CA as:

OverlapPeriod = CRLOverlapUnits * CRLPeriod

If an invalid or no value is present under the *CRLOverlapUnits* registry key, the *OverlapPeriod* for a base CRL is initially calculated as 10 percent of the *CRLPeriod* and *CRLPeriodUnits* registry values:

OverlapPeriod = (CRLPeriodUnits * CRLPeriod) / 10

If the *OverlapPeriod* for a Delta CRL is calculated, the entire period of time specified as *CRLDeltaPeriod* and *CRLDeltaPeriodUnits* of the delta CRL is used.

OverlapPeriod = (CRLDeltaPeriodUnits * CRLDeltaPeriod)

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.

OverlapPeriod = max(OverlapPeriod, 1.5 * ClockSkewMinutes)

In case the Overlap period is calculated for a base CRL, it cannot be longer than *CRLPeriodUnits* * *CRLPeriod*. Therefore the smaller value wins.

OverlapPeriod = min(OverlapPeriod, CRLPeriodUnits * CRLPeriod)

Is the Overlap time calculated for a delta delta CRL, the *OverlapPeriod* can not be longer than *CRLDeltaPeriodUnits* * *CRLDeltaPeriod*.

OverlapPeriod = min(OverlapPeriod, CRLDeltaPeriodUnits * CRLDeltaPeriod)

Finally, the *ClockSkewMinutes* are added to the calculated *OverlapPeriod*.

OverlapPeriod = OverlapPeriod + ClockSkewMinutes

The calculation of the *OverlapPeriod* is done so far. The the actual calculation of the CRL values can start a next step:

The **Effective Date** must not be earlier than the CA certificate became valid. This is because the CRL carries the CA certificate’s signature.

Effective Date = max(Current Time – ClockSkewMinutes, NotBefore_date_from_the_CA_certificate)

The **Next CRL Publish** for a base CRL is calculated as the sum of current time plus *CRLPeriod*:

Next CRL Publish = Current Time + (CRLPeriodUnits * CRLPeriod)

The **Next CRL Publish** for a delta CRL is calculated as the sum of current time plus *CRLDeltaPeriod*:

Next CRL Publish = Current Time + (CRLDeltaPeriodUnits * CRLDeltaPeriod)

The **Next Update** is for a base CRL is calculated with the following formula:

NextUpdate = min(Current Time + (CRLPeriodUnits * CRLPeriod) + OverlapPeriod + ClockSkewMinutes, NotAfter_date_from_the_CA_certificate)

The **Next Update** is for a delta CRL is calculated with the following formula:

NextUpdate = min(Current Time + (CRLDeltaPeriodUnits * CRLDeltaPeriod) + OverlapPeriod + ClockSkewMinutes, NotAfter_date_from_the_CA_certificate)

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:

certsrv.msc /e

With the /e switch, an additional container is shown in the snap-in that lists all CRLs at a glance.

VPN Reconnect in Windows 7 RC- redux

[comment] I am trying to understand how these values affect the behavior of the Crypto API CRL fetching and caching. Do you have a link or pointer you could share?

[response] The "Certificate Revocation and Status Checking" whitepaper (http://technet.microsoft.com/en-us/library/bb457027.aspx#EFAA) contains information

about the Crypto API CRL fetching and caching.

[comment] Can you explain why the base CRL cannot be longer than CRLPeriodUnits * CRLPeriod?

[response] You are asking why the OverlapPeriod of a base CRL cannot be longer than CRLPeriodUnits * CRLPeriod?

The OverlapPeriod is defined as "The period by when the CRL should be renewed before it is expired." You cannot renew a CRL before it is created.

[comment] Also, a few editing comments. Can the units for the Period registry keys (CRLOverlapPeriod, CRLDeltaOverlapPeriod, CRLPeriod) also be "Days" or "Months"?

[response] No because the OverlapPeriod is limited to a max value of 12 hours.

[comment] In your first calculation of OverlapPeriod, I believe that the formula should be OverlapPeriod = CRLOverlapPeriod * CRLOverlapUnits.

[response] I have corrected this. Thanks!

[comment] Finally, threading together base CRL and delta CRL calculations makes this note harder to understand. Have I correctly understood the base CRL calculation to be as follows?

min( ( CRLOverlapUnits isvalid ? CRLOverlapUnits * CRLOverlapPeriod : CRLPeriodUnits * CRLPeriod / 10 ), CRLPeriodUnits * CRLPeriod)

[response] I assume that you are talking about the NextUpdate for a base CRL. The NextUpdate for a base CRL is calculated as stated in the blog post.

Thanks for the info. I am trying to understand how these values affect the behavior of the Crypto API CRL fetching and caching. Do you have a link or pointer you could share?

Can you explain why the base CRL cannot be longer than CRLPeriodUnits * CRLPeriod?

Also, a few editing comments. Can the units for the Period registry keys (CRLOverlapPeriod, CRLDeltaOverlapPeriod, CRLPeriod) also be "Days" or "Months"? In your first calculation of OverlapPeriod, I believe that the formula should be OverlapPeriod = CRLOverlapPeriod * CRLOverlapUnits. Finally, threading together base CRL and delta CRL calculations makes this note harder to understand. Have I correctly understood the base CRL calculation to be as follows?

min( ( CRLOverlapUnits isvalid ? CRLOverlapUnits * CRLOverlapPeriod : CRLPeriodUnits * CRLPeriod / 10 ), CRLPeriodUnits * CRLPeriod)

Thanks again,

Dan

Great article! Base CRL seems totally clear now. But Delta CRLs are stilly confusing. Where is the

CRLDeltaOverlapUnits Value actually used?

First you say:

"If the registry values are set and valid, the overlap period for a base or delta CRL is initially calculated by the CA as:

OverlapPeriod = CRLOverlapUnits * CRLPeriod"

So I assume it would be:

OverlapPeriod = CRLDeltaOverlapUnits * CRLDeltaOverlapPeriod

For Example if CRLDeltaOverlapUnits = 3 and CRLDeltaOverlapPeriod is hours then OverlapPeriod would be 3hours

But two steps further you say:"If the OverlapPeriod for a Delta CRL is calculated, the entire period of time specified as CRLDeltaPeriod and CRLDeltaPeriodUnits of the delta CRL is used:

OverlapPeriod = (CRLDeltaPeriodUnits * CRLDeltaPeriod)"

Thats confusing – here is no CRLDeltaOverlapUnits at all? Or does this line only come into play when no CRLDeltaOverlapUnits is initially set?

It would be awesome if you can underline how the OverlapPeriod in

OverlapPeriod = min(OverlapPeriod, 12 hours) – is actually calculated for DeltaCRLs

Thank You

I need to add one more Issue Enterprise CA on another site.

What better way to meet this demand?