Bug 505200
Summary: | scep enrollment : cisco asa 5510 not working when ca is connected to nethsm | ||
---|---|---|---|
Product: | [Retired] Dogtag Certificate System | Reporter: | Chandrasekar Kannan <ckannan> |
Component: | SCEP | Assignee: | Deon Ballard <dlackey> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | urgent | ||
Version: | unspecified | CC: | benl, cfu, jgalipea, jmagne |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-02-24 17:32:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 443788 |
Description
Chandrasekar Kannan
2009-06-10 23:31:55 UTC
scep enrollment works just fine when the ca is not connected to nethsm 2000 router has 3des enabled ... (08:14:56) mgalgoci: you have the 3DES/AES feature enabled (08:15:01) ckannan: nice (08:15:18) mgalgoci: VPN-DES : Enabled (08:15:18) mgalgoci: VPN-3DES-AES : Enabled just reporting some findings: The nethsm log shows something like: 2009-06-29 13:41:32 [18436] t901b5792: pkcs11: 000008CD Application error: DES key parity wrong 2009-06-29 13:41:32 [18436] t901b5792: pkcs11: 000008CD < *phObject 0x00000000 2009-06-29 13:41:32 [18436] t901b5792: pkcs11: 000008CD < rv 0x00000013 (CKR_ATTRIBUTE_VALUE_INVALID) While NSPR debug log for the nfast pkcs11 module shows: -1839785072[8b13990]: C_UnwrapKey -1839785072[8b13990]: hSession = 0x8cd -1839785072[8b13990]: pMechanism = 0x9257070c -1839785072[8b13990]: hUnwrappingKey = 0x469 -1839785072[8b13990]: pWrappedKey = 0x87844c0 -1839785072[8b13990]: ulWrappedKeyLen = 256 -1839785072[8b13990]: pTemplate = 0x92570640 -1839785072[8b13990]: ulAttributeCount = 3 -1839785072[8b13990]: phKey = 0x87845cc -1839785072[8b13990]: CKA_CLASS = CKO_SECRET_KEY [4] -1839785072[8b13990]: CKA_KEY_TYPE = 0x13 [4] -1839785072[8b13990]: CKA_DECRYPT = CK_TRUE [1] -1839785072[8b13990]: mechanism = CKM_RSA_PKCS -1839785072[8b13990]: *phKey = 0x0 (CK_INVALID_HANDLE) -1839785072[8b13990]: rv = CKR_WRAPPED_KEY_INVALID According to Relyea: "It seems pretty clear. The nethsm does not like the key that SCEP is sending. DES keys have redundant bits which are set to parity values to detect if a bad key was transmitted. Softoken does not generally require the parity to be set correctly on input, but always makes sure DES keys have the proper parity on output." So far, we have tried unsetting all protection on the hsm: /opt/nfast/cknfastrc: CKNFAST_OVERRIDE_SECURITY_ASSURANCES=all and still failed in the same fashion. I don't know if there is a way to get the cisco router to produce more legit keys. This not CS bug. HSM does not accept DES keys with bad parity generated by Cisco router. Release notes: http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.1/html/Release_Notes/Release_Notes-Known_Issues-new.html Changing old ON_QA bugs to closed (since they've long since been published.) |