Tested this issue on Ubuntu 14.04 by using chrome reported version stable # 58.0.3029.81 & Chrome latest stable # 58.0.3029.96 and able to repro the Issue (Please refer attachment 'WebSocket errors InM-46').

Similar Behavior is also seen in older chrome versions # 46.0.2463.4 

Note: In Firefox "Firefox can't establish a connection to the server at ...." error is seen (Please refer attachment 'FirefoxError')

Marking this as Untriaged for further investigation by the respective team

Deleted: WebSocket errors InM-46.png 1.4 MB

	WebSocket errors InM-46.png 1.4 MB View Download

Deleted: FirefoxError.png 1.4 MB

	FirefoxError.png 1.4 MB View Download

The screenshots in #2 show the secure WebSocket connections working in neither Firefox nor Chrome.

Here is screenshot from Firefox and it is WebSocket is working. What Firefox version did you use?

Deleted: Screenshot_20170509_155648.png 1.4 MB

	Screenshot_20170509_155648.png 1.4 MB View Download

I made a video with Firefox vs Chromium https://www.youtube.com/watch?v=lOGzsr7yXxI

I have tested secure WebSocket on Android Firefox (53.0.2) and Android Chrome (58.0.3029.83) on the same site.
- Firefox is working
- Chrome not working

Will you still need my site? I would like to run it, and since WS SSL does not work on browsers with WebKit engine, I have to disable encryption.

Could you provide a net-internals log? https://dev.chromium.org/for-testers/providing-network-details

Net export

Deleted: chrome-net-export-log.json 148 KB

chrome-net-export-log.json 148 KB View Download

Thank you!

wss://warsoftheheroes.eu:1025/main
Start Time: 2017-05-11 02:56:36.734

t=2339 [st= 0] +REQUEST_ALIVE  [dt=41]
                --> priority = "LOWEST"
                --> url = "wss://warsoftheheroes.eu:1025/main"
t=2340 [st= 1]   +URL_REQUEST_DELEGATE  [dt=1]
t=2340 [st= 1]      DELEGATE_INFO  [dt=1]
                    --> delegate_blocked_by = "rozszerzenie uBlock Origin"
t=2341 [st= 2]   -URL_REQUEST_DELEGATE
t=2341 [st= 2]   +URL_REQUEST_START_JOB  [dt=39]
                  --> load_flags = 18 (BYPASS_CACHE | DISABLE_CACHE)
                  --> method = "GET"
                  --> url = "wss://warsoftheheroes.eu:1025/main"
t=2341 [st= 2]      URL_REQUEST_DELEGATE  [dt=0]
t=2341 [st= 2]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=2341 [st= 2]     +HTTP_STREAM_REQUEST  [dt=39]
t=2341 [st= 2]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                      --> source_dependency = 24664 (HTTP_STREAM_JOB_CONTROLLER)
t=2380 [st=41]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                      --> source_dependency = 24665 (HTTP_STREAM_JOB)
t=2380 [st=41]     -HTTP_STREAM_REQUEST
t=2380 [st=41]      URL_REQUEST_DELEGATE  [dt=0]
t=2380 [st=41]      CANCELLED
t=2380 [st=41]   -URL_REQUEST_START_JOB
                  --> net_error = -3 (ERR_ABORTED)
t=2380 [st=41]    URL_REQUEST_DELEGATE  [dt=0]
t=2380 [st=41] -REQUEST_ALIVE
24664: HTTP_STREAM_JOB_CONTROLLER
wss://warsoftheheroes.eu:1025/main
Start Time: 2017-05-11 02:56:36.736

t=2341 [st= 0] +HTTP_STREAM_JOB_CONTROLLER  [dt=39]
                --> is_preconnect = false
                --> url = "wss://warsoftheheroes.eu:1025/main"
t=2341 [st= 0]    HTTP_STREAM_JOB_CONTROLLER_BOUND
                  --> source_dependency = 24663 (URL_REQUEST)
t=2341 [st= 0]    HTTP_STREAM_REQUEST_STARTED_JOB
                  --> source_dependency = 24665 (HTTP_STREAM_JOB)
t=2380 [st=39] -HTTP_STREAM_JOB_CONTROLLER
24665: HTTP_STREAM_JOB
wss://warsoftheheroes.eu:1025/
Start Time: 2017-05-11 02:56:36.736

t=2341 [st= 0] +HTTP_STREAM_JOB  [dt=39]
                --> alternative_service = "unknown :0"
                --> original_url = "wss://warsoftheheroes.eu:1025/"
                --> priority = "LOWEST"
                --> source_dependency = 24664 (HTTP_STREAM_JOB_CONTROLLER)
                --> url = "wss://warsoftheheroes.eu:1025/"
t=2341 [st= 0]   +PROXY_SERVICE  [dt=0]
t=2341 [st= 0]      PROXY_SERVICE_RESOLVED_PROXY_LIST
                    --> pac_string = "DIRECT"
t=2341 [st= 0]   -PROXY_SERVICE
t=2341 [st= 0]    HTTP_STREAM_JOB_PROXY_SERVER_RESOLVED
                  --> proxy_server = "DIRECT"
t=2341 [st= 0]    HTTP_STREAM_JOB_WAITING  [dt=0]
                  --> should_wait = false
t=2341 [st= 0]   +SOCKET_POOL  [dt=39]
t=2379 [st=38]      SOCKET_POOL_BOUND_TO_CONNECT_JOB
                    --> source_dependency = 24666 (SSL_CONNECT_JOB)
t=2380 [st=39]   -SOCKET_POOL
                  --> net_error = -110 (ERR_SSL_CLIENT_AUTH_CERT_NEEDED)
t=2380 [st=39]    HTTP_STREAM_JOB_BOUND_TO_REQUEST
                  --> source_dependency = 24663 (URL_REQUEST)
t=2380 [st=39] -HTTP_STREAM_JOB

This is because the server requests the client to provide a client certificate.

Chrome doesn't show any dialog (including the client certificate choosing one) for sub-resources (including WebSockets). If a web app wants to use WebSocket with authentication with a client certificate, the user should be navigated to a page that would show the dialog in advance to the WebSocket instantiation. The certificate picked will be remembered and used for WebSockets.

Even if client certificate providing is optional for the server (i.e. connection can be established without a client certificate), as far as the server requests the client to provide one, WebSocket aborts establishment since it doesn't know whether it may retry with no cert or the user might want to provide a cert. wss://warsoftheheroes.eu:1025/ does accept connection without a client cert but the decision must be remembered by the user agent in advance for some main resource with the same authentication realm.

Typically, it's done just by serving the page with the WebSocket and the WebSocket on the same server, but https://warsoftheheroes.eu/en/ connects to wss://warsoftheheroes.eu:1025/ which is different from the main resource. So, it doesn't work.

@tyoshino@chromium.org 
> server requests the client to provide a client certificate
Are you sure about that this is the case here?

> Typically, it's done just by serving ... on the same server
This is the same physical machine, port is different but how can HTTPS and WSS work on the same port?

When I attempt to view https://warsoftheheroes.eu:1025/, I'm asked to pick a client certificate. According to yhirano's network dump, the WebSocket connection is also getting the request to provide a client cert. Please see the like with "ERR_SSL_CLIENT_AUTH_CERT_NEEDED". It indicates that.

> This is the same physical machine, port is different but how can HTTPS and WSS work on the same port?

When the port is different, I guess the choice on use/no-use of client cert won't be reused, but if they're the same, it does. I need to check with TLS expert for the strict criteria, I'm not.

At least, if I access https://warsoftheheroes.eu:1025/ first but decline to choose a client certificate, and then open the app at https://warsoftheheroes.eu/en/, it works without any WebSocket error.

Ok, I have found a solution to my problem. There is this PHP SSL context option "verify_peer" which defaults to "true" which I think makes the server requests the client to provide a client certificate. So I set it to "false" and now Chromium is working with WSS.

There is still a question if Chromium (all WebKit browsers) should behave like this...

Thanks

I've been getting similar feedback but there's a UI policy behind that.
https://bugs.chromium.org/p/chromium/issues/detail?id=338306#c3

We might be able to show something more helpful on the console.

Filed bug 721318 for investigating this point.

Closing this bug.

@tyoshino@chromium.org you were 100% right about client cert but I don't understand how can it be possible to have HTTPS and WSS on the same machine, same address and same port?

> We might be able to show something more helpful on the console.
Yes it would be very welcomed to have some meaningful info in console. And I agree that taking it to UI has no much sense.

P.S. You could always try Firefox approach - it doesn't bother with lack of client cert and tries to connect without (and it succeeds). But some warning in console would be useful.

Re #16:

Yes. If you're using separate server softwares for HTTP and WebSocket, then it might be not feasible, but theoretically you can dispatch request to HTTP logic and WebSocket logic by looking into the header e.g. Upgrade.

Re #18:

Thanks for the input. I'll consult security folks if it's acceptable for Chrome.

#16 It's common to select the protocol by the path. See for example http://nginx.org/en/docs/http/websocket.html where WebSocket is implemented only on the /chat/ path.