Jay Blanchard Jay Blanchard - 3 years ago 694
Javascript Question

WebSocket connection failed: WebSocket opening handshake was canceled

I have recently setup an EC2 instance (in a VPC with no load balancer) and admittedly the configuration is a bit odd, but it is what is required for the web application we're running.

The web server (in Haskell) is running on port 4433 (standard ports are reserved for an Apache instance) and is receiving UDP packets being broadcast from another system. I have many of the ports wide-open (just during testing) as shown here (from Security Groups):

Custom TCP Rule 4433 tcp 0.0.0.0/0 ✔
Custom TCP Rule 8080 tcp 0.0.0.0/0 ✔
SSH 22 tcp 0.0.0.0/0 ✔
HTTP 80 tcp 0.0.0.0/0 ✔
HTTPS 443 tcp 0.0.0.0/0 ✔
Custom UDP Rule 30090 udp 0.0.0.0/0 ✔
Custom UDP Rule 30089 udp 0.0.0.0/0 ✔


The JavaScript for the TCP socket makes a request to setup the socket on this same port (using the URL assigned to the AWS's public IP) and this is where the request returns the error:


WebSocket connection to 'wss://[URL]:4433/projects/socket' failed: WebSocket opening handshake was canceled.


Binding the socket to 0.0.0.0 results in the same error.

In order to start the Haskell web server I had to reference the internal IP provided by AWS as it would not run when referencing the public IP provided by the elastic IP service. Thinking this is where the problem came in I changed my socket request to this...

wss://[internal ip]:4433/projects/socket


This changes the error:


WebSocket connection to 'wss://[internal IP]:4433/projects/socket' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED


That error makes sense to me as the internal IP is not available to the outside world.

Everything that I've read on websockets on AWS involves an ELB (Elastic Load Balancer) and I am not in need of one of those. I have tried all of the things in all of the currently posted answers (some of the questions haven't even gotten answers) on SO to no avail. I also setup a support case with Amazon (nearly 24 hours ago) which hasn't received a response.

Additional Info



Navigating to
http://[URL]:4433/projects/socket
yields 'WebSocket Available' where the URL is the one we wish to use as well as the Public DNS provided by AWS.

Running
netstat -plunt
reveals the following:

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 [internal IP]:8080 0.0.0.0:* LISTEN -
tcp 0 0 [internal IP]:4433 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::443 :::* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
udp 0 0 [internal IP]:30089 0.0.0.0:* -
udp 0 0 0.0.0.0:30090 0.0.0.0:* -
udp 0 0 0.0.0.0:11950 0.0.0.0:* -
udp 0 0 0.0.0.0:68 0.0.0.0:* -
udp6 0 0 :::38450 :::* -


Has anyone had a similar problem with websockets on AWS? If so, how did you solve the problem?

Answer Source

There was an SSL certificate mismatch between the Haskell server and the Apache server.

The Haskell server had to be rebuilt with information concerning the new certificates for the instance. Further complicating this the proper SSL library (libssl0.9.8 libssl-dev) was not installed on the EC2 instance which was causing me problems during the rebuild of the Haskell server. Knowing an EC2 instance is a "blank canvas" makes the lack of that installation my fault.

Once I had the libssl installed I was able to rebuild the Haskell server with it pointing to the new certificates. Once the certificates "matched" the websocket issue disappeared.

Just to reiterate, ours is a unique situation. We have an Apache server (ports 80 and 443) and a Haskell server (ports 8080 and 4433) which communicate with each other, performing a pub-sub operation over websockets. A certificate mismatch between the two servers (it would not have mattered what type, it could have been multiple Apache instances) caused an SSL warning. Any warning from SSL will tear-down any attempt to establish or maintain a websocket (hence the handshake canceled message).

Another StackOverflow post provided some clues that were of tremendous help during this process. More specifically this warning -

The key to the problem is this: If your SSL certificate causes a warning of any sort, wss:// WebSocket connections will immediately fail, and there is no canonical way to detect this.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download