Websocket on Mac/IPad/IPhone not connecting

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: sessions-ebookbuddy.org

I ran this command:

It produced this output:

My web server is (include version): Ubuntu 20.04 , nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version):
Django==3.2.7,
channels==3.0.4,
daphne==3.0.2,

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): snap certbot (1.19.0)

We have a website with websockets through Django, Django Channels. The main part of the site is working fine however Mac/IPhone/Ipad users can't connect to the websockets.

The users of the site are children so unfortuately having them make any changes on their device is pretty much out of the question. What can I do the server to ensure only the trusted chain is sent.

Previously I just had this error when checking the ssl.

|4|In trust store|DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
EXPIRED

Weak or insecure signature, but no impact on root certificate

However, now this one is now coming up as well

|3|Sent by server|ISRG Root X1
Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA

CRL ERROR: HTTP request failed with status code 404: http://crl.identrust.com/DSTROOTCAX3CRL.crl

Those are both in the Path 2, Path 1 is showing no errors, but for some reason the Macs are denying the websocket only based on the not trusted second path.

Any help would be greatly appreciated, the kids are so disappointed they can't use the program.

Thanks

2

Hi @Buddy_Admin welcome to the LE community forum :slight_smile:

I see that site is already using the shorter trust path:

openssl s_client -connect sessions-ebookbuddy.org:443 -servername sessions-ebookbuddy.org | head
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = www.sessions-ebookbuddy.org
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:CN = www.sessions-ebookbuddy.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---

If this change hasn't improved the situation...
I can only recommend that you switch to another (free) CA that supports ACME protocol.
That should provide another trust path (one that isn't connected to any expired or too newly issued root)

3

Thanks Rudy, I did switch to the shorter chain. I will see if it helps. We have a three sessions this afternoon with approximately 180 users. Quite a few of the kids joining with iPads and then the volunteers with Macs will be the true test.

Mickie

1 Like
4

The iPads are likely new enough to work with this shorter chain (that requires for them to have "ISRG Root X1" in their trust store).

The Macs are a big question mark.
There might be really new ones and there might be really old/un-updated ones in that "group".

So, again, the sure fire way to cover all the bases (without having any end-user modification) is to switch to another (free) CA that is using a root that has been in the trust store for many years.

5

From what you've explained, I think this may be happening:

If the Mac/iPhone/iPad users are connecting to the main site via https, then they are on a newer OS and have the ISRG root installed.

Daphne is an ASGI server, and based on the errors on websockets and not the main site, my guess is the issue is likely on the Daphne configuration (if you're terminating SSL on that) or the nginx+daphne configuration.

Is there a publicly accessible route for the websockets portion of your site?

1 Like
6

I like your thinking...
Definitely going in the right direction!
If this worked last week, then it has to do with daphne likely not using the fullchain.pem.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.