See StackOverflow conversation for more: http://stackoverflow.com/questions/18373699/err-ssl-client-auth-signature-failed-in-google-chrome

This may be a regression of  issue 90392 .
https://code.google.com/p/chromium/issues/detail?id=90392

sean.baker, ymmt2005:

Thank you for the bug report and the extra information in the StackOverflow
conversation.

I have some questions for you that will help me track down the problem.

1. Does the problem happen on Mac OS X?

2. Does the problem happen on Windows 7?

3. Can you provide the contents of the supported_signature_algorithms field in the
"client certificate request" message from the server? The official name of that
message is CertificateRequest or cerrificate_request. Do you see "sha256" in the
contents of supported_signature_algorithms in the "client certificate request"
message?

A workaround is to run chrome with the command-line option --ssl-version-max=tls1.1 

Note: the client authentication problem should be independent of the use of
HMAC-SHA256 cipher suites.

Thank you for your help.

1.) It does not happen on OSX.
2.) It does happen on Windows7.
3.) Supported Signature Algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA

Let me know what else you need - thanks!

Sean

sean.baker:

Thank you for the answers to my questions. They confirm your server supports SHA-256
signatures for client authentication.

Could you follow the instructions at

  http://www.chromium.org/for-testers/providing-network-details

and email a network event log to me? The network event log will contain the Windows
error code when Chrome asks the smart card to generate a SHA-256 signature for client
authentication. Thanks.

I will work on this bug today as my top priority.

Inbound

1) It does not happen on OSX.
2) It does not happen on Windows7 so far.
3) SHA512*RSA,DSA,ECDSA, SHA384*RSA,DSA,ECDSA, SHA256*RSA,DSA,ECDSA
   SHA224*RSA,DSA,ECDSA, SHA1*RSA,DSA,ECDSA, MD5*RSA

In addition, Chrome on Android also fails to use client cert on Samsung GalaxyS4 (Android 4.2.2).
Disabling TLSv1.2 resolves these problems.

ymmt2005:

Thank you for the answers to my questions.

What is the error code reported by Chrome on Android?

Chrome on Android uses a different SSL library (OpenSSL instead of NSS).
I would expect the TLS 1.2 implementation in OpenSSL to be more mature
than the TLS 1.2 implementation in NSS.

rsleevi: do you have any idea what might go wrong in Chrome on Android
when it does TLS 1.2 client authentication?

Chrome on Android displays "ERR_FAILED" only.
Can I see more detailed error code?

Same problem in Estonia with national ID-card (500 000+ card owners affected).

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36

Example URL:
N/A

Steps to reproduce the problem:
1. Need:
   a. Server with TLS 1.2 and require a client certificate. 
   b. Smart card containing certificate for (a). Smartcard which does not supprt SHA-2 hash algorithms
   c. Windows 7 machine running Chrome 29.0.1547.57.
2. Browse to site / URL in 1a.
3. Choose from available + matching certificates.

What is the expected behavior?
User is prompted to enter PIN (or password); client cert negotiation takes place.

What went wrong?
User is not prompted to enter a PIN, and nothing is Chrome log shows ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED

Did this work before? Yes 28.0.1500.95 

Chrome version: 29.0.1547.57  Channel: stable
OS Version: 7

Disabling TLS 1.2 on browser side helps.

+digit for Android SSL Client authentication question in #8.

(No comment was entered for this change.)

Here is my plan for this bug.

1. For Chrome 29, I will simply turn off TLS 1.2. My changelist is at
https://codereview.chromium.org/23442006/.

Before my change appears in Chrome 29, your workaround is to either
disable TLS 1.2 on your servers, or ask your Windows Chrome users to
run Chrome with --ssl-version-max=tls1.1.

2. I will develop a better workaround and the real fix using Chrome
Canary. I will announce here when I have a fix in Chrome Canary
for you to test.

digit, ppi: I may need your help to investigate the Android problem
reported by ymmt2005 in comment 7 and comment 9. Thanks.

ymmt2005: I filed  issue 280275  for the TLS 1.2 client authentication problem
on Android that you reported.

Chrome uses different SSL libraries on Windows and Android, so the underlying
cause of the problem on Android is likely to be different.

I will use this bug report for the problem on Windows.

kerz: I will request approval of the CL https://codereview.chromium.org/23442006/
for the Chrome 29 1547 branch.

wtc: I see.

I have mailed a network dump file gathered in Windows XP to you.

------------------------------------------------------------------------
r219882 | wtc@chromium.org | 2013-08-28T01:54:03.272844Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/ssl/ssl_config_service.cc?r1=219882&r2=219881&pathrev=219882

Turn off TLS 1.2 to work around the TLS 1.2 client authentication
problems on Android and Windows.

R=agl@chromium.org
BUG=278370
TEST=net_unittests

Review URL: https://chromiumcodereview.appspot.com/23442006
------------------------------------------------------------------------

Update from Estonia situation.
Problem is with older 1K RSA cards which does not support SHA-256. Problem is not with TLS 1.2 since that allows SHA-1 usage. For example IE 11 which supports also TLS 1.2 works with same old 1K RSA card on same site.
http://en.wikipedia.org/wiki/Transport_Layer_Security

(No comment was entered for this change.)

I found that it is the Chrome debug log that contains the error info
I need for this bug.

If you can reproduce this bug, please follow these instructions:

    http://www.chromium.org/for-testers/enable-logging

and email me the chrome_debug.log file.

To avoid sending me too much info, you can search for
"ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED" and just send me those lines.
There should be only one or two such lines in chrome_debug.log. Those
log lines will tell me what the "OS error" is.

Thank you.

jaan.murumets:

Thank you for the info you provided in comment 10 and comment 18.

In comment 10 you said:

  ... nothing is Chrome log shows ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED

I guess you meant "nothing in Chrome log shows ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED".
Can you confirm that? Does Chrome or the Chrome log show any error code?

Can you follow the instructions in comment 5 and comment 20 and email the network
event log and the chrome_debug.log file to me? Thanks.

 Issue 281464  has been merged into this issue.

I wanted to write:
What went wrong?
User is not prompted to enter a PIN, and nothing is showed, Chrome log shows ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED


Chrome log:

[1340:2364:0829/033123:ERROR:platform_thread_win.cc(127)] NOT IMPLEMENTED
[1808:1764:0829/033124:ERROR:textfield.h(173)] NOT IMPLEMENTED
[1808:3960:0829/033127:VERBOSE1:proxy_service.cc(1135)] Failed configuring with PAC script, falling-back to manual proxy servers.
[1808:3960:0829/033127:VERBOSE1:proxy_service.cc(1135)] Failed configuring with PAC script, falling-back to manual proxy servers.
[1808:1764:0829/033128:VERBOSE1:ssl_client_auth_handler.cc(63)] 0708DAA0 CertificateSelected 08279800
[1808:3960:0829/033128:VERBOSE1:ssl_client_auth_handler.cc(72)] 0708DAA0 DoCertificateSelected 08279800
[1808:3960:0829/033128:VERBOSE1:ssl_client_auth_handler.cc(72)] 0708DAA0 DoCertificateSelected 00000000
[1808:3960:0829/033134:ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146435041


From smartcard driver log:

CALG_SHA_256 key size 1024 unsupported 
return error 0x80100022

driver returns correctly since that 1K RSA Estonian ID-card does not support SHA-256

------------------------------------------------------------------------
r220433 | wtc@chromium.org | 2013-08-29T23:41:33.556385Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/ssl/ssl_config_service.cc?r1=220433&r2=220432&pathrev=220433

Revert 219882 "Turn off TLS 1.2 to work around the TLS 1.2 clien..."

219882 has been tested in 31.0.1614.0 (Official Build 220153) canary.

> Turn off TLS 1.2 to work around the TLS 1.2 client authentication
> problems on Android and Windows.
> 
> R=agl@chromium.org
> TEST=net_unittests
> 
> Review URL: https://chromiumcodereview.appspot.com/23442006

TBR=wtc@chromium.org
BUG=278370,280275

Review URL: https://codereview.chromium.org/23559012
------------------------------------------------------------------------

------------------------------------------------------------------------
r220595 | wtc@chromium.org | 2013-08-30T15:52:17.933415Z

Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/tls12backuphash.patch?r1=220595&r2=220594&pathrev=220595
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/ssl/ssl3con.c?r1=220595&r2=220594&pathrev=220595
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/ssl/sslimpl.h?r1=220595&r2=220594&pathrev=220595
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/applypatches.sh?r1=220595&r2=220594&pathrev=220595
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/README.chromium?r1=220595&r2=220594&pathrev=220595

On Windows, prefer to generate SHA-1 signatures for TLS 1.2 client
authentication if the client private key is in a CAPI service provider.

R=rsleevi@chromium.org,agl@chromium.org
BUG=278370
TEST=will require manual testing by the bug reporter.

Review URL: https://chromiumcodereview.appspot.com/23545010
------------------------------------------------------------------------

sean.baker, ymmt2005, jaan.murumets:

Could you please verify my fix for this bug using Chrome Canary?

Here are the steps.

1. Install Chrome Canary on Windows. Chrome Canary is installed
side-by-side to your primary Chrome installation, so that you can
run them independently.

2. Start up Chrome Canary. Type "about:version" in the location bar.
Verify that the version is 31.0.1620.1 or later.

3. Visit your website that requires TLS client authentication. Please
re-enable TLS 1.2 on the website if you disabled TLS 1.2 before to
work around this bug.

4. If the client authentication succeeds, click the lock icon and
select the "Connection" tab in the drop-down dialog. Make sure it says
"This connection uses TLS 1.2."

Please report success or failure here. Thank you!

Success using hardware certs and TLS v1.2 under Windows 7 and Canary 31.0.1620.1.

Much appreciated!

Any idea yet when we might see this in stable?

Thanks again!

(No comment was entered for this change.)

------------------------------------------------------------------------
r220997 | wtc@chromium.org | 2013-09-03T19:19:32.921303Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1547/src/net/ssl/ssl_config_service.cc?r1=220997&r2=220996&pathrev=220997

Merge 219882 "Turn off TLS 1.2 to work around the TLS 1.2 client..."

> Turn off TLS 1.2 to work around the TLS 1.2 client authentication
> problems on Android and Windows.
> 
> R=agl@chromium.org
> BUG=278370
> TEST=net_unittests
> 
> Review URL: https://chromiumcodereview.appspot.com/23442006

TBR=wtc@chromium.org

Review URL: https://codereview.chromium.org/23503030
------------------------------------------------------------------------

kareng: I'm requesting to merge r220595 (see comment 25) to branch 1599 for Chrome 30.

The CL is in Chrome Canary 31.0.1620.1 and has been verified by sean.baker in
comment 27. Thank you.

(No comment was entered for this change.)

wtc:

Success using client certs and TLS v1.2 under Windows XP SP3 and Canary 31.0.1620.1.

Thank you very much!

Unfortunately our problem remains with Canary 31. Maybe that certificate private key location detection (mentioned in readme) is not working for Estonian ID-card?

* On Windows, prefer to generate SHA-1 signatures for TLS 1.2 client authentication if the client private key is in a CAPI service provider. 


Chrome log:
[4744:4480:0904/054951:ERROR:desktop_root_window_host_win.cc(690)] NOT IMPLEMENTED
[4744:1696:0904/054955:INFO:dhcp_proxy_script_adapter_fetcher_win.cc(263)] Error fetching PAC URL from DHCP: 2
[4744:4036:0904/054955:INFO:dhcp_proxy_script_adapter_fetcher_win.cc(263)] Error fetching PAC URL from DHCP: 2
[4744:4480:0904/054955:VERBOSE1:one_click_signin_helper.cc(1043)] [0904/054955:VERBOSE1:texture_image_transport_surface.cc(385)] Allocating new backbuffer texture
[4744:4480:0904/054955:ERROR:chrome_views_delegate.cc(158)] NOT IMPLEMENTED
[4744:4480:0904/055002:VERBOSE1:ssl_client_auth_handler.cc(63)] 0819B200 CertificateSelected 0CD6F000
[4744:2740:0904/055002:VERBOSE1:ssl_client_auth_handler.cc(72)] 0819B200 DoCertificateSelected 0CD6F000
[4744:2740:0904/055002:VERBOSE1:ssl_client_auth_handler.cc(72)] 0819B200 DoCertificateSelected 00000000
[4744:2740:0904/055028:ERROR:nss_ssl_util.cc(194)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146435041

From driver log:

04.09.13 05:50:28 [SxS\Application\chrome.exe][PID: 4744][CardSignData:2205] Hash to sign: 0a a8 c4 06 d9 da 28 63 25 45 0c dd 66 6c db 36 cb d5 5c f3 47 a2 2b 88 91 88 23 b3 a5 c2 87 41  with size: 32 
04.09.13 05:50:28 [SxS\Application\chrome.exe][PID: 4744][CardSignData:2230] CALG_SHA_256 key size 1024 unsupported 
04.09.13 05:50:28 [SxS\Application\chrome.exe][PID: 4744][ret:124] return error 0x80100022

jaan.murumets: can you go to about:version in the Canary, report the version number, and try once more?

I've merged r220595 (see comment 25) to branch 1599 for Chrome 30:
https://src.chromium.org/viewvc/chrome?revision=221227&view=revision

This bug needs to stay open until I have fixed the problem for Estonian ID-card.

jaan.murumets: can you find out whether Internet Explorer also generates the message
"[CardSignData:2230] CALG_SHA_256 key size 1024 unsupported" in the driver log?

This will tell us whether Internet Explorer tries to sign a SHA-256 hash first and
then falls back on signing a SHA-1 hash, or it somehow detects whether the card can
sign a SHA-256 hash.

Do you know how I can detect if an Estonian ID-card can sign a SHA-256 hash, without
actually signing a SHA-256 hash? Based on the source code in
https://svn.eesti.ee/projektid/idkaart_public/trunk/minidriver/esteidcm.cpp , it
seems that the only way to detect is to actually sign :-(

Is there a way for me to perform the equivalent of this check using Windows
functions?

    if(scard.getCardVersion() < EstEidCard::VER_1_1)

Do you know why esteidcm.cpp doesn't perform that check when signing CALG_SHA_224?

------------------------------------------------------------------------
r221227 | wtc@chromium.org | 2013-09-04T18:04:27.334596Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/patches/applypatches.sh?r1=221227&r2=221226&pathrev=221227
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/README.chromium?r1=221227&r2=221226&pathrev=221227
   A http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/patches/tls12backuphash.patch?r1=221227&r2=221226&pathrev=221227
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/ssl/ssl3con.c?r1=221227&r2=221226&pathrev=221227
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/ssl/sslimpl.h?r1=221227&r2=221226&pathrev=221227

Merge 220595 "On Windows, prefer to generate SHA-1 signatures fo..."

> On Windows, prefer to generate SHA-1 signatures for TLS 1.2 client
> authentication if the client private key is in a CAPI service provider.
> 
> R=rsleevi@chromium.org,agl@chromium.org
> BUG=278370
> TEST=will require manual testing by the bug reporter.
> 
> Review URL: https://chromiumcodereview.appspot.com/23545010

TBR=wtc@chromium.org

Review URL: https://codereview.chromium.org/23880004
------------------------------------------------------------------------

Chrome version we tested is 31.0.1621.1

We can test with IE as well, it takes some time here. I will post results later.

https://svn.eesti.ee/projektid/idkaart_public/trunk/minidriver/esteidcm.cpp is indeed Estonian ID-card driver source.

SHA-256 has been banned in driver for old card because there card is tested APDU level. Old card support up to SHA-224 only on APDU level (longer APDU command will not perform).

jaan.murumets:

Do the 1K RSA Estonian ID-cards work on Mac OS X or Linux? If so, I think
Chrome should also have problem using those cards for TLS 1.2 client
authentication on Mac OS X and Linux because the inability to use SHA-256
seems to come from the card itself rather than the Windows smartcard minidriver
for the card.

With this assumption, the workaround I am implementing for this card will
be cross-platform rather than Windows only.

------------------------------------------------------------------------
r221609 | wtc@chromium.org | 2013-09-06T06:40:03.479674Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/ssl/sslimpl.h?r1=221609&r2=221608&pathrev=221609
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/README.chromium?r1=221609&r2=221608&pathrev=221609
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/tls12backuphash.patch?r1=221609&r2=221608&pathrev=221609
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/ssl/ssl3con.c?r1=221609&r2=221608&pathrev=221609

Prefer to generate SHA-1 signatures for TLS 1.2 client authentication if
the client private key is a 1024-bit RSA or DSA key.

Older Estonian ID cards with 1024-bit RSA keys cannot sign SHA-256
hashes.

1024-bit DSA keys were formerly specified to be used with SHA-1 only.

R=agl@chromium.org,rsleevi@chromium.org
BUG=278370
TEST=manual testing by someone who has an older Estonian ID card

Review URL: https://chromiumcodereview.appspot.com/23596013
------------------------------------------------------------------------

We tried on OSX with latest Canary chrome and overall result was same. On OSX Estonian ID card driver does not have SHA-256 error code written and therefore error will come from PCSCD level.

Chrome log:
[42612:2307:0906/151833:VERBOSE1:ssl_client_auth_handler.cc(63)] 0x1dd9d0 CertificateSelected 0x132dbe20
[42612:25859:0906/151833:VERBOSE1:ssl_client_auth_handler.cc(72)] 0x1dd9d0 DoCertificateSelected 0x132dbe20
[42612:25859:0906/151833:VERBOSE1:ssl_client_auth_handler.cc(72)] 0x1dd9d0 DoCertificateSelected 0
[42612:25859:0906/151834:ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2147416054

PCSCD log:
APDU: 00 88 00 00 33 30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 0F 99 8A 6B A1 D8 50 66 02 06 68 87 3B 2D 04 8A 51 97 C6 F6 C8 FA 55 75 67 1A C1 E6 C0 77 86 02 
SW: 67 00

67 00 APDU error means:
Response data has incorrent length, data field is superfluous, Le is superfluous


Checked with IE11 as well and IE11 starts with SHA-1 to TLS 1.2 server. From driver log:

06.09.13 04:19:17 [Explorer\IEXPLORE.EXE][PID: 4748][CardSignData:2219] CALG_SHA1 key size 1024 with OID: TRUE 
06.09.13 04:19:19 [Explorer\IEXPLORE.EXE][PID: 4748][CardSignData:2303] Signed hash: 73 cb 1e 62 ee cd 11 b4 36 3e 87 83 2d 1a fc fa 77 1f 6d 3f 13 54 f3 a2 b9 c8 3d 96 7e 58 97 4c a3 68 25 d9 26 f6 e3 d4 a9 f7 86 d5 8d 09 af 21 66 7d 16 aa d2 0a 5d a9 c5 09 66 96 13 10 23 61 89 1a 37 77 51 1c 58 65 71 78 ba 80 5c 45 f1 d4 f7 60 b5 1f a6 bb 6b 88 21 9a 80 f1 dc df 21 53 dd e7 1f ac a2 ea 3f 28 53 af ac e8 c1 8c ae 0d e5 9a cd 05 42 e7 5b e2 f6 96 8c f4 67 1e d1 5e  with size: 128 
06.09.13 04:19:19 [Explorer\IEXPLORE.EXE][PID: 4748][ret:120] return OK

jaan.murumets: thank you very much for the info.

Your test result on OS X confirms that my workaround for the 1K RSA Estonian ID card
must be cross-platform.

Your test result with IE11 shows IE11 doesn't try the SHA-256 signature first, although
we still don't know how IE11 determines which hash function to use.

jaan.murumets: please verify my second bug fix using Chrome Canary on
Windows and Mac OS X.

sean.baker, ymmt2005: it would be nice if you could verify that my
second bug fix still works for you on Windows.

Here are the steps.

1. Install Chrome Canary. Chrome Canary is installed side-by-side to
your primary Chrome installation, so that you can run them independently.

2. Start up Chrome Canary. Type "about:version" in the location bar.
Windows: verify that the version is 31.0.1625.2 or later.
Mac OS X: verify that the version is 31.0.1625.0 or later.

3. Visit your website that requires TLS client authentication. Please
re-enable TLS 1.2 on the website if you disabled TLS 1.2 before to
work around this bug.

4. If the client authentication succeeds, click the lock icon and
select the "Connection" tab in the drop-down dialog. Make sure it says
"This connection uses TLS 1.2."

Please report success or failure here. Please report the Chrome Canary
version from Step 2. Thank you!

For my use case (server - Tomcat w/ TLS 1.2; client - HW PIV using Chrome)...

Windows 31.0.1625.2 - SUCCESS
OSX 10.8 31.0.1625.0 - SUCCESS

Thanks again guys!

wtc: Canary still works nicely using TLS 1.2.

Windows: 31.0.1625.2

Re: comment #27: sean.baker asked:
> Any idea yet when we might see this in stable?

The next Chrome 29 Stable update will disable TLS 1.2 to work around this bug
and the related  bug 280275  (for Android). Unfortunately I don't know when the
next Chrome 29 Stable update will be released.

I am focusing on fixing the bug in Chrome 30 (which is now on the Beta channel).
So, the worst case is that this bug won't be fixed on the Stable channel until
Chrome 30 is released to the Stable channel.

Using the following public info:
- Chrome 29 was released to the Stable channel on Aug. 20 (Windows, Mac, Linux)
  and Aug. 21 (Android).
- Chrome usually has a six-week (42 days) release cycle.
I estimate that Chrome 30 will be released to the Stable channel around Oct. 1
(Windows, Mac, Linux) and Oct. 2 (Android).

Tested with 31.0.1625.2

Everything seems ok now for TLS 1.2

Tested with old 1K card, driver log:

10.09.13 01:17:58 [SxS\Application\chrome.exe][PID: 3632][CardSignData:2205] Hash to sign: a8 2c f4 87 db c3 e0 b0 93 2a 01 98 9e b5 06 6d ff 77 da d2  with size: 20 
10.09.13 01:17:58 [SxS\Application\chrome.exe][PID: 3632][CardSignData:2219] CALG_SHA1 key size 1024 with OID: TRUE 

Tested with new 2K card, driver log:

10.09.13 01:22:05 [SxS\Application\chrome.exe][PID: 4444][CardSignData:2205] Hash to sign: 6a 76 b2 de 6e a4 47 8f 66 4a ba 31 5f 9e 93 d9 9c 38 14 28 04 e1 8e c4 62 3c 9b 53 39 e8 d3 b1  with size: 32 
10.09.13 01:22:05 [SxS\Application\chrome.exe][PID: 4444][CardSignData:2233] CALG_SHA_256 key size 2048 


How you determine which SHA to use? By certificate key size? For Estonian situation it is ok to determine by key size.

PS. 50% times 31.0.1625.2 crashed after successful authentication. It maybe related to fact that on our testsite we use selfsigned SSL cert, crash happens after we choose "proceed anyway" button. We can collect more data for that crash if needed, separate ticket?

jaan.murumets: thank you for testing the second fix.

Since this bug report is already very long (47 comments so far),
please open a new bug report for the crash. Please opt in to
"Automatically send usage statistics and crash reports to Google"
under Settings > Privacy (you need to click "Show advanced settings..."
to see Privacy). Then, in that bug report, include your crash report
IDs. I will also look for your crashes in our crash server. Thanks.

The way I determine which hash function to use is described in
comment 40. It is indeed based on key type and key size only.

Tried today to reproduce crash with newer 31.0.1627.2 but 1627 did not crash. 

jaan.murumets: thank you for the info. When Chrome crashed yesterday, did the
entire browser or just one browser tab crash?

------------------------------------------------------------------------
r222724 | wtc@chromium.org | 2013-09-12T05:59:33.518627Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/tls12backuphash.patch?r1=222724&r2=222723&pathrev=222724
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/ssl/ssl3con.c?r1=222724&r2=222723&pathrev=222724

The NSS client auth (as opposed to NSS_PLATFORM_CLIENT_AUTH) also needs
to check if the backup handshake hash should be used.

R=agl@chromium.org,rsleevi@chromium.org
BUG=278370
TEST=none

Review URL: https://chromiumcodereview.appspot.com/23880010
------------------------------------------------------------------------

Whole browser crashed.

kareng: I am requesting to merge r221609 and r222724 to branch 1599 for Chrome 30.

r221609 (see comment 40) has been in Canary since 31.0.1625.0 and has been verified
by the three affected users.

Note: one user (jaan.murumets) reported a crash of the browser process in 31.0.1625.2
but the crash could not be reproduced in 31.0.1627.2. So I am assuming it was an
unrelated crash.

r222724 (see comment 51) is a small cleanup of r221609. It is expected to be in
Canary tomorrow.

ok i'll approve now but pls keep an eye on things.

------------------------------------------------------------------------
r223079 | wtc@chromium.org | 2013-09-13T18:15:11.780154Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/ssl/sslimpl.h?r1=223079&r2=223078&pathrev=223079
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/README.chromium?r1=223079&r2=223078&pathrev=223079
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/patches/tls12backuphash.patch?r1=223079&r2=223078&pathrev=223079
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/ssl/ssl3con.c?r1=223079&r2=223078&pathrev=223079

Merge 221609 "Prefer to generate SHA-1 signatures for TLS 1.2 cl..."

> Prefer to generate SHA-1 signatures for TLS 1.2 client authentication if
> the client private key is a 1024-bit RSA or DSA key.
> 
> Older Estonian ID cards with 1024-bit RSA keys cannot sign SHA-256
> hashes.
> 
> 1024-bit DSA keys were formerly specified to be used with SHA-1 only.
> 
> R=agl@chromium.org,rsleevi@chromium.org
> BUG=278370
> TEST=manual testing by someone who has an older Estonian ID card
> 
> Review URL: https://chromiumcodereview.appspot.com/23596013

TBR=wtc@chromium.org

Review URL: https://codereview.chromium.org/23889028
------------------------------------------------------------------------

------------------------------------------------------------------------
r223081 | wtc@chromium.org | 2013-09-13T18:17:01.620210Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/patches/tls12backuphash.patch?r1=223081&r2=223080&pathrev=223081
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/net/third_party/nss/ssl/ssl3con.c?r1=223081&r2=223080&pathrev=223081

Merge 222724 "The NSS client auth (as opposed to NSS_PLATFORM_CL..."

> The NSS client auth (as opposed to NSS_PLATFORM_CLIENT_AUTH) also needs
> to check if the backup handshake hash should be used.
> 
> R=agl@chromium.org,rsleevi@chromium.org
> BUG=278370
> TEST=none
> 
> Review URL: https://chromiumcodereview.appspot.com/23880010

TBR=wtc@chromium.org

Review URL: https://codereview.chromium.org/23851032
------------------------------------------------------------------------

shall i close this bug wtc@? any way for QA to verify all is good?

Yes, this bug is fixed. Please have QA contact me about verifying the bug fix.

Yesterday (Oct. 1) Chrome 30.0.1599.66 was released to the Stable channel for
Windows, Mac, and Linux. If you are not using client certificates on Android,
you can re-enable TLS 1.2 on your servers now.

I tested Chrome 30.0.1599.66 on Ubuntu 13.04 agains an Apache server 2.2.22 with 

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !AES128 !RC4 !CAMELLIA !SEED !SHA1"

and did not work. Opera 12.16 work fine... just said that to prove that the server is working.

I must change something in Chrome to work with TLSv1.2 servers or is suppose works out the box?

Here (https://cc.dcsec.uni-hannover.de/) I can see that my Chrome 30.0.1599.66 support DHE-RSA-AES256-SHA256 and https://www.ssllabs.com/ssltest/index.html show that my server support that cipher too, so is not a problem related to the cipher I think.

I believe, on Linux, we require a new enough version of your system NSS library for TLS 1.2. TLS 1.2 support was added to NSS in 3.15.1 which looks like it's slated to be in Ubuntu 13.10.

http://packages.ubuntu.com/saucy/libnss3

Thanks David, I tested on Ubuntu 13.10 and it works.