Re: Server certs expired higher up the chain, imaps and https

On Thu, Sep 30, 2021 at 4:00 PM Sebastian Benoit <benoit-lists@fb12.de> wrote:
> This is an issue with an expired root/intermediate certificate (DST Root X3)
> in use by Let's Encrypt.
>
> [...]
> An errata has just been published, you can install it using syspatch.

Thanks for the quick patch! I can verify this fixes fetching with
ftp(1) from https servers which use Let's Encrypt certificates. It
looks like this is "workaround 2" as described in this OpenSSL blog
[1]?

I'm surprised this was even needed, as I thought this problem was
"fixed" last year after the AddTrust External CA Root expiration. It
seems to be a similar case of "while waiting for widespread acceptance
of a new root, the intermediate is cross-signed". In that case the
cert chain configured on your web server was:
- host cert, signed by:
- InCommon RSA Server CA (or several other intermediates), signed by:
- USERTrust RSA Certification Authority, signed by:
- AddTrust External CA Root (which expired 2020-05-30; recommended not
to send the top-level root since it's in the client store and thus
redundant).

A few years before that expiration, they got a new USERTrust root into
browser/OS certificate stores, and intermediates like InCommon were
also signed by this new root. Browsers would ignore that last
USERTrust intermediate cert since it wasn't needed, but OpenSSL before
1.1 would still consider it expired because of that intermediate.

This seems to be a similar scenario, with:
- host cert, signed by:
- Let's Encrypt R3, signed by:
- ISRG Root X1, signed by:
- DST Root CA X3 (which just expired)

Likewise, there's a new ISRG Root X1. The "alternate" or "short"
chain on your server would consist of host + R3, but certbot etc. are
defaulting to the "long" chain which adds the X1 intermediate. Unlike
the USERTrust/AddTrust scenario, where the intermediate USERTrust cert
expired the same time as the AddTrust root, the intermediate X1 cert
doesn't expire until 2024-09-30. That seems to go against accepted
standards of not issuing certificates expiring after the issuer
expires, but maybe they got special dispensation. (And apparently
Android doesn't care if the root expired, if everything else is valid?
Also, apparently there was a different, older R3 intermediate which
_also_ expired a couple days ago.)

The immediate fix last year was to stop sending the unnecessary
expired intermediate cert (i.e. only send host cert and InCommon RSA,
not the USERTrust intermediate), but I thought a fix went into
LibreSSL then to not consider a host "expired" if it was possible to
generate a valid chain of trust, regardless of "extra" certs sent by
the server?

Indeed, Let's Encrypt's own documentation [2] thinks that only
LibreSSL < 3.2.0 is affected, but that is not the case. LibreSSL
3.3.2 in OpenBSD 6.9 (before the new syspatch) still considered
servers expired, as does the somewhat older version bundled in macOS.

-Andrew

[1] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/
[2] https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816