Server info:
SSL protocols: TLSv1.2 only, does not allow TLSv1, TLSv1.1 and SSLv3

Ciphers:
>>openssl ciphers -v 'HIGH:MEDIUM:!SSLv3:!kRSA'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(256)  Mac=SHA256
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256

And the certificate for the websock port is valid?
If you https:// to it does is it OK?

Could you provide a NetLog dump as described at https://dev.chromium.org/for-testers/providing-network-details ?

I would also like to reiterate the advice in comment #2. If you see an SSL error when connecting via https then it won't work with WebSockets either (and you may get more useful diagnostic information that way).

#2:
It works fine with https://.
PFA and log.

#4:
PFA.

Deleted: login_ok.json 194 KB

login_ok.json 194 KB View Download

Deleted: index_fail.json 855 KB

index_fail.json 855 KB View Download

Deleted: login.png 10.9 KB

	login.png 10.9 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

So it looks like the HTTPS server is running on port 443 but the wss server is running on port 4443?

I think your problem is probably that the server requests a client certificate, but the browser cannot provide a client certificate without user interaction. However, since the WebSocket is a subresource, the browser can't pop up a certificate chooser dialog, and so the connection fails.

In the log I see that the server requested a client certificate (ERR_SSL_CLIENT_AUTH_CERT_NEEDED) and then after that connection was aborted, which usually means that the browser was unable to select a client certificate by itself.

To give the opportunity for the user to select a client certificate, the browser needs to do a top-level navigation to the server port running the WebSocket. The best way to do this is run the WebSocket server on the same port that the HTML pages are served from. If that is not possible, an alternative would be to have a URL on the WebSocket server which can be accessed over HTTPS and redirects the user back to the main HTTPS server after giving the user an opportunity to select the client certificate. You could route the user to the page on port 4443 as part of the login process.

Cannot start HTTPS server and WSS server and both listen to same port 443.

Just like what you mentioned, WSS just a subresource inside of page, the Chrome will pop up certificate chooser dialog for web page, and then it should pickup the same certificate for subresource WSS. Is not it?
Like what Firefox does.

Took your suggestion, first I go to https://beasyer-server:4443 and it will pop up dialog and choose certificate, then go to https://beasyer-server/ui/index.html, and it works fine.

But we cannot ask user to manually handle this :(.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Issue seems to be out of TE scope as this requires HTTPS and WSS server setup. As developers are already looking into it adding TE-NeedsTriageHelp label to remove this bug from Triaging bucket. Please remove if not the case.

Thanks!

So Firefox considers a client certificate selection for beasyer-server:443 to also apply to beasyer-server:4443, and Chrome doesn't? That's interesting.

davidben@, can you comment on which behaviour is right here?

Assuming Chrome's current behaviour is correct, you can force the certificate selection by redirecting the user's browser to https://beasyer-server:4443/get-certificate (or whatever path you choose) and then back to https://beasyer-server/ui/index.html, but the user will see the certificate chooser twice.

I'm not sure "correct" is particularly well-defined. Mixing ports up is probably not a good plan, however. It's pretty common to have different behavior on different ports, e.g. issue #753756.

We actually do prompt for client certificates on subresources today, though I'd rather we did less of that. Prompting on subresources, notably cross-origin ones, introduces all kinds of room for UI confusion.

I'm going to mark this WontFix. There's no reason to assume the same ports are under the same control, and as such, no reason to consider authorization for one port to be acceptable for another port. As David says, prompting across-origin is problematic, and prompting for (authentication) on subresources is also undesired.

If this is an Enterprise situation, you can use AutoSelectCertificateForUrls ( https://www.chromium.org/administrators/policy-list-3#AutoSelectCertificateForUrls ) to reduce/eliminate these prompts.

at least it should be popup UI for cert selection.
but anyway, we have firefox which is working :)
also can load xxx:4443 in frame in same page, or suggest user to use the one working.