Opened 13 years ago
Closed 13 years ago
#10172 closed defect (invalid)
Bug in engine_pkcs11
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | general | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
Hello,
I think I've found a bug in the OpenSSL engine_pkcs11.
The slot_index supplied from the command line to OpenSSL and actually directed to engine_pkcs11 is actually incorrectly parsed by the latter which treats it as if it were the slot_id.
Most pkcs#11 implementations assume slot_index = slot_id, so there're no issues in these cases. However some implementations (for example the nCipher Hardware Security Modules product line) do not return (in C_GetSlotInfo) incremental slot ids starting from 0.
For example to access slot#0 with such devices, I need to issue something like:
openssl req -config ./openssl.cnf -new -out ncipher.pem -days 365 -engine pkcs11 -keyform engine -key slot_761406613
That could be easily corrected by checking the slot_index supplied against the array index rather than the array value returned by C_GetSlotInfo.
Consider that in no way, the user is supposed to know the slot_ids. They're internal values to be treated as opaque pointers that the library gives to the driving engine and you later return them to address slots (i.e. typically in C_OpenSession or C_GetSlotInfo)
If you need further information, please reach me at the following address: gb@…
Kind Regards, Giuliano Bertoletti
WrongTrac.