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).
