xmlsectool can't find keys on eTokenPro

[Ian Young]

> On 18 Sep 2017, at 22:47, Rainer Hoerbe <rainer at hoerbe.at> wrote:
> 
> When I try to sign with xmlsectool, it does not find the objects:

You say that you "can list key and cert", referencing this output:

> Private Key Object; RSA 
>  label:      test
>  ID:         01
>  Usage:      decrypt, sign, unwrap
> Public Key Object; RSA 2048 bits
>  label:      test
>  ID:         01
>  Usage:      encrypt, verify, wrap

There is no certificate there, just the two parts of an RSA keypair (private key and public key). Here's what I see with a token that does work with XMLSecTool:

> Certificate Object, type = X.509 cert
>   label:      key10
>   ID:         6b65793130
> Public Key Object; RSA 2048 bits
>   label:      key10
>   ID:         6b65793130
>   Usage:      encrypt, verify


Note that the first object is of a different kind than in your case. That may be significant.


> ERROR XMLSecTool - Unable to recover key entry from PKCS11 store
> java.security.cert.CertificateException: unknown type of key entry in keystore
> 	at net.shibboleth.tool.xmlsectool.CredentialHelper.getCredentialFromKeystore(CredentialHelper.java:212) ~[xmlsectool-2.0.0.jar:na]
> 	at net.shibboleth.tool.xmlsectool.CredentialHelper.getPKCS11Credential(CredentialHelper.java:179) ~[xmlsectool-2.0.0.jar:na]
> 	at net.shibboleth.tool.xmlsectool.XMLSecTool.getCredential(XMLSecTool.java:901) [xmlsectool-2.0.0.jar:na]
> 	at net.shibboleth.tool.xmlsectool.XMLSecTool.main(XMLSecTool.java:148) [xmlsectool-2.0.0.jar:na]


At this point, XMLSecTool is looking at the KeyStore.Entry corresponding to the alias you provided.

Examining the code, though, there a are a couple of possibilities.

One of them, unfortunately, is that no such KeyEntry was found (that would be a bug). You could try a completely different alias to see if you get the same result; if so, please file a JIRA case.

The other possibility is that the KeyEntry was found, but it was not one of the types of KeyEntry that XMLSecTool knows how to deal with. It can handle PrivateKeyEntry and TrustedCertificateEntry. What appears in the "keystore" depends on the PKCS11 bridge and to a certain extent to the native drivers as well, so there's a lot of variation and it's possible we haven't covered one. It's also possible that this is a result of your not having a certificate object on the token after all, just a private key (which I think results in a SecretKeyEntry rather than a PrivateKeyEntry). XMLSecTool (currently) requires you to have something it can extract a certificate from.

One thing you might try is to list the keystore entries with keytool rather than pkcs11-tool. That way you'll get a more direct indication of what the stack has turned the objects on the token into in Java keystore terms; the results of this can be surprising.

Let me know if you can make progress based on the above. If that's not possible, I guess I'd have to put it down to "every ^*^&*^&! token is different" and ask you to consider if you might have a spare token you could mail me that I can use to try and debug this with.

Cheers,

    -- Ian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170919/bf769c8f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3563 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20170919/bf769c8f/attachment.p7s>