How to debug Safari silently failing to connect to a secure WebSocket

Question

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.

Answer 1

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.

Answer 2

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.