Opened 6 years ago
Closed 11 months ago
#1044 closed Bug / Defect (fixed)
pkcs11-id - Cannot deserialize id 19-'CKR_ATTRIBUTE_VALUE_INVALID'
| Reported by: | hjb | Owned by: | Samuli Seppänen |
|---|---|---|---|
| Priority: | major | Milestone: | release 2.4.10 |
| Component: | Certificates | Version: | OpenVPN 2.4.5 (Community Ed) |
| Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | pkcs-id, RFC7512 |
| Cc: |
Description
OS: Windows 7
OpenVPN 2.4.5
PKCS#11 IDs exported with option --show-pkcs11-ids using the RFC 7512 UIR scheme are not recognized by --pkcs11-id and throw an error message:
"PKCS#11: Cannot deserialize id 19-'CKR_ATTRIBUTE_VALUE_INVALID'"
IDs with the old scheme as exported with version 2.4.4 are still working.
There seems to be a bug ether with --show-pkcs11-ids or with --pkcs11-id. Or even both!?
Change History (6)
comment:1 Changed 5 years ago by
comment:2 Changed 5 years ago by
Looks related to #1075 (and there is more info in that ticket).
As a workaround, you could manually change the token to the format that is recognised.
comment:3 Changed 3 years ago by
| Milestone: | release 2.4.5 → release 2.4.10 |
|---|---|
| Owner: | set to Samuli Seppänen |
| Status: | new → assigned |
As far as I understand, this is a bug in pkcs11-helper - we have problems on Windows as well, and with 2.5_beta3, shipping a more recent (+patched) version of pkcs11-helper, things magically start working.
So, you might want to test the 2.5_beta3 test installer - if that works, please comment here. We currently plan to also release 2.4.10 with the new library, but only "if it works"...
comment:4 Changed 3 years ago by
So, can I have an update here? Is this fixed with the new pkcs11 library in 2.5.0 and 2.4.10? Can we close the ticket?
comment:5 Changed 11 months ago by
All official Windows releases (2.4.10+, 2.5, 2.6) consistently use the new RFC7512 serialization format by applying an unofficial patch (https://github.com/OpenSC/pkcs11-helper/pull/4).
We (try to) regularly sync this patch with the Fedora-version (https://src.fedoraproject.org/rpms/pkcs11-helper), they require "everything PKCS11" to be RFC7512-compliant.
I am facing this bug in both 2.4.5 and 2.4.6 with Yubikey and ePass2003. Is there any chance to get this fixed? I can sponsor a Yubikey token to the community.
Similar problem is also on Linux, where the special characters needs to be escaped manually.