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 2 days ago | parent [-]

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?

▲

sugarpimpdorsey 2 days ago | parent | next [-]

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 2 days ago | parent [-]

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.

	▲	sugarpimpdorsey 2 days ago \| parent [-]
		Safari enforces a hard limit of just over two years.

▲

avianlyric 2 days ago | parent | prev | next [-]

> 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 a day ago \| parent [-]
		The bad actor would also need to install a root for their custom CA on the end-user device.

▲

arccy 2 days ago | parent | prev [-]

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.