Chris Green
2021-Oct-11 08:46 UTC
ssh proxy connection used to work with Firefox, now doesn't
OK, I have used the following command:- ssh -fC2qTnN -D 1080 chris at isbd.uk ... 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. As I said I'm pretty certain it's something more that Firefox is now demanding, but I don't know what. Thanks for your reply, just bouncing ideas back and forth can often sort this sort of thing out. -- Chris Green
Brian Candler
2021-Oct-11 09:05 UTC
ssh proxy connection used to work with Firefox, now doesn't
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> Regards, Brian.