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:
- 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:
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
PeriodUnitsspecifies scalar values, while units are identified byPeriodvalue. 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.
- CA gets a 1/10 of
CRLPeriodand compares it with 12 hour constant. If one tenth ofCRLPeriodis larger than 12 hours,InterimBaseCRLOverlapis set to 12 hours. If one tenth ofCRLPeriodis less than 12 hours, a 1/10 of CRLPeriod is assigned toInterimBaseCRLOverlap. This step ensures thatInterimBaseCRLOverlapis not larger than 12 hours. - If a value of
InterimBaseCRLOverlap(calculated in step 1) is less than1.5 * ClockSkewMinutes(by default it is 10 minutes, so 1.5 * 10 minutes = 15 minutes),1.5 * ClockSkewis assigned toInterimBaseCRLOverlap. Otherwise,InterimBaseCRLOverlapis not changed. This step ensures thatInterimBaseCRLOverlapis not smaller than1.5 * ClockSkewMintesand there will be a minimum reasonable overlap value. InterimBaseCRLOverlapis compared with CRL period and the smallest value is assigned toInterimBaseCRLOverlap. So far calculations ensured that Base CRL overlap is between1.5 * ClockSkewMinutes(15 minutes) and 12 hours. However, overlap period cannot be greater than CRL validity; therefore, if calculated value is greater thanCRLPeriod(assuming that CRLs are short living) then it is truncated toCRLPeriod. Otherwise,InterimBaseCRLOverlapis 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.
- First, CA gets a
CRLDeltaPeriodand compares it with 12 hour constant. If itCRLDeltaPeriodis larger than 12 hours,InterimDeltaCRLOverlapis set to 12 hours. IfCRLDeltaPeriodis less than 12 hours,CRLDeltaPeriodis assigned toInterimDeltaCRLOverlap. This step ensures thatInterimDeltaCRLOverlapis not larger than 12 hours. - If a value of
InterimDeltaCRLOverlap(calculated in step 1) is less than1.5 * ClockSkewMinutes(by default it is 10 minutes, so 1.5 * 10 minutes = 15 minutes),1.5 * ClockSkewis assigned toInterimDeltaCRLOverlap. OtherwiseInterimDeltaCRLOverlapis not changed. This step ensures thatInterimDeltaCRLOverlapis not less than1.5 * ClockSkewMintesand there will be a minimum reasonable overlap value. InterimDeltaCRLOverlapis compared with CRL period and the smallest value is assigned toInterimDeltaCRLOverlap. So far calculations ensured that Base CRL overlap is between1.5 * ClockSkewMinutes(15 minutes) and 12 hours. However, overlap period (once again) cannot be greater than CRL validity, therefore if calculated value is greater thanCRLDeltaPeriod(assuming that CRLs are short-living) then it is truncated toCRLDeltaPeriod. Otherwise,InterimDeltaCRLOverlapis not changed in this step.
Final computation, when ClockSkewMinutes are added to resulted InterimDeltaCRLOverlap value. The result of this step is final overlap value.
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.
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.
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.
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
> 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?
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
> 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.
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
> 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).
Hi Vadims
Firstly, thanks for all the effort you put in documenting the PKI theory and solutions and more over replying to queries.
Well, my query is about a solution I would like to put in my organisation. Requirement is:
Base CRL - 30 days and its overlap - 15 days (CRLPeriodUnits - 15, CRLOverlapPeriodUnits - 15) - I have achieved the desired result.
Delta CRL - 14 days and its overlap - 13 days (CRLDeltaPeriodUnits - 7, CRLDeltaOverlapPeriodUnits - 6) - I could only achieve with overlap as 7 days rather than 13 days. Basically I would like to issue a Delta CRL every day with each valid for 14 days to provide sufficient time for replication and more importantly sufficient to recover the CA for any issues unforeseen.
Would you be able to assist me here please ?
Thanks
Sans
@sans, I don't fully understand what you are trying to achieve.
> Basically I would like to issue a Delta CRL every day with each valid for 14 days
you can't. Overlap period cannot exceed main validity period. The only way to achieve this is to configure delta CRL with larger validity and use scheduled script to re-publish CRL daily.
Hi and hello Vadims !
Greeting from a friend of Mark C and Brian K :-)
After reviewing use cases of Get-CRL and Show-CRL, I'm looking for a way to determine CRL NextUpdate via a certificate issued from an ADCS Enterprise Issuing Root CA. The Issuing CA is NOT available, yet the CA cert is valid for a few more years. The CRL appears to be valid as existing PKI enabled applications continue to operate (for now !!!). The only CDP location is LDAP, where a .CRL file does not exist for inspection of NextUpdate. Any advice on extracting CRL data from AD ? Perhaps this could be an additional function for PSPKI.
Thanks, KB
> The only CDP location is LDAP, where a .CRL file does not exist for inspection of NextUpdate.
you can use PKIView.msc to look at CRL in a readable command. In addition, you can use new APIs to read PKI objects from AD:
[SysadminsLV.PKI.Management.ActiveDirectory.DsPkiContainer]::GetAdPkiContainer("CDP")
this command will return all CRL objects from Active Directory.
CRLOverlapPeriodUnits should be CRLOverlapUnits
I have a RootCA with HSM, I have CRLs published every 3 months, this server is offline, turned off, I only turn on for the period of CRL publication, I wonder what is the best practice with publishing CRL on RootCA, the period every 3 months is a bit troublesome, the servers are in a different city, can this period be extended, e.g. 6 months or once a year and what is the real impact on PKI, what is the best practice?
General recommendation is between 6-9 months. Make sure that your web server properly implements ETag and MaxAge HTTP headers. When configured (see this whitepaper: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee619730(v=ws.10)?redirectedfrom=MSDN), clients whill periodically poll HTTP server if there is new CRL without actually downloading the CRL and force CRL download when it is updated on a server. With this configuration 6-12mo CRLs are enough reliable.
Post your comment:
Comments: