The SSL/TLS certificate revocation system (CRL and OCSP) is broken. This is a fact known for a long time by the whole certificate industry.
Long-lived certificates that have issues (eg. a certificate that was fraudulently issued), hang around on the Internet for extended periods (currently up to 3 years) potentially causing security and authenticity issues.
revocation
Certificate Revocation (CRL) and the subsequent OCSP were the systems originally designed to take care of issues like this. These are basically blacklists against which a browser can check for certificates that have been revoked and should no longer be trusted. In CRL’s case, the lists are periodically downloaded to the browser, and with OCSP, the browser will go out to the list to do the check (so more lightweight and current than CRL).
The revocation lists are supposed to be maintained by the respective CAs that issue certificates. (A CA or Certificate Authority, is a company that has been authorised informally to issue certificates). So CA no.1 would keep a revocation list for all the certificates they have revoked, CA no.2 would keep a similar for their revoked certificates, and so on for every other CA.
There are 3 main issues with this system:
- both CRL and OCSP introduce latency into the connection request
- unreliable CA infrastructure was never designed for this purpose – if an OCSP server becomes unavailable, it can stall internet browsing
- the browser now leaks websites that are being visited, to the CA (privacy issues)
If there is an issue with the certificate check, browsers tend to soft-fail and assume the certificate is valid, effectively circumventing the entire system.
There are 2 main approaches to solving the issue of revoked certificates:
- implement a technical solution
- reduce the time that bad certificates are in the system
Let’s look at the 2nd option first as that is the focus of this article.
certificate lifetime
The CA/B Forum is an informal group made up of Certificate Authorities (CAs), the companies that issue TLS certificates used to support HTTPS traffic, and browser makers.
There have been a number of attempts over the years to reduce the lifetime of certificates as they apply to websites. Primarily by Apple (and some of the other browser makers). As a member of the CA/B Forum, and having a fair chunk of the market (around 17% currently) due to Safari, they have an important say in the matter. Most CAs have been hesitant to move to short-lived certificates for a number of reasons including the fact that IT teams already struggle with the complex process of generating or renewing TLS certificates.
And so in February 2020 at a CA/B meeting, Apple took the unilateral step of accepting a maximum certificate lifespan of 398 days in Safari, as of the 1st of September 2020. This move effectively then forces the entire CA industry, including the other browser makers, to conform to the same stipulation. To be clear, certificates with longer lifetimes (up to 27 months currently) issued before the 1st of September 2020, will still be accepted for their entire validity period. This change only affects certificates issued from this date.
The issue has been decided, and CAs are nowhere near satisfied as to how the entire process played out. In a May 2020 meeting of the CA/B Forum, some CAs provided public responses to Apple's decision, and many didn't have a positive tone.
Notwithstanding the above grumpiness from the CA industry, they have already started putting plans in place to support certificate users – an example is SSL.com who is offering 5 year bundles where they will issue free replacement certificates on expiration and re-validation of site ownership.
websites and end-users
So how does this effect those that are using TLS certificates?
The main difference is that public website operators will now need to renew their certificates at shorter intervals, the maximum being 398 days.
For end-users, there may be an increase of certificate errors in their browsers, especially where website owners have not applied the new limitation, and continue to run certificates with longer validity periods.
This also means more work for IT teams who already struggle with the scheduling and renewal of TLS certificates, so it’s vitally important certificate engineers maintain a solid change control system with scheduling for their certificate renewals.
Digicert maintains a very good Best Practices Guide to TLS Certificate Management that can guide certificate engineers.
technical solutions
Those interested in technical solutions to certificate revocation can continue below.
We’ve already discussed CRL and OCSP briefly above, and why they are not useful for the modern day internet. So what other options do we have?
OCSP Stapling
OSCP Stapling moves the querying of the OCSP server from the client to the https server. The https server periodically polls the OCSP server for revocation status of its own certificate(s), and sends an OCSP response along with the certificate (staples) to the client during the TLS handshake in aServerCertificateStatus message.
OCSP responses are short-lived (around a week) and are signed by the CA, so clients can trust them.
The biggest issue with OCSP Stapling is that it is not mandatory and it’s up to the website operators to implement this function. As a result, and because of the added configuration complexity on the server side, this option is seldom used. Web server implementations of OCSP Stapling also have issues …
CRLset and OneCRL
Browser makers Google (Chrome) and Mozilla (Firefox) have come up with their own browser-based solutions.
In CRLset’s case, Chrome compiles a list of revoked certificates by regularly crawling CRLs from major CAs around the world, and embedding this list in Chrome. Note that Chrome does not use CRL or OCSP at all!
Firefox has an analogue in OneCRL however it also makes use of OCSP.
must-staple
Must-staple is simply a flag in the certificate, that puts a mandatory requirement on OSCP stapling presence and instructs the browser that the certificate must be served with a valid OCSP response or the browser should hard fail on the connection. This flag is set when CA generates certificate for you.
So you need to have already configured your web server to implement OCSP Stapling before generating a certificate that will use must-staple.
If you were to turn of stapling in the web server, then the browser should block the connection with a certificate error. Note as well that because Chrome does not support stapling, must-staple will not work at all for Chrome users, and Chrome will simply allow the site.
http public key pinning
HPKP is similar to OCSP Stapling however instead of a certificate in response, it sends a series of hashes of public keys which must appear in the certificate chain of future connections to the same domain name.
To combat the risk of compromised certificates, the HTTPS web server serves a list of “pinned” public key hashes valid for a given time; on subsequent connections, during that validity time, clients expect the server to use one or more of those public keys in its certificate chain. If it does not, an error message is shown, which cannot be (easily) bypassed by the user.
So HPKP pins hashes and not certificates (as is the case with OCSP Stapling.
Because of the complexity in implementing HPKP (as is the same with OCSP Stapling), it has been deprecated in favour of Expect-CT.
Expect-CT
Certificate Transparency (CT) is an Internet security standard and open source framework for monitoring and auditing digital certificates. The standard creates a system of public logs that looks to eventually record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates.
As mentioned above, one of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked by the browser vendors. Certificate Transparency would help by making it impossible for a certificate to be issued for a domain without the domain owner knowing.
Certificate Transparency depends on verifiable Certificate Transparency logs. To be seen as behaving correctly, a log must:
- Verify that each submitted certificate or precertificate has a valid signature chain leading back to a trusted root certificate authority certificate.
- Refuse to publish certificates without this valid signature chain.
- Store the entire verification chain from the newly accepted certificate back to the root certificate.
- Present this chain for auditing upon request.
A log may accept certificates that are not yet fully valid and certificates that have expired.
So Expect-CT is a combination of certificates being included in a log, and those logs being implemented in browsers.
Chrome has required all certificates issued since April 2018 to implement CT.
conclusion
As you can see, there is a hodgepodge of solutions available to the certificate revocation issue, many of them with issues in implementation and lack of cross-browser/server support.
Expect-CT seems to be the best option right now but needs more support from other players in the industry, which will take time. Until then, short-lived certificates and one or more of the above the solutions is the best we can do.
Which leaves the possibility of fraudulent certificates still in circulation. And that is not good for anyone.
some more (lite) reading
Revocation is broken — https://scotthelme.co.uk/revocation-is-broken/
The current state of certificate revocation (CRLs, OCSP and OCSP Stapling) — https://www.maikel.pro/blog/current-state-certificate-revocation-crls-ocsp/
HTTPS Certificate Revocation is broken, and it’s time for some new tools | Ars Technica — https://arstechnica.com/information-technology/2017/07/https-certificate-revocation-is-broken-and-its-time-for-some-new-tools/
OCSP Must-Staple — https://scotthelme.co.uk/ocsp-must-staple/
The Problem with OCSP Stapling and Must Staple and why Certificate Revocation is still broken — Hanno’s blog — https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html
ImperialViolet — Revocation checking and Chrome’s CRL — https://www.imperialviolet.org/2012/02/05/crlsets.html
Google Chrome will no longer check for revoked SSL certificates online | Computerworld — https://www.computerworld.com/article/2501274/desktop-apps/google-chrome-will-no-longer-check-for-revoked-ssl-certificates-online.html
Damn it, nginx! More bugs, this time with SSL OCSP stapling. — https://blog.crashed.org/nginx-stapling-busted/