OCSP Magic Number

The magic number is a value that states when CRLs will be processed over OCSP, specifically it is when the total number of cached OCSP responses from a single OCSP responder URL on behalf of a single certificate authority will stop performing OCSP and start processing CRLs. This will occur if the number of cached OCSP responses meets or exceeds a magic number – by default this is set to 50. An OCSP Responder providing revocation details for multiple CAs will be counted based on the number of cached responses per CA.

Many organizations implement OCSP because of large CRLs or a desire to detect fraudulent certificates with stateful responses – provided by Hotfix 2960124 . The OCSP Magic Number presents a significant security concern to any organization using OCSP as it quietly stops the use of OCSP queries and switches to using CRLs. If you have a large CRL, that could cause timeouts or certificate revocation failures – the very reason you implemented OCSP to begin with. If you are using stateful responses, the switch to CRL checking will cause systems to no longer detect fraudulent certificates.

This setting is particularly nefarious as there is no logging or detectable change to the client. In fact, the only way you would know that the change had occurred is to watch network traffic to see the transfer of the CRL (and related cessation of OCSP queries). This can render the entire OCSP infrastructure as unused (for the most part) as systems switch to CRLs and your OCSP servers look happy and ready to do more work.

There is a reason why Microsoft created the Magic Number – to prevent excess data transfer for OCSP in some scenarios. For example, assume you are using certificates for Wi-Fi or VPN authentication and your CRL is 3 MB in size. An OCSP query is approximately 2 KB, and after validating 20,000 certificates the RADIUS server has transferred and cached approximately 40 MB of OCSP response data versus downloading the 3 MB CRL.

Changing the default Magic Number can be accomplished through a group policy setting or locally in the registry.

Group Policy

Registry:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config registry key.

The registry setting can be done on a non-domain joined computer, this would affect only the machine that has the registry change.

Demonstration

To see how this process works and demonstrate the magic number at play, we configured a test system with a magic number of 5.
Testing steps:

1. Configure our CA to use OCSP and an HTTP based CDP location
2. Issued 6 certificates and exported to a p7b file
3. Changed the magic number to 5 on our test computer
4. Reset and clear all cached revocation information:

certutil –setreg chain\ChainCacheResyncFiletime @now

• Ran a validation lookup of the 6 certificates in the p7b using the script below using CAPI behavior

As you can see in the below Wireshark capture, CA1.crl retrieval appeared after the 5th OCSP request was cached.

When viewing the disk cache in we can see that the CRL only appeared after the 5th OCSP request was cached.

There are several use cases as to why one lookup may be preferred over another.

Network/latency
We already know large CRLs could have an impact on checking status revocation given the time spent downloading – this is one of the primary reasons OCSP came about.

What if your organization needs to validate thousands of certs within the same revocation period? This would drive up bandwidth and latency and so CRLs might prove to be a more efficient process after X amount of OCSP requests.

Security
Depending on the OCSP and CA configuration the OCSP response may give a valid certificate status for a serial number that was never issued by the CA[1]. The CRL alone can not determine if a certificate is valid, only that it has not been revoked. A fraudulent certificate would not be known to the CA and would not be in a revocation list.

Recommendation
Your environment and use cases will dictate how the magic number should be configured. For example, if you wish to always be able to detect fraudulent certificates, then your OCSP number should be sufficiently high the cache threshold is never reached. The value is a REG_DWORD with a maximum value of 4,294,967,295. That is likely to be sufficiently large enough to ensure OCSP is always performed.

Alternatively, for network performance and traffic, you may want to set the magic number to an appropriate value to ensure your OCSP client does not perform too many queries before reverting to CRL. There may be cases where you want CRL lookups only or perhaps never to revert to CRLs. You can use the 2K traffic component and the anticipated number of queries to determine the client’s consumption. Compare that to your CRL size. You can then determine your threshold.

Editor’s note: If you wonder why this is called the Magic Number – that isn’t our term. Additionally, this setting is mentioned in only one Microsoft article – yes, that is right, 1! You can read the full revocation article here. In this article Microsoft describes this behavior as:

In some cases, CryptoAPI may retrieve CRLs before OCSP URLs. This only occurs when one of the following two circumstances exist:

The number of cached OCSP responses for a specific certificate issuer exceeds the magic number defined in Group Policy. This number is 50 by default.

Group Policy is configured to prefer CRLs over OCSP for revocation checking.

[1] RFC 6960 does not mandate this and providing this feature requires MSFT CA and OCSP Responder configuration. Information can be found under the section “The Online Responder service does not return a deterministic GOOD for all certificates not included in the CRL” found on https://www.pkisolutions.com/adcs-hotfixes/.