Closed margueritepd closed 1 year ago
Thanks for the thorough diagnostic information here. I believe that https://github.com/faye/faye-websocket-ruby/commit/d9428fae72240bfa8b98627a0414524814b92f22 fixes this problem, could you confirm?
Ooo thank you so much! Preliminary testing is indicating this is working. I will report back when I try this fix on our main tool that has been broken these last few days.
This looks to be working! Thank you so much!!!
Thanks for testing, this has now been release in version 0.11.2.
Hi there, I am not terribly experienced in websockets, eventmachine or SSL so there is a good chance this ticket is misfiled. I hope I don't waste too much of anyone's time.
It seems as though this library is unable to verify Let's Encrypt certificates when the so-called "long chain" is provided by the server. ("Short" vs "Long" chain is described here: https://community.letsencrypt.org/t/long-default-and-short-alternate-certificate-chains-explained/162526 . The Long Chain includes an expired root certificate, but according to Let's Encrypt, the chain should still validate on modern systems, because the next cert in the chain is often itself installed as a CA.)
I am coming across this because recently Slack changed something with their certificate chain as described here. My hypothesis is that they just began serving the Let's Encrypt long chain.
I have validated it with a program like this:
Here are some sample CLI runs:
When I inspect the certificate chain of the failing runs, here's what I end up with:
cert chain for demo.piesocket.com
``` #cert chain for wss-primary.slack.com
``` #As you can see the failing servers are serving the same certificate chain.
I don't know of a websocket endpoint serving the let's encrypt short chain to be able to compare.
Wondering if you are able to reproduce and if you have any more insight into the matter.
Thank you!