I also have some Wireshark traces with the necessary session keys to look into the TLS setup

Deleted: chrome.pcapng 90.1 KB

chrome.pcapng 90.1 KB Download

Deleted: firefox-2.pcapng 110 KB

firefox-2.pcapng 110 KB Download

Deleted: sslkeys.txt 5.5 KB

sslkeys.txt 5.5 KB View Download

The server logs state that the request does not contain a user certificate, but lists the hash of the CA certificate included in the request.

I've done some more testing: Chrome 68 also fails to authenticate on macOS, but it works on Linux (Ubuntu 18.04).

No idea if client certs is Internals>Network>SSL or Internals>Network>Certificates.  Assuming the former.

I also looked at a wireshark trace of Chrome on Linux and could directly see one difference:

Windows: Chrome sends both the user certificate and the CA certificate
Linux: Chrome only sends the user certificate

That might point to the area of the problem. On the other hand, sending the CA certificate along should not be a problem, Firefox also does it. 

Hi, this sounds similar to  issue 855155 , does comment 11 there address it? https://bugs.chromium.org/p/chromium/issues/detail?id=855155#c11

That's unlikely, the server is a fully updated Windows 2016 server instance that was only created a few weeks ago, but I can check whether the update referenced in the Microsoft article is installed.

The website also doesn't always fail like in the other bug, other authentication flows (form-based, Kerberos (GSSAPI) and NTLM) all work without a problem. It's really the TLS setup when presenting the client certificate. According to the logs, the server thinks that there is no client certificate present.

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

A Gentle ping...

@mattm@chromium.org: Requesting you to can you please have a look in to it for further inputs on it.

Thanks..!

The issue seems to be out of scope for us to triage it further from our end as this is related to SSL certificate authentication with Microsoft ADFS, hence adding label "TE-NeedsTriageHelp" and requesting someone from "Network" team to have a look into this and help in further triaging.

Thanks!

To correct this point here:

> The TLS messages with the Certificate Verify from the client are slightly different

They differ only in the contents of the signature, which is, of course, expected to differ because the signature is different for each connection. If you gathered two traces in Firefox, you would see the same distinction.

The server appears to be resetting the connection after the CertificateVerify, so it seems unhappy with it for some reason. I manually verified the signature against the transcript, and it's just fine.


Honestly, I'm at a loss as to what could be different here. The certificates sent in the two pcaps are byte-for-byte identical. It's true that we discard the connection while waiting for the user prompt to resolve, but that shouldn't affect things with a correctly implemented TLS server.

Is there anything useful in the server logs? Look specifically for the ones corresponding to the second connection, the one where we actually present a certificate. For some reason, the server is just resetting the connection on us.

Ping reporter: can you please respond to c#12?

[steffen.muething]:  Last ping.  Can you please response to comment 12?

Closing due to lack of feedback.