Open robstradling opened 2 years ago
The point is that the trust store is controlled by the system administrator (or user and not the remote attacker) so the self-signature is irrelevant. And actually checking the expiry date on root certs makes sense to avoid requiring dropping expired root certs as they really should NOT be used to sign anything after the date. I.e., what the Let's Encrypt and DST Root CA did is actually fairly ugly hack to just appease some older Androids.
If we implement such (mis?)feature, it would have to be optional and not on-by-default.
Marking as inactive, to be closed at the end of the 3.4 dev cycle, barring further input
OpenSSL has ignored self-signed certificate signatures since 0.9.8m (see https://github.com/openssl/openssl/commit/1e53b797f65ef6d3c2eb1052797683fec27a9ff5). Due to this, it's possible to artificially extend the lifetime of an expired root certificate in an OpenSSL client's trust store simply by locally modifying that certificate's notAfter date. I posted a write-up (https://www.mail-archive.com/openssl-users@openssl.org/msg90092.html) that demonstrates how this technique is useful for working around the recent expiry of the "DST Root CA X3" root certificate.
What's the point of OpenSSL checking the notAfter timestamps in certificates that have self-signed signatures, given that these timestamps can be trivially modified?
I propose that OpenSSL should adopt the same behaviour as Android (explained by https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/). i.e., Ignore the notAfter field in locally-trusted certificates, so that OpenSSL clients will never regard these locally-trusted certificates as expired.