How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2)

Disclaimer: this article is a rewritten, updated and clarified version of the article posted by John Morello: How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated.

This article is also available on TechNet Wiki.


This article describes how CA server calculates estimated CRL validity. By default, CRL validity is configured in a safe manner, so everything works without administrator interaction. However, if you are an experienced PKI administrator and plan custom CRL validity, it is important to understand how validity is calculated.

First, we need to determine CRL fields that identify CRL validity and the next update date:

Certificate Revocation List

 

  • Effective Date (This Update) – a mandatory field that indicates the start of CRL validity.
  • Next Update – a mandatory field that indicates when CRL expires and becomes invalid for revocation checking.
  • Next CRL Publish – an optional extension that indicates the date and time when a CA issues a new CRL.

The diagram below displays relations between these fields:

CRL lifetime

In order to calculate values for these fields, CA server (we are talking about MS CA) has the following configuration settings. CA server uses them to calculate each time field in CRL.

  • CRLPeriod – Base CRL validity period;
  • CRLOverlapPeriod – Base CRL overlap period;
  • CRLDeltaPeriod – Delta CRL period;
  • CRLDeltaOverlapPeriod – Delta CRL overlap period;
  • ClockSkewMinutes – an extra timeframe intended to mitigate possible time synchronization issues. “The case about actual certificate signing time” article covers details of this setting.

Each of the first four settings consist of two registry entries:

  • *PeriodUnits – specifies the scalar validity value;
  • *Period – specifies the measurement (units) for the value specified in the *PeriodUnits.

Registry entry names are confusing, because PeriodUnits specifies scalar values, while units are identified by Period value. However, everything is correct here. Microsoft noticed this mistake when they released the beta version of Windows 2000, but decided not to make possible breaking change to maintain compatibility with scripts written for the beta version.

Notation

This article uses the following formula components:

Field = MaximumOf(value1, value2,...,valuen) – means that filed value is the largest value of all values listed in parentheses. Values are separated by comma.

Field = MinimumOf(value1, value2,...,valuen) – means that filed value is the smallest value of all values listed in parentheses. Values are separated by comma.

This Update

This Update field identifies the date and time when CRL becomes valid. CRL expires when this value is greater than current time. Normally the value is calculated by using the following formula:

ThisUpdate = MaximumOf(CurrentTime – ClockSkewMinutes, CANotBefore)

In other words, usually ThisUpdate field value is CurrentTime minus ClockSkewMinutes (10 minutes by default). However, there is an exception when CA certificate is renewed. In this case, CurrentTime minus ClockSkewMinutes may occur prior to CA certificate validity. In this case, ThisUpdate field value equals to NotBefore value of the CA certificate.

Next CRL Publish

Next CRL Publish extension identifies the time when next CRL is issued. This extension value is calculated as follows for Base and Delta CRLs:

NextCRLPublish (Base CRL) = MinimumOf(CurrentTime + CRLPeriod, CANotAfter)
NextCRLPublish (Delta CRL) = MinumumOf(CurrentTime + CRLDeltaPeriod, CANotAfter)

If CRLDeltaPeriod is equal to zero, Delta CRL is not published. CRL cannot be valid after CA certificate expiration.

Next Update

Next Update identifies the point in time when CRL expires. This field value is calculated as follows for Base and Delta CRLs:

NextUpdate (Base CRL) = MinimumOf(NextCRLPublish + InterimBaseCRLOverlap, CANotAfter)
NextUpdate (Delta CRL) = MinimumOf(NextCRLPublish + InterimDeltaCRLOverlap, CANotAfter)

There are two unknowns: InterimBaseCRLOverlap and InterimDeltaCRLOverlap. Overlap values are used to provide an extra validity for each CRL. It is useful to provide extra validity to mitigate the following cases:

  • Active Directory replication delays;
  • CRL distribution from CA server to revocation server delays;
  • Temporary network connectivity issues;
  • Unexpected server failure.

Generally speaking, CRLs must be distributed from CAs to target locations (revocation servers) in a timeframe between NextCRLPublish and NextUpdate.

InterimBaseCRLOverlap

The InterimBaseCRLOverlap value calculation depends on CRLOverlapPeriod value. If it is non-zero and is valid, then the value is calculated as follows:

InterimBaseCRLOverlap = CRLOverlapPeriod + ClockSkewMinutes

If CRLOverlapPeriod is zero or invalid, CA performs multistep value evaluation:

1. InterimBaseCRLOverlap = MinimumOf(0.1 * CRLPeriod, 12 hours)
2. InterimBaseCRLOverlap = MaximumOf(InterimBaseCRLOverlap, 1.5 * ClockSkewMinutes)
3. InterimBaseCRLOverlap = MinimumOf(InterimBaseCRLOverlap, CRLPeriod)
4. InterimBaseCRLOverlap = InterimBaseCRLOverlap + ClockSkewMinutes

CRLOverlapPeriod is considered invalid under one or more of the following conditions:

  • Registry value is not present
  • Has non-integer value
  • Has integer value that is less than 1.5 * ClockSkewMinutes + ClockSkewMinutes

Here is an explanation of this process.

  1. CA gets a 1/10 of CRLPeriod and compares it with 12 hour constant. If one tenth of CRLPeriod is larger than 12 hours, InterimBaseCRLOverlap is set to 12 hours. If one tenth of CRLPeriod is less than 12 hours, a 1/10 of CRLPeriod is assigned to InterimBaseCRLOverlap. This step ensures that InterimBaseCRLOverlap is not larger than 12 hours.
  2. If a value of InterimBaseCRLOverlap (calculated in step 1) is less than 1.5 * ClockSkewMinutes (by default it is 10 minutes, so 1.5 * 10 minutes = 15 minutes), 1.5 * ClockSkew is assigned to InterimBaseCRLOverlap. Otherwise, InterimBaseCRLOverlap is not changed. This step ensures that InterimBaseCRLOverlap is not smaller than 1.5 * ClockSkewMintes and there will be a minimum reasonable overlap value.
  3. InterimBaseCRLOverlap is compared with CRL period and the smallest value is assigned to InterimBaseCRLOverlap. So far calculations ensured that Base CRL overlap is between 1.5 * ClockSkewMinutes (15 minutes) and 12 hours. However, overlap period cannot be greater than CRL validity; therefore, if calculated value is greater than CRLPeriod (assuming that CRLs are short living) then it is truncated to CRLPeriod. Otherwise, InterimBaseCRLOverlap is not changed in this step.

Final computation, when ClockSkewMinutes are added to the resulting InterimBaseCRLOverlap value. The result of this step is the final overlap value.

For example, CRLPeriod is set to 1 week (168 hours), the resulting value will be 12 hours plus ClockSkewMinutes, or 12 hours and 10 minutes.

If CRLPeriod is 1 day (24 hours), the resulting value will be 2 hours 24 minutes plus ClockSkewMinutes or 2 hours and 34 minutes.

If CRLPeriod is 1 hour, the resulting value will be 34 minutes.

In other words, Base CRL overlap value will never be less than 24 minutes and no greater than CRLPeriod (assuming that ClockSkewMinutes property has default value).

InterimDeltaCRLOverlap

The InterimDeltaCRLOverlap value calculation depends on CRLDeltaOverlapPeriod value. If it is non-zero and is valid, then the value is calculated as follows:

InterimDeltaCRLOverlap = CRLDeltaOverlapPeriod + ClockSkewMinutes

If CRLDeltaOverlapPeriod is zero or invalid (for example, it is a negative number or the unit value is invalid), CA performs multistep value evaluation:

  1. InterimDeltaCRLOverlap = MinimumOf(CRLDeltaPeriod, 12 hours)
  2. InterimDeltaCRLOverlap = MaximumOf(InterimDeltaCRLOverlap, 1.5 * ClockSkewMinutes)
  3. InterimDeltaCRLOverlap = MinimumOf(InterimDeltaCRLOverlap, CRLDeltaPeriod)
  4. InterimDeltaCRLOverlap = InterimDeltaCRLOverlap + ClockSkewMinutes

Here is an explanation of this process.

  1. First, CA gets a CRLDeltaPeriod and compares it with 12 hour constant. If it CRLDeltaPeriod is larger than 12 hours, InterimDeltaCRLOverlap is set to 12 hours. If CRLDeltaPeriod is less than 12 hours, CRLDeltaPeriod is assigned to InterimDeltaCRLOverlap. This step ensures that InterimDeltaCRLOverlap is not larger than 12 hours.
  2. If a value of InterimDeltaCRLOverlap (calculated in step 1) is less than 1.5 * ClockSkewMinutes (by default it is 10 minutes, so 1.5 * 10 minutes = 15 minutes), 1.5 * ClockSkew is assigned to InterimDeltaCRLOverlap. Otherwise InterimDeltaCRLOverlap is not changed. This step ensures that InterimDeltaCRLOverlap is not less than 1.5 * ClockSkewMintes and there will be a minimum reasonable overlap value.
  3. InterimDeltaCRLOverlap is compared with CRL period and the smallest value is assigned to InterimDeltaCRLOverlap. So far calculations ensured that Base CRL overlap is between 1.5 * ClockSkewMinutes (15 minutes) and 12 hours. However, overlap period (once again) cannot be greater than CRL validity, therefore if calculated value is greater than CRLDeltaPeriod (assuming that CRLs are short-living) then it is truncated to CRLDeltaPeriod. Otherwise, InterimDeltaCRLOverlap is not changed in this step.

Final computation, when ClockSkewMinutes are added to resulted InterimDeltaCRLOverlap value. The result of this step is final overlap value.

Comments:

Ammar
Ammar 28.12.2013 05:50 (GMT+3)

It is one of the most interesting blog posts regarding CRL overlap. I want to thank you for putting the effort of putting all this togather. Further more, I want to quote items from this blog post on a blog post im doing for CA SLA setting.

Ram
Ram 16.05.2014 10:15 (GMT+3)

I have a simple scenario on my Enterprise Issuing CAs" CRL Validity = 15 days. I want the Next CRL publish to be on the 7th day rather than the 14th day which is only one day before the CRL expires to avoid any risks. I ran the the following certutil -setreg CA\CRLOverlapPeriodunits 7 certutil -setreg CA\CRLOverlapPeriod "Days" This doesnt seen to work. Do we have a command like certutil -setreg CA\NextCRLPublish or something. I checked for this value in the registry and its there. Pls help.

Vadims Podans
Vadims Podans 16.05.2014 17:16 (GMT+3)

If you watch the diagram carefully, you will notice that NextCRLPublish will occur on CRL period. Therefore, you have to configure validity settings as follows: CRLValidityPeriodUnits = 7 CRLOverlapPeriodUnits = 7 in a given example, CRL will be published each 7 days, and it's validity will be 14 days.

Chipeater
Chipeater 16.05.2014 18:55 (GMT+3)

Hi Vadims, I know that "the rules" do not allow an CRLOverlap to be a great value than the CRLPeriod - is there a way around "the rules" :-) I have a "CRL lifetime" requirement of 7 days: I'd like to set the CRLPeriod as 1 day and the CRLOverlap as 6 days to: a) Help me keep a fresh CRL published every day b) Enable Microsoft relying parties like DCs to retrieve fresh CRLs more regularly. I know I can do manual CRL publications using scheduled tasks which would mitigate (a), but I'd still be facing an imperfect solution for (b). Is there anything you'd suggest? Regards, Chipeater

Vadims Podans
Vadims Podans 16.05.2014 22:11 (GMT+3)

> is there a way around "the rules" you can create a scheduled task which will publish CRLs each day, while CRLValidity period is set to 7 days. However I would not recommend this solution. > Enable Microsoft relying parties like DCs to retrieve fresh CRLs more regularly why not to use Delta CRLs?

Chipeater
Chipeater 17.05.2014 04:43 (GMT+3)

Hi Vadims, I prefer if possible to have a long CRL lifetime because in the enterprise so much depends on having a CRL available and using shorter validity period creates a great deal of risk. I have in this instance designed in a seven day CRL to enable plenty of time to recover a CA in the event of it going badly wrong. I have to cater for things like it crashing on a bank holiday weekend where there could be four days before it got any proper attention. Delta CRLs won't help in this situation and I am amazed at some of the designs that have things like four hour CRLs. Testing I have done confirms that delta CRLs are critical, so using them would massively affect the SLA for the "PKI service". I get frustrated when a lot of the Microsoft PKI documentation suggests using Delta CRLs of a day or less, without the user / system designer properly appreciating the huge risk on availability. And of course, I have to cater for both Cisco and CheckPoint VPN concentrators in my environment - I'm not sure they would recognise delta CRLs - they are something I have simply avoided at any cost. Obviously, this is all just opinion - I do recognise there's no right and wrong answer. But I do tend to play things very cautiously in the PKI because there are as many as fifty different applications and services that depend on the PKI in one way or another. Sorry for the long explanation. I love your work and it is immensely valued. You are up there with BK when it comes to Microsoft PKI. :-) Regards, Dave

Vadims Podans
Vadims Podans 18.05.2014 03:05 (GMT+3)

> I prefer if possible to have a long CRL lifetime CRL should have a reasonable validity. With long-living CRLs you are increasing revoked certificate detection latency. Too many people see CRLs and revocation system as a blocking issue (because they get problems when CRLs aren't available or expired), rather than an important component of PKI and trust. Certain administrators would easily publish a 10 year-valid CRL and forget about possible issues with expired CRLs. This is why you should combine Base and Delta CRLs to provide a reasonable revocation detection. Overlap settings shoul cover only file distribution latency (copy from isolated CA or AD replication delays). Other issues should be solved in a different ways. > to enable plenty of time to recover a CA in the event of it going badly wrong. This is what I talked in the previous section. CA crash should not be hidden by a CRL overlap. When CA crashed, the first thing to do is to use a backed up CA key (or the one that is stored on HSM) to extend CRL validity and resign the file to get some time to recover CA service. > I am amazed at some of the designs that have things like four hour CRLs exact my scenario :) I'm usually using a 4-hour valid Delta CRL with 1 hour overlap. > Testing I have done confirms that delta CRLs are critical, so using them would massively affect the SLA for the "PKI service" I don't think so. CA failure may immediately affect the SLA, because no one can get the certificate from it, while existing certificates could be used for a while. CA service is unavailable, period. If you have strict requirements on SLA, why not to cluster CA service? In addition, there are other options to control the situation. For example, you may have a service (or scheduled script) that will ping ICertRequest interface and sent an alert when interface ping fails. You can add options to the service/script which will take additional precaution steps. For example, if there are two CAs (non-clustered), the script can publish certificate templates (from failed CA) to a working CA, so clients will be able to continue certificate enrollment. Many and many options and they depend on a specific design and requirements. > I'm not sure they would recognise delta CRLs Cisco devices (which aren't 15-year old, or have upgraded IOS) support Delta CRLs.

Chipeater
Chipeater 19.05.2014 18:19 (GMT+3)

Hi Vadims, Thanks for the bit of sport... I will keep it going. I've implemented ADCS clusters before on Win2K8 and they're OK - but believe me - when you have tens of thousands of users on a PKI the very most important thing is to be able to maintain fresh CRLs rather than keep certificate issuance going from another cluster node. I am a pessimist and always think "what's the worst that could happen" :-) I appreciate that there's no single answer and designs all depend upon requirements, however, I am confident that encouraging 4 hour delta CRLs is fine for test environments - but very bad for production. As an example, we have 50,000 users - say 10,000 are relying upon PKI for VPN as well as tons of applications and systems. We have a fairly complex PKI where the Issuing CA is protected by HSM and requires multi-card (people) authorisation to start up - this could take a day to co-ordinate. Our over-riding requirement IS security - so we accept that there is an operational lag to start things - but we know the key components are suitably dispersed to help mitigate compromise. For me, a 4-hour delta CRL would be a disaster. IMHO delta CRLs should only be used in very rare occasions where you have limited bandwidth - if you have good bandwidth - why not just engineer the timings into your base CRL? Finally, I have observed on a previous engagement a client fail to publish a CRL at a Policy CA and copy it to AD which caused smart card logon to fail for over 100,000 users for nearly a whole day - I will never forget that day :-) Perhaps this has left a mental scar!!! :-) Regards, Chipeater

Vadims Podans
Vadims Podans 20.05.2014 03:53 (GMT+3)

> certificate issuance going from another cluster node Second node can publish CRLs too. > I am confident that encouraging 4 hour delta CRLs is fine for test environments - but very bad for production. can't agree with you. In common scenarios there is nothing wrong or bad. If you can't afford 4+1 hours, use other values to protect yourself from unnecessary problems. No one restricts you here. > a client fail to publish a CRL at a Policy CA and copy it to AD which caused smart card logon to fail for over 100,000 users for nearly a whole day and it is nothing about the subject. Tasks that include manual operations should be implemented accordingly. To mitigate human factor. It is another story, not a technical (about which we are talking here).

Captcha