Issue metadata
Sign in to add a comment
|
Logging on with Belgian eID fails with ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED
Reported by
wverhe...@gmail.com,
Apr 18 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Example URL: https://test.eid.belgium.be Steps to reproduce the problem: 1. Install the eID support software from https://eid.belgium.be 2. Using Google Chrome with a Belgian eID card in a smart card reader, go to https://test.eid.belgium.be 3. select eID certificate and enter PIN code What is the expected behavior? Google Chrome uses the eID card's certificates as provided by the eID middleware's tokend, and uses that to do a TLS-level certificate authentication to test.eid.belgium.be What went wrong? Google Chrome instead produces an ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED error. The attached file contains a net-internals export from a test session. Did this work before? Yes Chrome 56 (it stopped working after upgrading to 57) Chrome version: 57.0.2987.133 Channel: stable OS Version: OS X 10.12.4 Flash Version: we cannot reproduce this issue on either Windows or Linux; it appears to be macOS-specific. I'm one of the people behind the software on eid.belgium.be, in case that's relevant.
,
Apr 18 2017
I assume you mean you used the wrong account to post a bug, not that the ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED was the result of using the wrong account (i.e., that this is a valid bug report, and not user error).
,
Apr 18 2017
Yes, that's what I meant. Apologies if that wasn't clear.
,
Apr 19 2017
Sounds like it could be related to the new Sierra smartcard handling from issue 666796 . Can you get a debug log as described at https://www.chromium.org/for-testers/enable-logging ? Relevant part from netlog: t=8389 [st=16] +SSL_PRIVATE_KEY_OP [dt=21] --> hash = "SHA512" --> type = "RSA" t=8410 [st=37] -SSL_PRIVATE_KEY_OP --> net_error = -141 (ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED)
,
Apr 20 2017
I ran /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging --v=1 > chrome.log.txt 2>&1 The result of that is attached. Note that the Dutch error message "De bewerking can niet worden voltooid" translates to "The operation could not be completed".
,
Apr 20 2017
I notice that the error message mentions something about the padding. Did Chrome change their chosen padding type?
,
Apr 20 2017
It looks like both old and new use PKCS #1 padding, the only difference is the old CSSM version of SSLPlatformKey does the padding itself (RSA_add_pkcs1_prefix), the new SecKey version calls SecKeyCreateSignature with the appropriate param (eg SecKeyAlgorithmRSASignatureDigestPKCS1v15SHA512), which indicates that SecKeyCreateSignature takes the raw digest and is supposed to do the padding internally. Unless there's something subtle, it seems like the issue might be in how this particular middleware interacts with the new Apple apis rather than a Chrome problem?
,
Apr 25 2017
Thanks for the information mattm, this must be the issue indeed. We do not yet handle digests that are SHA512 hashes in our tokend. So if the previous hashes didn't mention they were sha512, we just signed them, while now we'll have to add a header and do the padding.
,
Apr 27 2017
Thanks for the confirmation. I'm going to mark this WontFix, but feel free to reply or open a new bug if needed.
,
May 4 2017
Just an update: We've updated our tokend to also support SHA512 hashes, and that seems to have fixed it, indeed. Thanks for the help, and sorry for the noise.
,
May 4 2017
Thanks for the update, and glad you were able to get it working! |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by wouter.v...@fedict.be
, Apr 18 2017