xmlsectool can't find keys on eTokenPro

Rainer Hoerbe rainer at hoerbe.at
Tue Sep 19 09:42:28 EDT 2017


> Am 19.09.2017 um 09:22 schrieb Ian Young <ian at iay.org.uk>:
> 
> 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.

This seems to be the cause. `pkcs11-tool -cert` does list pubkeys as well.

> 
> 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.

keytool shows no objects on the token. Also, when I try to use the token with `openssl -engine pkcs11` it will not find the key (possibly I did not get the the PKCS11-URL format right?). The vendor’s SAC-tool will show the same label/alias as pkcs11-tool.

> 
> 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.

I tried to create a create certificate from the existing RSA key pair on the token. Spending quite a few hours I had no success so far. I do not want to re-create the key pair, because I want to replace pyff’s signing with xmlsectool because of xmldsig interop issues. pyff’s xmldsig library can create a signature just from the key pair, however, so I do not have certificates so far. Do you see any trivial option to tweak xmlsectool into using the public key instead of a x509 cert?


thanks, Rainer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170919/e7f70e70/attachment-0001.html>


More information about the users mailing list