User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 When an encrypted (wss:https://) WebSockets connection is made from a page and the server is using a self-signed certificate, there is no way to force the browser to accept the certificate. This is probably going to be the normal case when developers are testing their pages that use WebSockets. It's likely people will want to do this in production too where the main page is https and handles authentication and authorization, and the WebSockets connection is just for encryption (and may be to a different location). When the connection is made, a dialog pops up named "Secure Connection Failed" and there is no way to accept the certificate from this dialog. There is a "View Certificate" button, but this just shows certificate info and has no way to accept the dialog. Note that Chrome does not prompt at all for self-signed certificates used in WebSockets connections. That might not be the right answer, but at the very least there should be an easy way to accept the certificate like there is for normal https connections. Perhaps just an indication in the address bar that the page is not entirely secure. Reproducible: Always Steps to Reproduce: 1. Start a WebSockets server that supports 'wss:https://' and has a self-signed certificate. The noVNC project has a python and C implementation of a generic WebSockets to TCP sockets proxy that supports 'wss:https://' (https://github.com/kanaka/noVNC). 2. Load a page/webapp that supports 'wss:https://' WebSocket connections. I.e. the noVNC client (see above link). 3. Try and connect to the server from the client. The dialog will pop-up. Other text in the dialog: Secure Connection Failed FOO uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_untrusted_issuer) It is possible to work around this by first going to the 'wss:https://' site manually using the browser and accepting the certificate there. After that, the WebSockets connection can be made manually. But that's only a workarond. There should be a way to accept the certificate when the 'wss:https://' WebSockets connection is actually initiated.

We're experiencing the same problem. Our embedded device may be accessed directly by IP. In this case the Certificate is invalid, because the hostname doesn't match. A dialog allows the user to accept the seemingly invalid certificate and continue using the site. Firefox accepts this user-initiated cert-ignore for the given authority (schema, hostname, port) only. That means that a WSS (Secure WebSocket) connection on another port on the same hostname cannot be established. Google Chrome accepts the certificate for the hostname, allowing WSS to work just fine. We'd need a second dialog to accept the certificate for the WSS connection as well - or have firefox accept the cert for the hostname.

Having the same issue in our project User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 responce is 403 Forbidden on chrome wss:https:// works fine.

I am experiencing this problem as well. I used to be able to get around it by using the same SSL certificate for both the HTTPS website and the WSS WebSocket but that doesn't work if the WebSocket is on a different port. It *used* to work (not sure when it changed) but apparently not anymore. This is a fairly serious problem that stands in the way of more WebSocket adoption. It stands counter to the idea that WebSockets have no origin restrictions. You *should* be able to connect to wss:https://foo.com from https://whatever.com/ even if it uses a self-signed certificate.

Yes actually I am having this issue on Firefox 17 LST on Linux CENTOS. Even I have accepted the self-generated certificate it does not allow websokets to work, meanwhile in Chrome this does not happens. How to accept this certificate?

The workaround in the original report does not work for me in Firefox 30.0 on a mac. Entering wss:https://example.com:port doesn't appear to do anything. Fortunately, it works in Safari 6.1.4 on a mac. Use https to hook up to a server on the same host, and Safari will offer to save the certificate and use it for all connections on the same machine. I can at least test my app, though I'll need to make it configurable for SSL or NO-SSL to test with Firefox. Do we know if wss:https:// works at all in firefox? Once I get a production certificate, I might find other bugs. Presumably, the firefox developers found some way to test wss?

Confirmed bug present in Firefox 22 on linux (no surprise there), and absent in google chrome 35.0 on linux. So, the workaround seems to be: Use an alternate browser (Safari, Chrome confirmed) for the bulk of your testing with SSL. Use a non-SSL server for testing with Firefox. Do a final test pass using your production certificate when you are about ready to release.

This bug is still present in Firefox 32.0.1 on Windows, and silently breaks secure websockets connections which use a self signed certificate. Chrome 37 works as expected. The browser should at a minimum prompt to accept the wss:https:// self-signed certificate. Having to go to https://server:<wssport> and accept the certificate (which in my case is the same one as port 443) isn't a good workaround. Can a developer please take a look at this bug for us? Thanks!

I also confirm this. I did a try with Fleck to have a wss server on Windows using a. I have a index.html on a server

Sorry, I'll continue I also confirm this. I did a try with Fleck (github) to have a wss server on Windows using a PFX certificate I had to include the PFX certificate to root Auth in IE I have a index.html on a server I have no problem on IE11 and Chrome, the index.html is able to connect to the wss server (Fleck) Firefox brokes the socket during negociation... Note: for Firefox: I also had to generate a PFX with password (didn't accept one without pwd) and I don't how to import it in "root" as for IE ?

In latest version of firefox ie 34.0, the issue is still present. Tried with self-signed certificate, it didn't open the web socket connection. There must be a solution for this. It's too difficult to develop something with web sockets under a real certificate for each developer in a production. Chrome doesn't have any problem. Using https + wss, did any one try with trusted / real certificate ? What is the result ? Is it working ?

(In reply to Rama Krishna G from comment #10) > In latest version of firefox ie 34.0, the issue is still present. Tried with > self-signed certificate, it didn't open the web socket connection. There > must be a solution for this. It's too difficult to develop something with > web sockets under a real certificate for each developer in a production. > > Chrome doesn't have any problem. > > Using https + wss, did any one try with trusted / real certificate ? What is > the result ? Is it working ? Please note - I also want/need it into FF for https site + localhost wss communication - I noticed also in IE on Windows 8.1 with enhanced security that https/wss on localhost

(In reply to Rama Krishna G from comment #10) > In latest version of firefox ie 34.0, the issue is still present. Tried with > self-signed certificate, it didn't open the web socket connection. There > must be a solution for this. It's too difficult to develop something with > web sockets under a real certificate for each developer in a production. > > Chrome doesn't have any problem. > > Using https + wss, did any one try with trusted / real certificate ? What is > the result ? Is it working ? Just tried with a trusted certificate "localhost" (with my own CA added in the store) instead of a self-signed certificates, it works. I'm able to open a wss connection to my server running on localhost. Should also work with any other server certificate.

Thank you. That would really help us to analyse the issue further. We started testing with a trusted certificate (with our CA added in the store), looks like it's working a trusted certificate. Can you please post the client javascript code which works with major browser such as IE10, Firefox, Chrome ? (handles both trusted and self-signed certs) My ID : guntuka.ramakrishna@gmail.com

What's the status of this? Firefox should be able to accept self-signed certificates if the user has explicitly accepted them

Hey? What's the state of this bug? I'm currently thinking on These possibilities: 1. Add a "ignore certificate error" button, just like when connecting to https, 2. Make a list, with accepted certificates, and check against then, maybe popping up a Dialog if not accepted (see 1.) 3. Accept any cert. (Disable cert-verification on wss) What do you think?

this is good and known ideas. so yes it's useful

Approval Request Comment [Feature/regressing bug #]: [User impact if declined]: [Describe test coverage new/current, TreeHerder]: [Risks and why]: [String/UUID change made/needed]:

Similar issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1187666