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

On 21-09-30 19:45:38, James Cook wrote:
> On Thu, Sep 30, 2021 at 10:02:17AM -0700, Chris Bennett wrote:
> > Hi,
> >
> > 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:imaps
> >
> > openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
> >
> > However are not happy. I force updated my ssl certs, syspatch, pkg_add
> > -u and rebooted.
> >
> > I didn't rebuild dh.pem for dovecot.
> >
> > Is this just a DNS propagation issue?
> > Or should I do something further myself?
> >
> > Thanks
> > Chris Bennett
>
> A certificate in LetsEncrypt's chain expired today or yesterday. The
> issue is a bit complicated.
>
>
> There's a page here:
>
> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
>
> and a forum thread here:
>
> https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190
>
>
> Summary: generally, newer clients and web browsers will not give the
> cert expired error, because the middle certificate on the chain is a
> root cert in its own right. Other clients, including as far as I can
> tell the LibreSSL version included in OpenBSD 6.9, are more strict and
> reject the whole chain because the last certificate in the chain
> expired.
>
> E.g. I just tried "ftp -o x
> 'https://mail.strengthcouragewisdom.rocks/'" on -current and it
> worked.

Current uses the new X.509 verifier and is not impacted by this problem.

> LetsEncrypt does not want to remove that last one from the chain
> because older Android phones don't have that middle certificate as a
> root CA.
>
> Some post(s) in the thread claim it is possible to request an alternate
> chain from LetsEncrypt, if you want one that doesn't end with the
> expired one. I couldn't find this functionality in OpenBSD's
> acme-client. However, I tried manually editing the fullchain pem file
> downloaded by acme-client, deleting the third of three certificates in
> the file, and now my older clients are happy (but presumably old
> Android phones will not be happy).

Let's Encrypt is supplying alternate certificate chains. When you
fetch the certificate from the ACME order, HTTP Link headers with
'rel="alternate"' are potentially provided and these can be fetched
in the same way as the primary certificate chain. Unfortunately,
acme-client does not currently support this (not to mention that
chain selection also becomes messy from a application/configuration
stand point).