In your case the token returns the error during the sign operation. It's hard to guess the reason, as the error code is generic and the call stack itself doesn't reveal anything as well.

The first thing to do is to try the latest version of SecureBlackbox. I see that you have a license for version 12, and probably are using this version. Meanwhile we introduces different improvements in versions 13 and 14, some of which improve compatibility with various hardware.

So you are welcome to install and test the evaluation version of SecureBlackbox 14 to see if the problem persists. If the problem is gone, then upgrading would be the right solution. If the problem persists, we would try to investigate it, yet if any changes are required, they would go only to the version 15.

On a side note it would help a lot if you used CODE button located above the text entry box (alternatively you can write [ CODE ] and [ /CODE ] tags by hand) to mark the beginning and the end of the code blocks in your messages. This would enable syntax highlighting and line numbering on the code and make it easier for analysis.

marcelo wrote:
I try your suggestion, use algorithm SHA1, but it doesn't work.

Are you getting the same error?

Quote

marcelo wrote:
I saw that the certificate usage is "Non repudiation", but i can sign a file with this certificate using dike. Any ideas?

The key usage should not be relevant in your case. It's some device or driver glitch. I don't know what Dike is, but are you sure that they use PKCS#11 interface and not CryptoAPI to access the device?

marcelo wrote:
On the same device i have another certificate, and thre's no error signing with this one.

Hmm. Could you please insert the check of the value of TElX509Certificate.PrivateKeyExists property of the certificate which you are trying to use? It can be that the private key is not properly associated with the certificate.

Quote

marcelo wrote:
Dike is a Italian sign program. I think it use PKCS#11 but i'm not so sure.

Let's put it differently - do you need to specify the path to the PKCS#11 driver in this Dike application? If not, then it works via CryptoAPI. In this case you also can try accessing the device via CryptoAPI (TElWinCertStorage) and see if signing works this way.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.