The Let's Encrypt non-profit certificate authority, governed by the community and providing certificates free of charge to anyone interested, has decided to discontinue support for the OCSP (Online Certificate Status Protocol) used for certificate revocation checking. Instead of the OCSP protocol, it is recommended to use Certificate Revocation Lists (CRL), published by Let's Encrypt starting in 2022. On May 7, 2025, Let's Encrypt will disable the inclusion of OCSP addresses in issued certificates and cease processing requests related to the use of the "OCSP Must Staple" extension. On August 6, 2025, OCSP request handlers will be disabled on the servers.
Privacy concerns are cited as the reason for discontinuing OCSP support. The use of OCSP results in the client system sending a request to the OCSP server of the certificate authority that issued the certificate with each establishment of a secure connection to check the certificate's validity. In response, the server provides information on whether the specified certificate is trustworthy. The problem is that the certificate authority receives information about when and which websites the user visits, tied to their IP address, which could be seen as a leak of confidential data. Additionally, using OCSP introduces a delay in processing requests, requires the user to have guaranteed network access, and creates a dependency on the uninterrupted operation of OCSP servers.
To address privacy issues when checking certificate revocation, the OCSP Stapling technology was developed, which allows OCSP responses certified by the certificate authority to be transmitted by the servers hosting the sites during the TLS connection negotiation with the client (the transfer of OCSP information is shifted to servers the sites, which frees the client system from making direct requests to the OCSP server of the certificate authority, while the correctness of the responses is ensured by the digital signature of the certificate authority).
In addition to OCSP Stapling, there is an extension added to certificates called 'OCSP Must Staple', which mandates that browsers use OCSP Stapling instead of directly contacting OCSP servers and requires considering the certificate untrustworthy if the serving site server does not return a certified OCSP response. Unfortunately, the 'Must Staple' extension has not gained widespread adoption in browsers, and the OCSP Stapling technology relies on the necessity of explicit support being enabled on the HTTP server side (supported in nginx since 2013).
When using CRL, the verification of certificate revocation is performed on the local system based on lists generated by the certificate authority. The downsides of this approach are the very large size of the downloaded data and the emergence of a temporary gap in the timeliness of the information (for example, in Firefox, data is updated every 6 hours). The size problem has been addressed in browsers through CRL proxying on browser manufacturers' servers — a basic CRL is included in browsers, which is periodically synchronized with the current list during operation (only changed data is transmitted to the client system). To reduce the size of the database with CRL, a probabilistic structure called a 'Bloom filter' is used, allowing the full CRL database to be stored on the client side in a very compact representation. In Firefox, a similar technique is implemented using the CRLite toolkit, while in Chrome — CRLSets.
Source: opennet.ru
