Hacker News Reader

Comment by GauntletWizard | Hacker News Reader

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.

View on HN

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.

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 could extend the format to account for repetition of otherwise identical short ttl certs

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.

> 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

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.

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.

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.

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?

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.

> 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?

The bad actor would also need to install a root for their custom CA on the end-user device.

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.

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.

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

actually that's pretty close to where we're going with ever shorter certificate lifetimes...

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.

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.

Reply on news.ycombinator.com