Smartcard responds, but "getCertificate() failed: Error: no_certificates"

[minfrin]

Using an ACR38T-D1, and Aventra MyEID, and OpenSC v0.19.0, I get the following from the test app:

sign() clicked on Sat, 29 Dec 2018 12:05:49 GMT
Signing SHA-256: 413140d54372f9baf481d4c54e2d5c7bcf28fd6087000280e07976121dd54af2
Debug: hwcrypto.js 0.0.11 with Chrome native messaging extension 0.0.29/1.0.8.500
getCertificate() failed: Error: no_certificates

During the signing process the smartcard flashes to indicate that a signing attempt is taking place.

The key on the smartcard looks like this:

Private RSA Key [XXX]
Object Flags : [0x3], private, modifiable
Usage : [0x22E], decrypt, sign, signRecover, unwrap, nonRepudiation
Access Flags : [0xD], sensitive, alwaysSensitive, neverExtract
ModLength : 2048
Key ref : 1 (0x1)
Native : yes
Auth ID : 01

The code contains debug logging such as this below, however there are no instructions that I can see to confirm where to find this log. Using the debug log on Chrome shows up no obvious messages:

chrome-token-signing/host-osx/CertificateSelection.mm

Line 78 in 6e9b4c8

_log("certificate is non-repu: %u, requesting signing certificate %u, moving on to next token...", isNonRepudiation, forSigning);

Looking at the code, it looks like there are error paths where the error is dropped and replaced with the "no certificates" response, such as this line:

chrome-token-signing/host-osx/CertificateSelection.mm

Line 68 in 6e9b4c8

for (const PKCS11CardManager::Token &token : PKCS11CardManager(p11.path).tokens()) {

[metsma]

Here are instructions for logging
https://github.com/open-eid/chrome-token-signing/wiki/DeveloperTips#logging

[minfrin]

I eventually got the code up and running in a debugger to figure out what was going on.

I discovered the Globalsign client certificate that was used for testing did not have the nonRepudiation key usage present, even though the key did. This causes the certificates to be silently ignored, and sent me on a wild goose chase to discover why.

Certificates that are recognised but cannot be used should be listed but greyed out, with a tooltip (for example) to explain what is wrong with the certificate and why it cannot be selected. This will drastically improve the user experience.

[metsma]

I disagree, it will generate loads of user support calls and thats why we don't bother users with not needed information.
Estonia has 1,3M cards and 300k actively users and they all have one authentication certificate and one signing certificate.

[minfrin]

In a world where you're the only user of the code, sure. But in the EU, where there are many possible cards you might plug in, this makes life difficult for other people.

[metsma]

As far I know, all state issued cards have same scheme.
Authentication, signature (Finland even RSA and ECC Signature) and rare cases decryption certificate.
Latvia, Lithuania, Finland, Belgium and so on

[minfrin]

Having greyed out certs is one fix, but not the only fix. Another is to fix the error responses so that multiple error conditions don't all return the same code for different errors.

The single biggest barrier to adoption in security technology is the error handling - I constantly have to get code up onto the debugger to get the code to tell me something it should have just told me straight in an error message.

[martinpaljak]

For consumer technology I would say the opposite - it should just work, error messages that common people have zero ideas about (certificate types, key flags, what?) should be hidden if possible.

IIRC the scope of certificates listed by the plugin is specified to only include certificates with non-repudiation EKU.

Doing heuristics to map device usage to certificates is troublesome in the first place, presenting users with greyed out options would not really make it easier.

[minfrin]

Right now it doesn't just work.

You get no certificates listed when certificates are present, and instead of the error response telling you this is the case, you need to bring the code up on a debugger to figure this out.

It's bad enough sitting on the phone for two hours with tech support and escalated tech support at a major certificate authority who swear blind the non repudiation flag was present where it was not (tl;dr, certificate authority first and second line support have never heard of the non repudiation flag on a certificate, and no attempts at explaining how it worked got through).

If you want anyone to use this code, the error handling has to be fixed.

To can argue about the choice of fix all you like, I don't care either way. But it cannot be that multiple failures all give the same error code.

[kristelmerilain]

Thank you for the feedback.
Currently there are no plans to address this issue since a new Web eID project(https://github.com/web-eid) is in development, which will replace Chrome Token Signing in the near future.
Therefore I recommend opening a new issue in the web eID project and maybe we will find a solution there.