19 ms·

OCSP Service Has Reached End of Life

217 points by pfexec 1y ago

GauntletWizard 1y ago
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.
- deleted 1y ago
  [deleted]
- jeroenhd 1y ago
  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.
  - tremon 1y ago
    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?
    - arccy 1y ago
      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.
    - avianlyric 1y ago
      > 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?
      - syncsynchalt 1y ago
        The bad actor would also need to install a root for their custom CA on the end-user device.
    - sugarpimpdorsey 1y ago
      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.
      - ameliaquining 1y ago
        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.
- layer8 1y ago
  > 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.
  - arccy 1y ago
    actually that's pretty close to where we're going with ever shorter certificate lifetimes...
    - layer8 1y ago
      Only because the browsers are enforcing shorter lifetimes. But you can’t force a premature expiration in case of a server compromise, which is what revocation is for.
  - GauntletWizard 1y ago
    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.
    - layer8 1y ago
      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.
- tgsovlerkhgsel 1y ago
  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.
  - tptacek 1y ago
    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.
  - charcircuit 1y ago
    >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.
    - lokar 1y ago
      You could extend the format to account for repetition of otherwise identical short ttl certs
    - tgsovlerkhgsel 1y ago
      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 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.
lol768 1y ago
The ship has very much sailed now with ballot SC63, and this is the result, but I still don't think CRLs are remotely a perfect solution (nor do I think OCSP was unfixable). You run into so many problems with the size of them, the updates not propagating immediately etc. It's just an ugly solution to the problem, that you then have to introduce further hacks (Bloom filters) atop of it all to make the whole mess work. I'm glad that Mozilla have done lots of work in this area with CRLite, but it does all feel like a bodge. 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?
- ekr____ 1y ago
  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-sha-1.html 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.
zahlman 1y ago
Does this mean I should turn "security.OCSP.require" back off in Firefox?
- mcpherrinm 1y ago
  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/ https://blog.mozilla.org/en/firefox/crlite/
sugarpimpdorsey 1y ago
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.
- stusmall 1y ago
  What in the Sam Hill? This is a new one on me. Does anyone have any reading for their logic of why?
  - TheDong 1y ago
    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/ 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.imperialviolet.org/2012/02/05/crlsets.html
  - na4ma4 1y ago
    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 https://www.w3docs.com/learn-html/html-keygen-tag.html) tag.
- creatonez 1y ago
  What are you on about? Literally all browsers have adopted the same strategy. It's not some secret they're trying to hide from you. It's a good thing.
  - ekr____ 1y ago
    Sort of. Firefox doesn't filter the list of revoked certificates the way Chrome does.
jart 1y ago
Good riddance. That was always a power grab if I ever saw it. They should take it out of browsers too.
EPWN3D 1y ago
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.
goldsteinq 1y ago
So non-browser clients have no feasible way of checking certificate revocation anymore.
NDizzle 1y ago
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
gregw2 1y ago
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).

217 points by pfexec 1y ago

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.

deleted 1y ago
[deleted]
jeroenhd 1y ago
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.
- tremon 1y ago
  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?
  - arccy 1y ago
    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.
  - avianlyric 1y ago
    > 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?
    - syncsynchalt 1y ago
      The bad actor would also need to install a root for their custom CA on the end-user device.
  - sugarpimpdorsey 1y ago
    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.
    - ameliaquining 1y ago
      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.
layer8 1y ago
> 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.
- arccy 1y ago
  actually that's pretty close to where we're going with ever shorter certificate lifetimes...
  - layer8 1y ago
    Only because the browsers are enforcing shorter lifetimes. But you can’t force a premature expiration in case of a server compromise, which is what revocation is for.
- GauntletWizard 1y ago
  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.
  - layer8 1y ago
    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.
tgsovlerkhgsel 1y ago
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.
- tptacek 1y ago
  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.
- charcircuit 1y ago
  >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.
  - lokar 1y ago
    You could extend the format to account for repetition of otherwise identical short ttl certs
  - tgsovlerkhgsel 1y ago
    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 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.

lol768 1y ago

The ship has very much sailed now with ballot SC63, and this is the result, but I still don't think CRLs are remotely a perfect solution (nor do I think OCSP was unfixable). You run into so many problems with the size of them, the updates not propagating immediately etc. It's just an ugly solution to the problem, that you then have to introduce further hacks (Bloom filters) atop of it all to make the whole mess work. I'm glad that Mozilla have done lots of work in this area with CRLite, but it does all feel like a bodge. 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?

ekr____ 1y ago
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-sha-1.html 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.

zahlman 1y ago

Does this mean I should turn "security.OCSP.require" back off in Firefox?

mcpherrinm 1y ago
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/ https://blog.mozilla.org/en/firefox/crlite/

sugarpimpdorsey 1y ago

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.

stusmall 1y ago
What in the Sam Hill? This is a new one on me. Does anyone have any reading for their logic of why?
- TheDong 1y ago
  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/ 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.imperialviolet.org/2012/02/05/crlsets.html
- na4ma4 1y ago
  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 https://www.w3docs.com/learn-html/html-keygen-tag.html) tag.
creatonez 1y ago
What are you on about? Literally all browsers have adopted the same strategy. It's not some secret they're trying to hide from you. It's a good thing.
- ekr____ 1y ago
  Sort of. Firefox doesn't filter the list of revoked certificates the way Chrome does.

jart 1y ago

Good riddance. That was always a power grab if I ever saw it. They should take it out of browsers too.

EPWN3D 1y ago

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.

goldsteinq 1y ago

So non-browser clients have no feasible way of checking certificate revocation anymore.

NDizzle 1y ago

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

gregw2 1y ago

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).