@Quinnypig I have been beating this drum for years, at browser companies keep making it *worse*, not better.

An expired cert should, at worst, be like, a yellow warning in the address bar for a month or two. There's *zero* justification for treating a barely expired certificate as a reason not to navigate to a page.

Worse yet is the absolute travesty that is HSTS, which then ensures you can't bypass the error for any reason, even if you understand why it happened.

@ocdtrekkie @Quinnypig

Expired certs *have to* be treated exactly the same as revoked certs for two reasons, imo:

1) No one revokes certs after they expire. If a cert should be revoked (e.g. due to key compromise) shortly after it expires, it just won't be revoked instead. The browser must assume all expired certs may have been revoked, too.

2) If certs are allowed to function after they expire, the WebPKI loses agility. Enforcing expiry is how browsers ensure that BRs changes take effect.

@markpx509v3 @asg @Quinnypig Is this a practical concern or a theoretical one? My understanding is CRL checking not exactly ironclad to begin with. But the practical risk of expired certs appears to be still effectively nonexistent.

Can you give me an example of a real world attack that was done involving an expired certificate?

@ocdtrekkie @markpx509v3

It's practical. The specifics of CRLs vs OCSP vs any other revocation checking mechanism don't matter; what matters is that a cert which *otherwise* would be revoked, in fact won't be, simply because it is already expired.

The easiest attack vector is:
- issue a cert for example.com, let it expire
- sell example.com to someone else. They revoke all extant certs, but don't revoke yours because it's expired.
- intercept their traffic, and use your expired cert for TLS

@asg @markpx509v3 You can already request a valid certificate that's good for a year, and sell a domain to someone immediately thereafter, can you not? There's 364 days of valid certificate.

The instant is expires is absolutely the worst time to start treating an expired cert like a revoked cert, aforementioned 81% of organizations negatively impacted by issue caused solely by theoretical risks not used in practical attacks ever.

@asg @markpx509v3 This has never gotten me to a bad place, so why would I ever stop? (Since this conversation started, I clicked a link on HP's website, which linked to a subdomain where their cert was expired a week ago, and I clicked through, and it in turn redirected me back to an HP site with a valid cert. I literally experience things like this... close to daily?)

I at least know the potential risks, but most people will both bypass these inane warnings while not understanding the risks.

@ocdtrekkie @markpx509v3 I guess I don't know what to say. I've worked in this field for a while now and in tech generally for much longer, and I have *never* clicked through an expired cert warning and refusing to do so has never negatively affected my experience.

Browsers blocking these sites works. Choosing to block them a day, a week, or a month after they expire simply kicks the can down the road.

Convince site operators to automate their issuance, not browsers to reduce user security.

@asg @markpx509v3 The thing is, the PKI structure doesn't actually increase user security. None of this nonsense has come from practical attacks.

And aren't we amongst the process of yet another of those highly vetted CAs getting distrusted for... never having been trustworthy to begin with?

Why do browsers trust a certificate signed for a US company in China more than a certificate that expired yesterday?