It’s a complete failure of infosec-meets-user-psychology that “this TLS certificate is issued for your bank and the server is sneaky hackerman dot com” and “this otherwise valid certificate expired a day ago” have the EXACT SAME USER EXPERIENCE.

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

@asg @ocdtrekkie @Quinnypig expired certs “drop off” CRLs (in most circumstances, code signing is one of the few usages where a cert with that key usage WON’T drop off a CRL.) Expiry of a certificate is checked (according to RFC 5280) PRIOR to revocation checking. Hence why expiry is considered “terminal” in terms of certificate validity.

@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 Beyond the general issue of causing widespread issues solely based on PKI being designed by people who literally hate users, instantly rejecting expired certs has (rightfully) taught me to completely ignore browser cert warnings, and bypass nearly all of them by default.
@ocdtrekkie @asg @markpx509v3 this is the exact scenario I point out in risk assessments when I find expired certs, along with things like "this cert expired a year ago, indicating a lack of site maintenance or monitoring." They're training end users to ignore potentially valid warnings. (Well, the browsers are training them in this case.)
@legion303 @asg @markpx509v3 Exactly. It's a case of alert fatigue, or a boy who cried wolf situation.