Replies: 1 comment
-
Yes, this was already reported in some magazines. E.g. in Germany, there is heise.de. They reported about the possible issues: https://www.heise.de/news/Let-s-Encrypt-Zertifikate-Ruckler-am-30-September-moeglich-6201155.html |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I just wanted to give a heads-up to anyone having the same issues that I have had recently...
Recently, I had an issue where I couldn't connect to my MQTT broker because clients were getting 400 errors or just not connecting to the server at all. I have NGINX as a reverse proxy and it is set up to work with secure WebSockets.
After days of configuration updates and code changes I eventually found out that the certificate I was serving had a recently expired root certificate! My certificate was fine, the parent "ISRG Root X1" root was fine too, but the "DST Root CA X3" was not. It is not clear from the error logs of various clients that this is the issue. What makes it worse is that browsers will report that the certificate is fine. You can run
openssl s_client -tls1_3 -connect mydomain.com:443
, and I also created a PowerShell script for testing too (see here).The solution is to force renewal of the certificate with an alternative certificate chain. This will cause validation issues for older clients but that was acceptable for me on this particular domain. A lot of older clients can also have the new root certificate installed manually and MQTTNet allows you to specify certificates to use too. I was able to use certbot to use the alternative certificate chain:
certbot renew --force-renewal --preferred-chain="ISRG Root X1" --cert-name mydomain.com
. You can see how letsencrypt certificates chain together hereLinks:
Beta Was this translation helpful? Give feedback.
All reactions