Saturday, October 02, 2021

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

On 2021-10-02, Marcus MERIGHI <mcmer-openbsd@tor.at> wrote:
> Hello!
>
> benoit-lists@fb12.de (Sebastian Benoit), 2021.09.30 (Thu) 21:42 (CEST):
>> Chris Bennett(cpb_misc@bennettconstruction.us) on 2021.09.30 10:02:17 -0700:
>> > I'm getting that the certs are expired, but https works fine in Firefox,
>> > including when looking at the full chain.
>> > openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
>>
>> This is an issue with an expired root/intermediate certificate (DST Root X3)
>> in use by Let's Encrypt.
>>
>> Stuart Henderson (sthen@) summarized it like this:
>>
>> LibreSSL in OpenBSD 6.9/earlier is having problems with the expiry of a
>> CA certificate used to cross-sign Let's Encrypt certs.
>>
>> LE decided not to switch to using their own root fully, rather they
>> are continuing to use the expired cross-signer to increase compatibility
>> with old Android devices, which is tickling this problem.
>> https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
>>
>> An errata has just been published, you can install it using syspatch.
>
> I've syspatch(8)-ed a machine that now delivers the following error:
>
> $ ftp -VMo /dev/null \
> "https://shop.theater-phoenix.at/Events.aspx?msg=0&ret=1"
> TLS handshake failure: certificate verification failed: unable to get
> local issuer certificate
>
> $ openssl s_client -servername shop.theater-phoenix.at -connect \
> shop.theater-phoenix.at:https
> Verify return code: 21 (unable to verify the first certificate)
>
> The server "shop.theater-phoenix.at" runs under Windows and uses
> letsencrypt certificates.
>
> Does this issue have the same root cause or is this something different?

Different. They are using the wrong *intermediate* cert (which expired on
*Wednesday*):

Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Validity
Not Before: Oct 7 19:21:40 2020 GMT
Not After : Sep 29 19:21:40 2021 GMT
Subject: C=US, O=Let's Encrypt, CN=R3

Specifically, at present they should be using this instead:
https://letsencrypt.org/certs/lets-encrypt-r3.pem
However it may change in future so they should use the one fetched by
their ACME client (generally this
means using the "fullchain" file) rather than fetching a separate one.

--
Please keep replies on the mailing list.

No comments:

Post a Comment