OCSP Service Has Reached End of Life(letsencrypt.org)
letsencrypt.org
OCSP Service Has Reached End of Life
https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life
101 comments
The problem with requiring OCSP stapling is that it's not practically enforceable without breakage.
The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. At present, approximately no Web servers do OCSP stapling, so any browser which requires it will just not work. In the past, when browsers want to make changes like this, they have had to give years of warning and then they can only actually make the change once nearly the entire ecosystem has switched and so you have minimal breakage. This is a huge effort an only worth doing when you have a real problem.
As a reference point, it took something like 7 years to disable SHA-1 in browsers [0], and that was an easier problem because (1) CAs were already transitioning (2) it didn't require any change to the servers, unlike OCSP stapling which requires them to regularly fetch OCSP responses [1] and (3) there was a clear security reason to make the change. By contrast, with Firefox's introduction of CRLite, all the major browsers now have some central revocation system, which works today as opposed to years from now and doesn't require any change to the servers.
[0] https://security.googleblog.com/2014/09/gradually-sunsetting... [1] As an aside it's not clear that OCSP stapling is better than short-lived certs.
The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. At present, approximately no Web servers do OCSP stapling, so any browser which requires it will just not work. In the past, when browsers want to make changes like this, they have had to give years of warning and then they can only actually make the change once nearly the entire ecosystem has switched and so you have minimal breakage. This is a huge effort an only worth doing when you have a real problem.
As a reference point, it took something like 7 years to disable SHA-1 in browsers [0], and that was an easier problem because (1) CAs were already transitioning (2) it didn't require any change to the servers, unlike OCSP stapling which requires them to regularly fetch OCSP responses [1] and (3) there was a clear security reason to make the change. By contrast, with Firefox's introduction of CRLite, all the major browsers now have some central revocation system, which works today as opposed to years from now and doesn't require any change to the servers.
[0] https://security.googleblog.com/2014/09/gradually-sunsetting... [1] As an aside it's not clear that OCSP stapling is better than short-lived certs.
I think you are correct. There were similar issues with Firefox rolling out SameSite=Lax by default, and I think those plans are now indefinitely on hold as a result of the breakage it caused. It's a hard problem to solve.
> As an aside it's not clear that OCSP stapling is better than short-lived certs.
I agree this should be the end goal, really.
> As an aside it's not clear that OCSP stapling is better than short-lived certs.
I agree this should be the end goal, really.
Oh wow. I thought SameSite=Lax by default was a done deal. It shows how much I’ve been following in the past few years.
> The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem.
Absolutely, this is important.
But I don't understand why this should have any effect on OCSP-stapling vs. CRL.
As you note, "approximately no Web servers do OCSP stapling, so any browser which requires it will just not work." But browsers also cannot rely on CRLs being 100% available and up-to-date.
Enforcing OCSP stapling and enforcing a check against an up-to-date CRL would both require this kind of incremental or iterative deployment.
> As an aside it's not clear that OCSP stapling is better than short-lived certs.
This is equally applicable to CRL, though.
The current plan for phased reduction of TLS cert lifespan is to stabilize at 47 days in 2029. If reducing cert lifetime achieves the goal of reducing the value of compromised certs, then any mechanism for revoking/invalidating certificates will be reduced in value.
Absolutely, this is important.
But I don't understand why this should have any effect on OCSP-stapling vs. CRL.
As you note, "approximately no Web servers do OCSP stapling, so any browser which requires it will just not work." But browsers also cannot rely on CRLs being 100% available and up-to-date.
Enforcing OCSP stapling and enforcing a check against an up-to-date CRL would both require this kind of incremental or iterative deployment.
> As an aside it's not clear that OCSP stapling is better than short-lived certs.
This is equally applicable to CRL, though.
The current plan for phased reduction of TLS cert lifespan is to stabilize at 47 days in 2029. If reducing cert lifetime achieves the goal of reducing the value of compromised certs, then any mechanism for revoking/invalidating certificates will be reduced in value.
> Why is that somehow okay, but OCSP not?
I think the argument isn’t that it’s okay, but that one bad thing doesn’t mean we should do two bad things. Just because my DNS provider can see my domain requests doesn’t mean I also want arbitrary CAs on the Internet to also see them.
I think the argument isn’t that it’s okay, but that one bad thing doesn’t mean we should do two bad things. Just because my DNS provider can see my domain requests doesn’t mean I also want arbitrary CAs on the Internet to also see them.
I never understood why they didn’t tried to push OSCP into DNS.
You have to trust the DNS server more than you trust the server you are reaching out to as the DNS server can direct you anywhere as well as see everything you are trying to access anyhow.
You have to trust the DNS server more than you trust the server you are reaching out to as the DNS server can direct you anywhere as well as see everything you are trying to access anyhow.
TLS is to protect you from malicious actors somewhere along your connection path. DNS can't help you.
Just imagine you succeeded in inventing a perfectly secure DNS server. Great, we know this IP address we just got back is the correct one for the server.
Ok, then I go to make a connection to that IP address, but someone on hop 3 of my connection is malicious, and instead of connecting me to the IP, just sends back a response pretending to be from that IP. How would I discover this? TLS would protect me from this, perfectly secure DNS won't.
Just imagine you succeeded in inventing a perfectly secure DNS server. Great, we know this IP address we just got back is the correct one for the server.
Ok, then I go to make a connection to that IP address, but someone on hop 3 of my connection is malicious, and instead of connecting me to the IP, just sends back a response pretending to be from that IP. How would I discover this? TLS would protect me from this, perfectly secure DNS won't.
If you had a perfectly secure DNS service, you could just stick the certificate fingerprint in DNS and be done. No need for trust stores, CAs, trust chains, OSCP/CRLs...
How would you revoke a certificate? If you are running a malicious DNS server, couldn't you just refuse the update and keep servicing the prior results?
If the DNS service is "perfectly secure", we're assuming MITM attacks are impossible. You wouldn't need to revoke anything, you just update the fingerprint in the record.
Why would DNS being perfectly secure make MITM attacks impossible? It might be impossible to hijack DNS, but after DNS resolution happens, then the actual connection via IP address has to happen.
If you are saying every packet sent is secure, then it would have nothing to do with DNS?
If you are saying every packet sent is secure, then it would have nothing to do with DNS?
You could store the certificate hashes in DNS (i.e., use DANE instead of the CA PKI) and so a MITM on the actual connection wouldn't succeed.
Right, but what if the certificate is compromised? How would your revoke it?
If the DNS entries for the certificates have a very short TTLs (i.e., 2 minutes) then you wouldn't need explicit revocation infrastructure. It would probably take more than 2 minutes for CRLs or OSCP changes to propagate anyway.
(I'm not necessarily in favour of this, I just don't see the revocation part as being the main issue.)
(I'm not necessarily in favour of this, I just don't see the revocation part as being the main issue.)
If we are going to solve the revocation issue by just having very short lived certificates, then we don’t need to involve DNS at all. Just have short lived certs.
Indeed, this already exists with record types such as TLSA, SMIMEA, and CERT.
However I don't believe I've ever seen it used "in the wild".
However I don't believe I've ever seen it used "in the wild".
Because one of the main things TLS is intended to defend against is malicious / MITM'd DNS servers? If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant...
Does it, though?
In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS.
Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either.
If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS.
Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either.
If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
> In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS.
Yes, except for CT, which can help detect this kind of attack.
> Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either.
I'm not sure quite what you have in mind here, but there is more to the issue than correct DNS resolution. In many cases, the attacker controls the network between you and the server, and can intercept your connection regardless of whether DNS resolved correctly.
> If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.
Yes, except for CT, which can help detect this kind of attack.
> Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either.
I'm not sure quite what you have in mind here, but there is more to the issue than correct DNS resolution. In many cases, the attacker controls the network between you and the server, and can intercept your connection regardless of whether DNS resolved correctly.
> If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.
> This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.
Well, DANE exists and provides an obvious transition path, as brittle of an approach it is. Ideally you would be able to create your own intermediates (with name constraints) and pin the intermediate rather than the lead certificate, but PKI isn't set up for that.
From my understanding, the biggest issue with DNSSEC is that it's just a return to the single signing authority model that TLS used in the 90s. Isn't it also just Verisign again? (At least for .com.)
Well, DANE exists and provides an obvious transition path, as brittle of an approach it is. Ideally you would be able to create your own intermediates (with name constraints) and pin the intermediate rather than the lead certificate, but PKI isn't set up for that.
From my understanding, the biggest issue with DNSSEC is that it's just a return to the single signing authority model that TLS used in the 90s. Isn't it also just Verisign again? (At least for .com.)
That is a problem, but beyond the philosophical problem (which I care a lot about) and the cryptographic problems (which I care a lot about), most of the reason DANE isn't taken seriously (is, in fact, a dead letter with the browsers, meaning it's a dead letter everywhere) are practical issues deploying it. Stipulate, very unrealistically, that a sizable portion of the most popular zones were signed (the opposite is true). Then:
You still have the problem where a substantial cohort of Internet users can't resolve DANE records. They're on Internet paths that include middleboxes that freak out when they see anything but simple UDP DNS records. You can't define that problem away.
So now you need to design a fallback for those users. Whatever that fallback is, you have to assume attackers will target it; that's the whole point of the exercise. What you end up with a system that decays to the natural security level of the WebPKI. From a threat model perspective, what you've really done is just add another CA to the system. Not better!
DANE advocates tried for years to work around this problem by factoring out the DNS from DANE, and stapling DANE records to TLS handshakes. Then someone asked, "well, what happens when attackers just strip that out of the handshake". These records are used to authenticate the handshake, so you can't just set "the handshake will be secure" as an axiom. Nobody had a good answer! The DANE advocates were left saying we'd be doing something like HPKP, where browsers would remember DANE-stapled hosts after first contact. The browser vendors said "lol no".
That's where things stand. The stapling thing was so bad that Geoff Huston --- a DNS/DNSSEC éminence grise --- wrote a long blog post asking (and more or less conceding) that it was time to stick a fork in the whole thing.
You still have the problem where a substantial cohort of Internet users can't resolve DANE records. They're on Internet paths that include middleboxes that freak out when they see anything but simple UDP DNS records. You can't define that problem away.
So now you need to design a fallback for those users. Whatever that fallback is, you have to assume attackers will target it; that's the whole point of the exercise. What you end up with a system that decays to the natural security level of the WebPKI. From a threat model perspective, what you've really done is just add another CA to the system. Not better!
DANE advocates tried for years to work around this problem by factoring out the DNS from DANE, and stapling DANE records to TLS handshakes. Then someone asked, "well, what happens when attackers just strip that out of the handshake". These records are used to authenticate the handshake, so you can't just set "the handshake will be secure" as an axiom. Nobody had a good answer! The DANE advocates were left saying we'd be doing something like HPKP, where browsers would remember DANE-stapled hosts after first contact. The browser vendors said "lol no".
That's where things stand. The stapling thing was so bad that Geoff Huston --- a DNS/DNSSEC éminence grise --- wrote a long blog post asking (and more or less conceding) that it was time to stick a fork in the whole thing.
To be clear, I'm not at all a DANE advocate -- I agree with you wholeheartedly. Even if all of those problems with DANE were magically resolved it would still be an administrative nightmare to manage (especially in a world with short certificate lifetimes) and so would likely still have very little adoption anyway.
Sorry, didn't mean to imply otherwise, I genuinely just think it's a fun story to talk about, which is why it's hard to get me to shut up about it.
This isn't true. Even if the DNS server is secure, the network between you and the server cannot be trusted.
If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. I'm saying there would be no need for CAs -- you could just trust self-signed certs. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.
> then the entirety of TLS PKI would be entirely redundant...
Don't think I agree with this. TLS is important against MITM scenarios - integrity, privacy. You don't need DNS for this to be abused but a man in the middle - whether that is some open wifi, ISP or tapped into your network any other way.
Don't think I agree with this. TLS is important against MITM scenarios - integrity, privacy. You don't need DNS for this to be abused but a man in the middle - whether that is some open wifi, ISP or tapped into your network any other way.
If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. There would be no need for the authentication provided by CAs, but you would still want to use TLS. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.
TLS != the current TLS PKI, which is the distinction GP is making I think.
Although tbh I think that just moves the problem somewhere else (which is perfectly fine if you don’t like the current PKI).
Although tbh I think that just moves the problem somewhere else (which is perfectly fine if you don’t like the current PKI).
> If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant
I’m not sure I understand the logic here. To me TLS PKI and DNS are somewhat orthogonal.
I’m not sure I understand the logic here. To me TLS PKI and DNS are somewhat orthogonal.
How would that work in the current reality of the DNS? The current reality is that it’s unauthenticated and indeterminately forwarded/cached, neither of which screams success for timely, authentic OCSP responses.
Sounds like something DANE could be used for.
OCSP stapling, when done correctly with fallback issuance, is just a worse solution than short-lived certificates. OCSP lifetimes are 10 days. I wrote about this some here [1].
[1]: https://dadrian.io/blog/posts/revocation-aint-no-thang/
[1]: https://dadrian.io/blog/posts/revocation-aint-no-thang/
It's funny that putting some random records in DNS is enough to have enough "ownership" to make a cert for one but we can't use same method for publishing revoking
The entire existence of CAs is a pointless and mystical venture to ensure centralized control of the Internet that, since now entirely domain-validated, provides absolutely no security benefits over DNS. If your domain register/name server provider is compromised, CAs are already a lost cause.
This isn't correct, because your domain name server may be insecure even while the one used by the CA is secure. Moreover, CT helps detect misissuance but does not detect incorrect responses by your resolver.
If someone can log into your domain registrar account or your web host, they can issue themselves a complete valid certificate. It won't matter if the CA resolver is secure, because the attacker can successfully validate domain control.
Yes, that's correct. The purpose of the WebPKI and TLS is not to protect against this form of attack but rather to protect against compromise of the network between the client and the server.
but if your domain server is insecure attacker can get a cert for it
The DNS is more centralized than the WebPKI.
Three browser companies on the west coast of the US effectively control all decisionmaking for WebPKI. The entire membership of the CA/B is what, a few dozen? Mostly companies which have no reason to exist except serving math equations for rent.
How many companies now run TLDs? Yeah, .com is centralized, but between ccTLDs, new TLDs, etc., tons. And domain registrars and web hosts which provide DNS services? Thousands. And importantly, hosting companies and DNS providers are trivially easy to change between.
The idea Apple or Google can unilaterally decide what the baseline requirements should be needs to be understood as an existential threat to the Internet.
And again, every single requirement CAs implement is irrelevant if someone can log into your web host. The entire thing is an emperor has no clothes thing.
How many companies now run TLDs? Yeah, .com is centralized, but between ccTLDs, new TLDs, etc., tons. And domain registrars and web hosts which provide DNS services? Thousands. And importantly, hosting companies and DNS providers are trivially easy to change between.
The idea Apple or Google can unilaterally decide what the baseline requirements should be needs to be understood as an existential threat to the Internet.
And again, every single requirement CAs implement is irrelevant if someone can log into your web host. The entire thing is an emperor has no clothes thing.
Incoherent. Browser vendors exert control by dint of controlling the browsers themselves, and are in the picture regardless of the trust system used for TLS. The question is, which is more centralized: the current WebPKI, which you say is also completely dependent on the DNS but involves more companies, or the DNS itself, which is axiomatically fewer companies?
I always love when people bring the ccTLDs into these discussions, as if Google could leave .COM when .COM's utterly unaccountable ownership manipulates the DNS to intercept Google Mail.
I always love when people bring the ccTLDs into these discussions, as if Google could leave .COM when .COM's utterly unaccountable ownership manipulates the DNS to intercept Google Mail.
> when .COM's utterly unaccountable ownership manipulates the DNS to intercept Google Mail.
Why is this more likely to happen than a rogue CA issuing a false certificate?
Also, Google has chosen to trust .com instead of using one of their eleven TLDs that they own for their own exclusive use, or any of the additional 22 TLDs that they also operate.
Why is this more likely to happen than a rogue CA issuing a false certificate?
Also, Google has chosen to trust .com instead of using one of their eleven TLDs that they own for their own exclusive use, or any of the additional 22 TLDs that they also operate.
When a rogue CA issues a bad cert, they get delisted from all major browsers and are effectively destroyed.
That isn’t possible with .com
That isn’t possible with .com
The DNS is federated and hierarchical. A domain name (including top-level domains) is controlled by a single entity. If you do not trust that entity, you cannot trust that domain or top-level domain, or anything beneath that in the tree. But given that you trust the root zone, you can still (potentially) trust other subtrees in the DNS, like other top-level domains.
This is not the case with a CA, however; you are forced to trust all of them, and hope that when fradulent certificates are issued (as has happened several times, IIUC), that they will not affect you.
This is not the case with a CA, however; you are forced to trust all of them, and hope that when fradulent certificates are issued (as has happened several times, IIUC), that they will not affect you.
In fact you don't have to trust any of them, since browser root stores enforce certificate transparency.
But also the issues of segmentation are pretty much a total shift of the goalposts from what we were discussing, which is what actually happens when malicious activity occurs. In DNS, your only option is to stop trusting that slice of the tree and for every site operator to lift and shift to another TLD, inclusive of teaching all their users to use the new site. In WebPKI, the CA gets delisted for new certificate issuance and site operators get new certificates before the current ones expire. One of those is insane, and the other has successfully happened several times in response to bad/rogue CAs.
But also the issues of segmentation are pretty much a total shift of the goalposts from what we were discussing, which is what actually happens when malicious activity occurs. In DNS, your only option is to stop trusting that slice of the tree and for every site operator to lift and shift to another TLD, inclusive of teaching all their users to use the new site. In WebPKI, the CA gets delisted for new certificate issuance and site operators get new certificates before the current ones expire. One of those is insane, and the other has successfully happened several times in response to bad/rogue CAs.
DNS isn’t centralized; it’s federated. I mean, just because there’s an ISO and a UN does not mean there is a single world government.
(Repost: <https://news.ycombinator.com/item?id=38695674>)
(Repost: <https://news.ycombinator.com/item?id=38695674>)
The distinction you're trying to draw here isn't relevant to the argument on the thread. "Centralization" is the other commenter's metric of concern, not mine.
No. You can host your own DNS. It's easy and practically free.
Your TLD registry operator still technically remains fully in control of your records. I am actually surprised more of them have not abused their power so far.
Most TLD operators are non-profit foundations set up by nerds in the early days of the internet, well before the lawyers, politicians, and MBAs could get their hands on it.
If you want to see what happens otherwise, just look at the gTLD landscape. Still, genuine power abuse is relatively rare, because to a large extent they are selling trust. If you start randomly taking down domains, nobody will ever risk registering a domain with you again.
If you want to see what happens otherwise, just look at the gTLD landscape. Still, genuine power abuse is relatively rare, because to a large extent they are selling trust. If you start randomly taking down domains, nobody will ever risk registering a domain with you again.
The most important TLDs are decidedly not non-profit foundations run by the nerds who set them up in the 1980s, and governments routinely manipulate the DNS for policy reasons.
You don't actually need a domain with an ""important"" TLD. True story.
What TLDs are today operated by non-profits? Looking at the list, I see a mix of commercial entities running them for profit and governments.
You don't actually need a non-profit TLD either.
Having a healthy competitive market for DNS services is good enough.
Having a healthy competitive market for DNS services is good enough.
Really? If .com or .io or some other popular TLD starts acting maliciously, what’s the route to handling that problem?
"And let's not pretend users aren't already sending all the hostnames they are visiting to their selected DNS server. Why is that somehow okay, but OCSP not?"
Running your own DNS server is rather easier than messing with OCSP. You do at least have a choice, even if it is bloody complicated.
SSL certs (and I refuse to call them TLS) will soon have a required lifetime of forty something days. OCSP and the rest becomes moot.
Running your own DNS server is rather easier than messing with OCSP. You do at least have a choice, even if it is bloody complicated.
SSL certs (and I refuse to call them TLS) will soon have a required lifetime of forty something days. OCSP and the rest becomes moot.
You still are reaching out to authoritative servers for that domain so someone else other than the destination knows what you are looking for.
The 47 day life expectancy isn’t going to come until 2029 and it might get pushed.
Also 47 days is still too long if certificates are compromised.
The 47 day life expectancy isn’t going to come until 2029 and it might get pushed.
Also 47 days is still too long if certificates are compromised.
The authoritative servers for a domain are likely to be operated by the same entity as the domain itself.
You can request 6-day certificates from Let's Encrypt. There's a clear path towards 24-hour certificates. This will be pretty much equivalent to the current status quo with the OCSP stapling.
> I still don't think CRLs are remotely a perfect solution (nor do I think OCSP was unfixable)
> The privacy concerns could have been solved through adoption of Must-Staple
Agreed. I haven't followed every bit of the play-by-play here, but OCSP (multi-)stapling appeared to me to be a good solution to both the end-user privacy concerns and to the performance concerns.
> The privacy concerns could have been solved through adoption of Must-Staple
Agreed. I haven't followed every bit of the play-by-play here, but OCSP (multi-)stapling appeared to me to be a good solution to both the end-user privacy concerns and to the performance concerns.
This will not impact Chrome in any meaningful way because - in typical Google fashion - they invented their own bullshit called CRLSets that does not perform OCSP or CRL checks in any way, rather periodically downloads a preened blacklist from Google which it then uses to screen certificates.
Most people don't realize this.
It's quite insane given that Chrome will by default not check CRLs *at all* for internal, enterprise CAs.
Most people don't realize this.
It's quite insane given that Chrome will by default not check CRLs *at all* for internal, enterprise CAs.
What in the Sam Hill? This is a new one on me. Does anyone have any reading for their logic of why?
They can be enabled by policy. An enterprise will usually have a policy installing it's custom ca
https://www.chromium.org/Home/chromium-security/crlsets/
See here for some of the why: https://www.imperialviolet.org/2012/02/05/crlsets.html
https://www.chromium.org/Home/chromium-security/crlsets/
See here for some of the why: https://www.imperialviolet.org/2012/02/05/crlsets.html
I vaguely remember there was similar reasoning as why golang doesn't support them, they're "antiquated and useless".
I hit that road-block a lot when trying to do mTLS in the browser, that and dropping support for the [KeyGen](https://www.w3docs.com/learn-html/html-keygen-tag.html) tag.
I hit that road-block a lot when trying to do mTLS in the browser, that and dropping support for the [KeyGen](https://www.w3docs.com/learn-html/html-keygen-tag.html) tag.
Good. OCSP sucks. It's a fail-open design, and the fact that it exists means that a lot of security people have developed an auto-response for certificate lifetime problems, even in domains where OCSP is totally infeasible, like secure boot.
I can patiently explain why a ROM cannot query a fucking remote service for a certificate's validity, but it's a lot easier to just say "Look OCSP sucks, and Let's Encrypt stopped supporting it", especially to the types of people I argue with about these things.
I can patiently explain why a ROM cannot query a fucking remote service for a certificate's validity, but it's a lot easier to just say "Look OCSP sucks, and Let's Encrypt stopped supporting it", especially to the types of people I argue with about these things.
Ocsp has always represented a terrible design. If clients require it, then it becomes just a override on the not after date included in the certificate, that requires online access to the cert server. If it is not required, then it is useless, because blocking the ocsp responses is well within the capabilities of any man in the middle attack, and makes the servers themselves DDOS attack targets.
The alternative to the privacy nightmare is ocsp stapling, which has the first problem once again - it adds complexity to the protocol just to add an override of the not after attribute, when the not after attribute could be updated just as easily with the original protocol, reissuing the certificate. It was a Band-Aid on the highly manual process of certain issuance that once dominated the space.
Good riddance to ocsp, I for one will not miss it.
The alternative to the privacy nightmare is ocsp stapling, which has the first problem once again - it adds complexity to the protocol just to add an override of the not after attribute, when the not after attribute could be updated just as easily with the original protocol, reissuing the certificate. It was a Band-Aid on the highly manual process of certain issuance that once dominated the space.
Good riddance to ocsp, I for one will not miss it.
Shortening the certificate lifespan to e.g. 24h would have a number of downsides:
Certificate volume in Certificate Transparency would increase a lot, adding load to the logs and making it even harder to follow CT.
Issues with domain validation would turn into an outage after 24h rather than when the cert expires, which could be a benefit in some cases (invalidating old certs quickly if a domain changes owner or is recovered after a compromise/hijack).
OCSP is simpler and has fewer dependencies than issuance (no need to do multi-perspective domain validation and the interaction with CT), so keeping it highly available should be easier than keeping issuance highly available.
With stapling (which would have been required for privacy) often poorly implemented and rarely deployed and browsers not requiring OCSP, this was a sensible decision.
Certificate volume in Certificate Transparency would increase a lot, adding load to the logs and making it even harder to follow CT.
Issues with domain validation would turn into an outage after 24h rather than when the cert expires, which could be a benefit in some cases (invalidating old certs quickly if a domain changes owner or is recovered after a compromise/hijack).
OCSP is simpler and has fewer dependencies than issuance (no need to do multi-perspective domain validation and the interaction with CT), so keeping it highly available should be easier than keeping issuance highly available.
With stapling (which would have been required for privacy) often poorly implemented and rarely deployed and browsers not requiring OCSP, this was a sensible decision.
Well, OCSP is dead, so the real argument is over how low certificate lifetimes will be, not whether or not we might make a go of OCSP.
>would increase a lot
You can delete old logs or come up with a way to download the same thing with less disk space. Even if the current architecture does not scale we can always change it.
>even harder to follow CT.
It should be no harder to follow than before.
You can delete old logs or come up with a way to download the same thing with less disk space. Even if the current architecture does not scale we can always change it.
>even harder to follow CT.
It should be no harder to follow than before.
Following CT (without relying on a third party service) right now is a scale problem, and increasing scale by at least another order of magnitude will make it worse.
I was trying to process CT logs locally. I gave up when I realized that I'd be looking at over a week even if I optimized my software to the point that it could process the data at 1 Gbps (and the logs were providing the data at that rate), and that was a while ago.
With the current issuance rate, it's barely feasible to locally scan the CT logs with a lot of patience if you have a 1 Gbps line.
https://letsencrypt.org/2025/08/14/rfc-6962-logs-eol states "The current storage size of a CT log shard is between 7 and 10 terabytes". So that's a day at 1 Gbps for one single log shard of one operator, ignoring overhead.
I was trying to process CT logs locally. I gave up when I realized that I'd be looking at over a week even if I optimized my software to the point that it could process the data at 1 Gbps (and the logs were providing the data at that rate), and that was a while ago.
With the current issuance rate, it's barely feasible to locally scan the CT logs with a lot of patience if you have a 1 Gbps line.
https://letsencrypt.org/2025/08/14/rfc-6962-logs-eol states "The current storage size of a CT log shard is between 7 and 10 terabytes". So that's a day at 1 Gbps for one single log shard of one operator, ignoring overhead.
> even if I optimized my software to the point that it could process the data at 1 Gbps
Are you sure you did the math correctly? We're scanning CT at my work, and we do have scale problems, but the bottleneck is for database inserts. From your link, looks like a shard is 10TB and that's for a year of data
Still insane amount and a scale problem, of course
Are you sure you did the math correctly? We're scanning CT at my work, and we do have scale problems, but the bottleneck is for database inserts. From your link, looks like a shard is 10TB and that's for a year of data
Still insane amount and a scale problem, of course
Well, 10 TB divided by 1 Gbps is ~22 hours, and there are multiple log providers with many shards (my scan was including data from certificates that had expired at that time).
It would still be feasible to build a local database and keep it updated (with way less than 1 Gbps), but initial ingestion would be weeks at 1 Gbps, and I'd need the storage for it.
For most hobbyists not looking to spend a fortune on rented servers/cloud, it's out of reach already.
It would still be feasible to build a local database and keep it updated (with way less than 1 Gbps), but initial ingestion would be weeks at 1 Gbps, and I'd need the storage for it.
For most hobbyists not looking to spend a fortune on rented servers/cloud, it's out of reach already.
Not all use cases need every single log. For example you may just want to have a log of certificates issued for domains that your company owns.
You could extend the format to account for repetition of otherwise identical short ttl certs
OCSP stapling was a good solution in the age of certificates that were valid for 10 years (which was the case for basic HTTPS certificates back in 2011 when OCSP stapling was introduced). In the age of 90 day certificates (to be reduced to a maximum of 47 days in a few years), it's not quite as necessary any more, but I don't think OCSP stapling is that problematic a solution.
Certificates in air-gapped networks are problematic, but that problem can be solved with dedicated CRL-only certificate roots that suffer all of the downsides of CRLs for cases where OCSP stapling isn't available.
Nobody will miss OCSP now that it's dead, but assuming you used stapling I think it was a decent solution to a difficult problem that plagued the web for more than a decade and a half.
Certificates in air-gapped networks are problematic, but that problem can be solved with dedicated CRL-only certificate roots that suffer all of the downsides of CRLs for cases where OCSP stapling isn't available.
Nobody will miss OCSP now that it's dead, but assuming you used stapling I think it was a decent solution to a difficult problem that plagued the web for more than a decade and a half.
But that 47-day lifetime is enforced by the certificate authority, not by the browser, right? So a bad actor can still issue a multi-year certificate for itself, and in the absence of side-channel verification the browser is none the wiser. Or will browsers be instructed to reject long-lived certificates under specific conditions?
Wrong. Enforcement is done by the browser. Yes, a CA's certificate policy may govern how long a certificate they will issue. But should an error occur, and a long-lived cert issued (even maliciously), the browser will reject it.
The browser-CA cartels stay relatively in sync.
You can verify this for yourself by creating and trusting a local CA and try issuing a 5 year certificate. It won't work. You'll have a valid cert, but it won't be trusted by the browser unless the lifetime is below their arbitrary limit. Yet that certificate would continue to be valid for non-browser purposes.
The browser-CA cartels stay relatively in sync.
You can verify this for yourself by creating and trusting a local CA and try issuing a 5 year certificate. It won't work. You'll have a valid cert, but it won't be trusted by the browser unless the lifetime is below their arbitrary limit. Yet that certificate would continue to be valid for non-browser purposes.
I just did this with a 20-year certificate and it worked fine in Chrome and Firefox. That said, my understanding is that the browsers exempt custom roots from these kinds of policies, which are only meant to constrain the behavior of publicly trusted CAs.
Safari enforces a hard limit of just over two years.
> So a bad actor can still issue a multi-year certificate for itself, and in the absence of side-channel verification the browser is none the wiser.
How would a bad actor do that without a certificate authority being involved?
How would a bad actor do that without a certificate authority being involved?
The bad actor would also need to install a root for their custom CA on the end-user device.
the browsers will verify, and every cert will be checked against transparency logs. you won't be able to hide a long lived cert for very long.
> the not after attribute could be updated just as easily with the original protocol, reissuing the certificate.
That's not a viable solution if the server you want to verify is compromised. The point of CRL and OCSP is exactly to ask the authority one higher up, without the entity you want to verify being able to interfere.
In non-TLS uses of X.509 certificates, OCSP is still very much a thing, by the way, as there is no real alternative for longer-lived certificates.
That's not a viable solution if the server you want to verify is compromised. The point of CRL and OCSP is exactly to ask the authority one higher up, without the entity you want to verify being able to interfere.
In non-TLS uses of X.509 certificates, OCSP is still very much a thing, by the way, as there is no real alternative for longer-lived certificates.
In this scenario, where oscp is required and stapled: The CA can simply refuse to reissue the certificate if the host is compromised. It does not matter if it is refusing to issue an ocsp ticket or a new short lived cert.
The use case is to shorten the lifetime of an existing certificate. As long as the server serves the original certificate with the longer lifetime, the browser has no way to tell that it isn’t supposed to be that long anymore, without asking the CA.
Yes, you could restrict certificates to very short lifetimes like 24 hours or less, but that isn’t always practical for non-TLS use cases.
Yes, you could restrict certificates to very short lifetimes like 24 hours or less, but that isn’t always practical for non-TLS use cases.
[deleted]
Does anyone think this causes problems with HSTS? I had a few clients report issues with our site last week... I was unable to see any kind of problem across all browsers and several geographic locations. auth0, using letsencrypt
One odd thing about OSCP is that it requires you to use port 80.
This sometimes collides with enterprise security policies that you should "never use port 80" (always 443).
This sometimes collides with enterprise security policies that you should "never use port 80" (always 443).
Good riddance. That was always a power grab if I ever saw it. They should take it out of browsers too.
So non-browser clients have no feasible way of checking certificate revocation anymore.
Does this mean I should turn "security.OCSP.require" back off in Firefox?
For Let’s Encrypt certificates which no longer contain an OCSP URL, I don’t think it’ll have any effect.
Firefox also already has more effective revocation checking in CRLite: https://blog.mozilla.org/en/firefox/crlite/
Firefox also already has more effective revocation checking in CRLite: https://blog.mozilla.org/en/firefox/crlite/
The advantages of OCSP were that you got a real-time understanding of the status of a certificate and you had no need to download large CRLs which become stale very quickly. If you set security.ocsp.require in the browser appropriately then you didn't have any risk of the browser failing open, either. I did that in the browser I was daily-driving for years and can count on one hand the number of times I ran into OCSP responder outages.
The privacy concerns could have been solved through adoption of Must-Staple, and you could then operate the OCSP responders purely for web-servers and folks doing research.
And let's not pretend users aren't already sending all the hostnames they are visiting to their selected DNS server. Why is that somehow okay, but OCSP not?