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


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.


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.


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.


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.


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


  1. Avatar Uwe Gradenegger on September 26, 2020 at 2:26 am

    There is even the possibility to force several hosts (e.g. Domain Controllers processing Smartcard Logons) to completely ignore the OCSP/CDP Settings in actual certificates (as these would be under control of the attacker in case of a CA compromise) and always use a specified Online responder. In combination with the deterministic good and OCSP auditing configured, you’d get a complete audit trail of certificates processed on a DC – and logon will fail and be logged both on the DC and OCSP if someone tries to log on with an “unknown” (that means, porribly fraudulent) certificate. See here (translation required): In this scenario, the magic number seems to get ignored as well and OCSP is always used. Kind regards.

    • ThePKIGuy ThePKIGuy on September 27, 2020 at 1:13 pm

      Uwe, I absolutely agree – the ability to use deterministic responses to detect fraudulent certificates is compelling! I do however put a caveot on your statement that using the GPO setting to defines an OCSP URL would change this behavior of the magic number. The GPO you speak of allows you to configure a GPO recipient to reference an OCSP Responder even though it’s not in the AIA extension of an issued certificate. This is a great way to quickly add OCSP to an environment without reissuing everything right away to include the OCSP URL. When defined, Windows will use any GPO based URL for OCSP before the AIA extension. In short, the selection goes GPO OCSP, AIA OCSP, CRL. I do not expect this would specifically change the Magic Number setting. From your statement you said “in this scenario, the magic number seems to get ignored.

      Also, in your article (translated) you say:

      To force computers to use an online responder and to ignore the revocation information entered in the certificate, a group policy can be used.

      This contradicts specific details from the product team. If you look at and refer to the Certificate Validation section it calls it out as:

      The URLs for OCSP and CDP are built in the following order:
      OCSP URLs from Group Policy
      OCSP URLs from the authority information access extension
      CRL URLs from the CDP extension

      When you wrote the article and tested out the GPO, did you use Wireshark or another method to ensure that the magic number was ignored? I’m curious if you are missing a data point.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.