This does sound like an issue on your side (i.e. the side of your website).
The certificate provided by the server is fine and it is accepted by almost all browsers - the problem is that a lot of older servers do not have the (relatively) new root certificate in their trust store so a lot of automated stuff is throwing errors at the moment.
I don’t know your exact site so I took an arbitrary hosted-by-discourse.com site and ran it through the Qualys SSL Server Test.
You can see that root of the second certification path is indeed expired, but this is mitigated by the ISRG Root X1 certificate being in the trust store (i.e. included in your browser and/or operating system) for the first certification path.
Servers typically do not update their trust store often so your server probably does not have the ISRG Root X1 certificate in its trust store. (That is what happened to the mail-receiver Docker image as well).
You can find a current bundle on for instance https://curl.se/ca/cacert.pem. On CentOS that file goes into /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. On Ubuntu you can use the update-ca-certificates command which updates /etc/ssl/certs/ca-certificates.crt.
Alternatively, you could temporarily disable SSL certificate verification in your server code.
The problem is, there are two copies of ISRG Root X1 - one of them was issued by DST Root CA X3 a long time ago, and the newer one was self-signed by the ISRG (the group that governs Let’s Encrypt, among other things) and that self-signed Root CA is now accepted as a trusted Root CA on most systems
They are the same signing certificate, so you can validate anything that claims to be issued by ‘ISRG Root X1’ against either version but the one that was signed by DST is no longer valid as a certification path because the DST certificate that signed it is now expired
If the server was doing the right thing and supplying the newer ISRG Root X1 that’s self-signed, then the client would compare the supplied one against its own trust store, verify that it’s the same cert, and be OK but instead it sees the supplied cert, goes “Ok I need to validate this against DST Root CA X3 that I have on file… oops that’s expired” and fails verification
So either your devops guy is wrong, or CDCK and LetsEncrypt and Qualys are wrong.
Tell him to update the root CA store. It will resolve the issue. Believe me.
Hi @bpaterson2000 - sorry to hear you’re having problems connecting to our hosted service. As @RGJ mentioned, this isn’t something wrong on the Discourse end - it needs to be fixed on your client. (Our servers don’t ‘supply’ the root certificate, they are managed by your client)
You can find more details from Let’s Encrypt on the change here:
Thanks for the info, it is an unexpected issue for us as the errors were apparently coming back from the hosted server.
We use heroku which bundles the stuff you are talking about via node/packages apparently - and it looks like updating node was the key to getting it successfully connecting to the discourse rest API successfully again.