ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED in Google Chrome

I recently had a similar issue in Chrome on Mac OS. It worked fine with Firefox, but started failing in Chrome and Safari after changing my corporate (AD) credentials -- I guess the issue was a mismatch between system creds and the keychain creds.

The solution for me was a reset of the private key(s) access permissions in the Keychain Access app.

To do the reset:

1. In Keychain Access app right-click each private key that fails and select "Get Info".
2. Go to "Access Control" tab and set "Allow all applications to access this item" -- click on that option even if it's already set. Then click Save Changes.
3. Refresh the website that fails and you should be prompted to enter keychain password -- enter it and select Allow Always.

We are experiencing the same problem. As Sean has reported, it seems that Chrome on Windows XP negotiates TLSv1.2 even though the operating system does not support SHA-2 (say, SHA-256 or SHA-384) hash function.

We found that Chrome fails when it receives "client certificate request" following SERVER HELLO. SERVER HELLO itself negotiates RC4-SHA1 (in our environment) which should succeeds. The problematic packet seems the "client certificate request" that includes SHA-2 (as well as SHA1) functions for hashes.

Invoking Chrome with "--enable-logging --log-level=0" outputs the following message: ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146893816

This is an Operating system error corresponding "NTE_BAD_ALGID" for CryptSignHash function: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx

Disabling TLSv1.2 on the server should fix the problem. But I think Chrome should prefer SHA1 on Windows XP.

I'm experiencing the same thing here with Windows7 client systems unable to authenticate with client certificates against some of our systems, but not others. The affected servers are running Apache Tomcat while the unaffected are running IIS7, though I'm hesitant to identify that difference as the culprit.

Anyone else seeing this?

EDIT:

I'm able to eliminate the problem by disabling TLSv1.2 on the server. Is anyone else able to replicate this experience?

I would also be interested to know whether anyone else is seeing this on anything but the Windows platform, as it's the only place it's happening here (same version OSX has no issues).

EDIT2:

Chrome Bug Report here: https://code.google.com/p/chromium/issues/detail?id=278370

EDIT3:

Should be working again in latest Chrome stable. Chrome 30 will have a more robust fix, but 29.x should also work now.