On Thu, Sep 30, 2021 at 09:43:54AM -0700, nate wrote:
> If I run this on OpenSSL 1.0.2g (Ubuntu 16.04)
>
> openssl s_client -connect bad_server_name:443 -servername bad_server_name
>
> I get at the end a clear: Verify return code: 10 (certificate has expired)
This is because OpenSSL 1.0.2 looks at the peer's certificate chain
before looking in the trust store.
> If I run on the same OpenSSL:
>
> openssl s_client -connect bad_server_name:443 -servername bad_server_name | openssl x509 -noout -dates
This is *not* the correct way to see all the expiration dates in the
chain. It will show only the leaf certificate dates. The right
incantation is:
$ openssl s_client -connect bad_server_name:443 -servername bad_server_name |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -print_certs -noout -text |
egrep 'not(Before|After)'
> If I try the same on OpenSSL 1.1.1f (Ubuntu 20.04), I get only the
> server cert
> not the CA cert dates:
> notBefore=Aug 31 17:59:09 2021 GMT
> notAfter=Nov 29 17:59:08 2021 GMT
Expected behaviour, you've only asked for the EE cert details.
> Also on the first command there is no error saying the cert is expired
> on OpenSSL 1.1.1f
OpenSSL 1.1.1 looks for issuer certificates first in the trust store and
only then in the peer chain.
> additional differences it seems 1.1.1f defaults to a verify depth of 2
> and 1.0.2g goes at least
> to 3 (perhaps more).
Expected, because it finds the ISRG root in the trust store, and so
ignores the cross-cert in the peer's chain.
Another potential issue (not in this case) is that the Let's Encrypt R3
intermediate issuing CA certificate (same subject DN and public key) is
available in two different forms:
* One issued by ISRG, still valid
* Another issued by DST, expired yesterday.
Correctly configured systems that use the Let's Encrypt "full_chain.pem"
file are using the ISRG version, and should not have any issues,
provided the client system is using OpenSSL 1.1.1 and has the ISRG root
CA
Servers that update only the Let's encrypt "cert.pem" file and provide
the rest of the chain independently, or somehow otherwise manage to be
stuck with the DST-signed "R3" now have certificate chains that will
fail to validate.
--
Viktor.
