Strictly it isn't true that a leaf cert's validity must be capped by the parent issuer's, but I'm also surprised this worked. I suspect the intermediate is sti

Strictly it isn't true that a leaf cert's validity must be capped by the parent issuer's, but I'm also surprised this worked. I suspect the intermediate is still valid though. The PKIX RFC 5280 says: https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5 https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.... I'll leave you to parse it, but it notably lacks the requirement that CAs must truncate validity. Let's Encrypt is a great example: https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/ -- DST Root CA X3 -> ISRG Root X1 is a cross-signed root, and DST Root CA X3 expired recently (breaking some validation on Android devices). However, by issuing that cross-signed ISRG root before the DST root expired, Let's Encrypt is still working on older Android devices: https://letsencrypt.org/2020/12/21/extending-android-compatibility.html https://letsencrypt.org/2020/12/21/extending-android-compati... In practice though, most chain validation I've looked at (OpenSSL, NSS+pkix, Go) all validate the validity period of the intermediate (relative to now, not of the leaf) and will err if it isn't still valid. What they don't validate is _root_ validity (since it is ultimately trusted and in the trust store, and is again how the Android support worked). So typically you'd want to permit longer validity from roots (pending the caveat about supporting CRL/OCSP/... throughout the longer lifetime of any leaf), but truncate validity on leaves issued from intermediates.