On Thu, Sep 30, 2021 at 4:00 PM Sebastian Benoit <benoit-li...@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
