Imagine that you are using both Base CRL and Delta CRL, but you want to stop using Delta CRL and only use Base CRL going forward. Could this cause any problems in revocation checking if you do not carefully plan it?
As a side note, I decided to color-code Base CRL and Delta CRL in this post, since they are mentioned ALOT and it might be easier to follow with that visual aid.
First off, how do applications (that perform the revocation checking in Windows) find out if a Delta CRL check is required? Well, if the Base CRL contains the attribute Freshest CRL, as seen in the screenshot below, the application knows that it needs to go to that location and find a valid Delta CRL before it can trust the certificate:
If you disable Delta CRL, that attribute will no longer be present in the Base CRL and the clients will only rely on that Base CRL.
But what will happen to clients that have a time valid Base CRL cached locally (with reference to a Delta CRL) if the CA server suddenly stops issuing new Delta CRLs during that Base CRL’s lifetime? My first guess was that applications that could not find a valid Delta CRL would be “smart enough” to try and download a new Base CRL (even if it had a time valid one in cache). Others suggested timing the disabling to sometime between when the last Delta CRL of a Base CRL was published and before a new Base CRL.
But I wanted to know for sure, so I decided to set up at lab and verify the behavior. I used Windows Server 2008 R2, since that is what my customer used in this case.
My first thought was to use a SSL certificate and Internet Explorer, but the default behavior of IE when you cannot reach a valid CRL is to allow the connection anyway and not even warn the user, see my earlier blog post about IE and revocation checking here.
So I decided to use smartcard logon instead, since that is one of the certificate use cases that requires a valid CRL. To my surprise the logon worked (with cached Base CRL with Delta CRL references, but no fresh Delta CRL published)!
My first thought was to verify that the client had in fact downloaded the new Base CRL, but almost by accident I discovered how this overlap problem is handled.
Let’s look at an example CA configuration:
To examine the details of the issued CRLs, click on the tab called View CRLs:
Click the button View CRL to see the details about this Base CRL:
Here you can see that it is valid between Jan 31 and Feb 9 (it will issue a new Base CRL on Feb 7 and allow some overlap time).
Let’s look at the Delta CRL:
You can see that it is valid between Jan 31 and Feb 2 (it will issue a new Delta CRL on Feb 1 and allow some overlap time).
Ok, let us disable Delta publishing on this CA server. Note that clients that already downloaded a copy of the Base CRL will not download a new one until 7 Feb):
If we now look at the new Base CRL:
The validity period intervals are the same as before (just 4 minutes later, when I did the change). It’s worth noting that when you disable Delta CRL a new Base CRL (without the Freshest CRL reference) is published immediately by the CA server.
What about the Delta CRL then? The button View Delta CRL is disabled, so we can’t find it via the GUI:
Well it you look in the folder C:\Windows\System32\CertSrv\CertEnroll (or any of your CRL Distribution Points that CRLs are published to) you will see the Delta CRL. The time stamp of the file indicated that it has also been automatically published at the exact time when you disabled Delta CRL.
Let’s open it and look at the details:
Look at that! The Delta CRL is signed one last time and the validity matches the new Base CRL. This guarantees that clients with cached old Base CRL’s will still be able to download a valid Delta CRL at least during the whole lifetime of the old Base CRL. When Next CRL Publish has passed, they will download the new Base CRL (without reference to Delta). So at no point in time will there be a Base CRL that do not have a valid Delta CRL.
Summary: There is no need to plan or use timing when disabling Delta CRLs on a CA, there is a built-in solution on the CA side to handle it.
Thanks for the blog… you articulated what could be a very messy article very well
Thank you!