On Mon, Oct 11, 2021 at 10:05:34AM +0100, Brian Candler wrote: > On 11/10/2021 09:46, Chris Green wrote: > > ... and it results in exactly the same error as I originally reported. > > So I don't think the port number matters and the certificates at > > isbd.uk are up to date. > > There's a problem for some clients though: > > $ curl https://isbd.uk > curl: (60) SSL certificate problem: certificate has expired > > $ openssl s_client -connect isbd.uk:443 -servername isbd.uk -showcerts > ... > depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3 > verify error:num=10:certificate has expired > notAfter=Sep 30 14:01:15 2021 GMT > verify return:0 > depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3 > verify error:num=10:certificate has expired > notAfter=Sep 30 14:01:15 2021 GMT > verify return:0 > depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 > verify error:num=10:certificate has expired > notAfter=Sep 30 14:01:15 2021 GMT > verify return:0 > > This is on macOS 10.14.6. It's possible that your Firefox is affected by > the expiry of the DST X3 cert, like curl and openssl on this old mac are. > > For the full details of what's happened see: > > https://scotthelme.co.uk/lets-encrypt-old-root-expiration/ > https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/ > > The slightly shorter version is: LetsEncrypt returns a certificate chain > like this: > > <your server signed by LetsEncrypt R3> > | > <LetsEncrypt R3 signed by ISRG X1> > | > <ISRG X1 signed by DST X3> > > These days, your browser's trust store should contain the ISRG X1 root, and > it should use that as the trust anchor, and it should ignore the final cert. > > ISRG X1 was signed by DST X3 for the benefit of the early days, before the > ISRG X1 root was widely trusted. > > However, recently the actual DST X3 root certificate expired. (That's what > expired on Sep 30 14:01:15 2021 GMT; googling for that date is helpful). > > *Some* clients are now borked, even if they trust ISRG X1. They see that > the chain of trust ends in an expired certificate, without realising that > the chain of trust should terminate early on ISRG X1. > > Why do LetsEncrypt include the DST X3 cert in the chain? Because it helps > some very old Android devices which (a) still don't have the ISRG X1 in > their trust store, and (b) have a bug which allows them to trust a root > certificate in their store even after it has expired. > > Try removing the DST X3 from the chain on those servers, and see if the > problem goes away. > > If you are using dehydrated to issue certs, then add > PREFERRED_CHAIN="ISRG Root X1" > in the config file. <https://github.com/dehydrated-io/dehydrated/issues/808> > Wow! Thanks for that long explanation. However I'm still a bit stuck. If I simply visit the isbd.uk web site directly using Firefox then everything works as it should (and it is an HTTPS site so the certificates are being used/seen by Firefox). It's only when I try and use isbd.uk as a proxy to other (definitely OK sites, e.g. duckduckgo.com, google.co.uk, etc.) that I get the error. So is using isbd.uk as a proxy somehow using different certificates and getting the old hierarchy to the now discontinued root certificate. ... and it seems odd that I'm getting exactly the same problem when using a different proxy server. I can possibly try some other sites as proxy servers but I'm unconvinced that it's going to help. I'm also rather unfamiliar with all this SSL certificate stuff so dehydrated means nothing to me. I use certbot on isbd.uk to update certificates, rather mindlessly I'm afraid. -- Chris Green _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
