On 2021-10-01, Andrew Daugherity <andrew.daugherity@gmail.com> wrote:
> 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]?
It's like the last paragraph of workaround 2, but without the build flag to
enable it. OpenSSL 1.1 doesn't have the problem due to the same change on
their side.
LibreSSL in -current/7.0 uses the new verifier which is better at
evaluating the graph of certificates and doesn't have this problem.
> 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)
IIUC the usertrust workaround handles cases where the server-supplied
certificate has expired, in this case the expired cert is in the trust
store but is not supplied by the server.
> 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?
Yes, and I see the same with at least one of the common JDK crypto
libraries (not entirely surprising given the relationship between Android
and Java).
> Also, apparently there was a different, older R3 intermediate which
> _also_ expired a couple days ago.)
Correct, I saw some issues with this too which I think might have been
down to client caching. (Also some server operators might be using
manually downloaded intermediates that they didn't update. "Normal"
GUI web browsers wouldn't notice this as they mostly fetch missing
intermediates automatically).
> 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.
Difficult situation and whether LE defaulted to the openssl
1.0.x-compatible chain or whether they defaulted to the one taking
advantage of the Android/Java security bug a large number of people
would have problems. But I think they did pick the one which is better
for the ecosystem in general and where the people who are affected
have some hope of fixing it.
> -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
>
>
--
Please keep replies on the mailing list.
No comments:
Post a Comment