9

When doing new WebSocket('ws://server/'); Safari connects fine, but when using new WebSocket('wss://server/'); it completely fails (returns a null object). Worse, it fails silently - no errors in traceback (a custom Eventlet web server) or in the error console within Safari.

Chrome works fine with both the secure and non-secure host.

How would I go about debugging or fixing this? Google is very short on information.

Here is some traceback from running OpenSSL in place of the WebSockets server and seeing what happens. Firstly, here's Chrome's (which does work) debug output:

Using default temp DH parameters Using default temp ECDH parameters ACCEPT SSL_accept:before/accept initialization SSL_accept:SSLv3 read client hello A SSL_accept:SSLv3 write server hello A SSL_accept:SSLv3 write certificate A SSL_accept:SSLv3 write key exchange A SSL_accept:SSLv3 write server done A SSL_accept:SSLv3 flush data SSL_accept:SSLv3 read client key exchange A SSL_accept:SSLv3 read finished A SSL_accept:unknown state SSL_accept:SSLv3 write change cipher spec A SSL_accept:SSLv3 write finished A SSL_accept:SSLv3 flush data -----BEGIN SSL SESSION PARAMETERS----- GIBBERISH HERE -----END SSL SESSION PARAMETERS----- Shared ciphers:CIPHERS_HERE CIPHER is REDACTED Secure Renegotiation IS supported GET / HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: live.redacted.com:8443 Origin: http://redacted.com Sec-WebSocket-Key1: 1 [ B l wA 3 e60 d9[ n0!>8384 Sec-WebSocket-Key2: 2 5 1 7p 17 64 3 9 Cookie: __key=value

and here's Safari's (which doesn't work):

ACCEPT SSL_accept:before/accept initialization SSL_accept:SSLv3 read client hello A SSL_accept:SSLv3 write server hello A SSL_accept:SSLv3 write certificate A SSL_accept:SSLv3 write server done A SSL_accept:SSLv3 flush data SSL_accept:failed in SSLv3 read client certificate A ERROR shutting down SSL CONNECTION CLOSED

So I think Safari has an issue with our certificates—but one it doesn't reveal when using regular HTTP.

Improve this question

2 Answers 2

Reset to default
3

Sysadmin fiddling has revealed a fix: setting OpenSSL to SSLv3 by default kills Safari, but letting it pick its own SSL version (all) works fine.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Ah yes, that was another thing I recall dealing with. However, I'm surprised you aren't getting any feedback from your WebSockets server in that case.
Well it wasn't even receiving the request, as Safari was closing the connection immediately after the handshake. It never got to the WebSockets server.
Could someone give more clear steps on what to be done? I didnt really get the solution here!
1

Where I've seen this, it means there is something wrong with the certificate (expired, incorrect domain, etc). Try connecting directly to the WebSockets server from Safari, i.e. https://wss_server:wss_port/. Safari should give you a better error message that way.

When I had this problem while developing wsproxy as part of noVNC (HTML5 VNC client) it turned out I was using an IP for the server but the certificate was signed for a hostname.

Improve this answer

1 Comment

The certificate is fine, we can connect in every other way. It was an SSL configuration issue, as shown below.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.