PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies
In this blog posting I want to talk about revocation, in particular CRLs. I will cover some strategies for designing a revocation solution. This includes determining where to host CDP Repositories and how best to configure CRL publishing.
Revocation
When a CA Administrator determines that a certificate should no longer be trusted, the CA Administrator can log onto a CA and revoke a certificate. In order to communicate that revocation the CA publishes a Certificate Revocation List (CRL). In order to make the CRL accessible the CRL is published to a repository. These repositories are normally (at least in Windows) either an HTTP or LDAP repository. These repositories are then referenced in the CRL Distribution Point (CDP) Extension of a certificate. More than one CDP can be included in the CDP Extension. A client that is checking revocation will first attempt to download a CRL from the first CDP location referenced in the CDP extension. If that location is inaccessible, the client will try the next location and so on until it either downloads a CRL or times out.
Certificate Revocation Lists (CRLs)
There are two types of CRLs:
Base CRLs: A Base CRL is a CRL that contains all non-expired revoked certificates
Delta CRLs: A Delta CRL is a CRL that contains all non-expired certificates that have been revoked since the last base CRL was published.
If just Base CRLs are used then a client checking revocation only needs to download the Base CRL to determine if a certificate is revoked.
If both Base and Delta CRLs are used then clients checking revocation must download both the Base CRL and the Delta CRL to determine if a certificate is revoked. This assumes the client can use Delta CRLs. All currently supported Windows Operating Systems support Delta CRLs.
Below is an example of a Base CRL:
• Version: V2 means version 2 of the CRL Profile which is defined in RFC 5280
• Issuer: The CA that issued the CRL
• Effective Date: The date and time that the CRL first becomes valid
• Next Update: The date and time that the CRL expires
• Signature Algorithm: The Public Key Cryptography Algorithem and the Hashing Algorithem that were used to sign the CRL
• Signature hash algorithm: The hashing algorithm used in to sign the CRL
• Authority Key Identifier: This field gives additional information used to identify the issuer of the CRL
• CA Version: The bersion number of the CA certificate
• CRL Number: A unique identifier for the CRL
• Next CRL Publish: The date and time that the next CRL will be published
• Freshest CRL: If you are using Delta CRLs this field will show where the Delta CRL can be retrieved, typically this is the same location as the CRL.
Below is the same CRL showing the actual list of revoked certificates:
CDP Locations
When discussing PKI I often put emphasis on CDP locations. The reason is that the CDP location and CRLs in general are extremely critical for a PKI. If an application performs revocation checking and cannot download a CRL or the CRL is expired, revocation checking will fail. If revocation checking fails that application will fail to use the certificate. Depending on how certificates are used your environment this failure can have significant consequences. For example if you were using Smart Cards to logon to the domain and the CRL could not be accessed or is expired, no one would be able to logon with their Smart Card.
As mentioned previously the CDP repositories can either be an LDAP or HTTP location.
LDAP
Advantages:
• The advantage to using LDAP as a repository is that the LDAP repository is Active Directory. And since the CDP location in Active Directory is stored in the Configuration Partition of Active Directory it is replicated to all domain controllers in the forest making it highly available.
• Another advantage is that since Windows Clients are site aware they can query a local DC to download the CRL.
Disadvantages:
• Non-windows clients may not have permission to access LDAP
• Not firewall friendly
• Security concerns with making LDAP (AD) available via insecure networks such as a DMZ or Internet
• Security concerns with internal name space being revealed through the CDP Extension
• Some additional overhead in the protocol versus HTTP
HTTP
Advantages:
• HTTP repository is typically configured to not require authentication. Therefore accessible by all clients.
• Firewall friendly
• Ability to make it securely accessible in untrusted networks like a DMZ or the Internet
• If configured properly limits exposing internal namespace
• Less protocol overhead then LDAP
Disadvantages:
• Not “site aware” by default. “Site Awareness” can be built in by placing web servers at multiple sites and using a load balancer to redirect to the appropriate web server.
• Not redundant by default, requires multiple web servers and load balancer
You can of course have multiple CDP locations specified in the CDP extension of a certificate. Multiple HTTP repositories are normally preferred as HTTP has several advantaged over LDAP. However, many customers feel more comfortable having at least 1 LDAP location. So many customers will setup one or more HTTP locations and then an LDAP location.
Additional HTTP CDP Considerations
• When determining what HTTP URL you will put in the CDP extension of a certificate there are some important considerations.
• The HTTP URL should be a DNS Name and not a short name.
• The DNS name should not include a server name, but should be an alias such as “certs.contoso.com” or “pki.contoso.com”
• Consider whether certificates issued by a PKI will be used on externally facing devices. If certificates are going to be used on externally facing devices you will need to use a DNS name that is resolvable both on internal and external networks. Also, if certificates are going to be used on externally facing devices that the CDP repository will need to be available both internally and externally.
Below is an example of the CDP extension in a certificate:
CRL Considerations
A Certification Authority has two primary functions. The first is to sign certificates. The second is to sign and publish CRLs. As mentioned earlier if a CRL is expired then revocation checking will fail. If a Certification Authority is down or fails, then obviously it cannot sign CRLs. So, when designing your PKI you have to take into consideration what will happen if the CA fails. Generally, the shorter the time that the CRL is valid the less time you have to recover the CA or perform emergency CRL signing. So, this may lead you to believe that increasing the period of time for which a CRL or Delta CRL is valid will increase the amount of time that you have to recover a CA or perform emergency CRL signing. This is not necessarily true, and depends heavily on how you have configured your CRL publishing. Later on in this article, I will cover how to configure CRL publishing in such a way that gives you adequate time to recover the CA or perform Emergency CRL signing. For now, let’s just say that with proper configuration if we increase the validity period for the CRL that it will give us time to recover.
There is, however, a downside to increasing the validity period for a CRL. CRLs are cached by the client. So, let’s say you have a CRL that is valid for a period of 6 days. A client will cache that CRL for 6 Days and will not try to download another CRL until that CRL expires. So, that means that if you revoke certificates, clients may not discover those revocations for up to 6 days. There is some configuration steps you can do to minimize this time, and we will discuss this shortly.
Another consideration is Delta CRLs. Delta CRLs exist primarily due to the fact that Base CRLs can get relatively large over time. As the size of the CRL increases it takes more time to download. This can effect performance. In organizations with very large CRLs, you can also reach time-out thresholds that will cause revocation checking to fail. Therefore Delta CRLs, allow you to download the large CRL less frequently and the Delta more frequently. Overall this increases performance, however, it still does not address the time-out issue when downloading the Base CRL. Also, since Delta CRLs are published more frequently, they decrease the amount of time you have to recover a CA in case of failure and reduce the time before you would have to perform Emergency CRL signing. Also, from a troubleshooting perspective Delta CRLs add some additional complexity. When Delta CRLs are used a client must first download or retrieve the Base CRL. The client will then read the Freshest CRL extension in a certificate to locate the Delta CRL. The client must then in turn download the Delta CRL. The client then has to search for the serial number of the certificate they are performing validation on, in both the Base CRL and Delta CRL. For the reasons mentioned above, I am not a big fan of Delta CRLs. Also, to be honest most organizations don’t revoke certificates very often which really minimize the need for using Delta CRLs.
CRL Publishing
So, how do we maximize the amount of time we have for recovery, and at the same time increase the “freshness” of the CRL? We can do this with the use of Overlap Periods.
So, let’s say we want to implement this solution that maximizes recovery time and increases CRL freshness. The first consideration is Delta CRLs. Since Delta CRLs in my view are not necessary in most instances, we will first get rid of Delta CRLs. So, now that gives us just Base CRLs to work with. Let us take our Base CRL and make it valid for a period of 3 days. So, at first you would think great, now I have 3 days to recover the CA if the CA fails since the CRL is valid for 3 days. Well this is not true. If the validity period of the CRL and the publishing interval coincide, then you could have as little time as 1 second depending on when the CA failed. The illustration below exemplifies this scenario. The problem is without changing the default configuration the Next Update and Next Publish fields will be very close together, providing very little time for recovery.
Introducing CRL Overlap Period
As mentioned there is some additional configuration that can be performed that can optimize your CRL publishing intervals so that you have adequate time to perform Emergency CRL Signing or to recover your CA. What will need to be configured is the CRL Overlap Period. In order to configure the CRL Overlap Period both the CRLOverlapUnits and CRLOverlapPeriod registry settings need to be configured.
So, in my previous example my CRL had a validity period of 3 days. What I can do now is add a CRL Overlap Period of 3 days. With this configuration, my CRL will be valid for a period of 6 Days. However, at 3 days a new CRL will be published as well. This is illustrated in the graphic below:
In the example illustrated in the graphic above, CRL 1 will be valid for a period of 6 days. CRL 2 will be published at Day 3. So, if my CA fails between Day 1 and Day 3, I would still have 3 Days (Day 3 through Day 6) to perform Emergency CRL signing or to recover my CA in event of failure. If my CA fails between Day 3 and Day 6, there is a new CRL (CRL 2) that is valid through Day 9. So, in short if my CA fails between Day 3 and Day 6, I still have at least 3 days to perform Emergency CRL Signing or to recovery my CA, before revocation checking starts to fail. And the reason that I have the 3 days is the CRL Overlap Period extended out my CRL for 3 days and staggered the Next Publish and Next Update times by 3 days.
CRL Pre-fetching
CRL Pre-fetching is a feature first available in Windows Vista. CRL Pre-fetching downloads CRLs before they are needed for revocation checking. This allows the client to check revocation against locally downloaded CRLs instead of having to download a CRL during the Certificate Validation and Certificate Revocation process. In other words this feature can speed up revocation checking. Pre-fetching does key off the Next Publish extension. So, when you configure the CRL Overlap Period you are also giving clients a chance to Pre-fetch the CRL. Additional information on CRL Pre-fetching is available here: https://technet.microsoft.com/en-us/library/ee619723(v=WS.10).aspx.
Conclusion
There are a number of factors that come into play when designing a scalable and highly available revocation solution for your PKI. These include determining your CDP locations and properly configuring CRL publishing. Careful planning should take place when designing and implementing a PKI, with special emphasis on how revocation is configured.
Comments
- Anonymous
December 27, 2013
Pingback from How to set your SLA for Certificate Authority? | Ammar Hasayen - Blog