#442 CA throws exception while processing SCEP PKCSReq message when cert DB is in FIPS mode
Closed: migrated 2 years ago by dmoluguw. Opened 10 years ago by nkinder.

https://bugzilla.redhat.com/show_bug.cgi?id=825887 (Dogtag Certificate System)

Description of problem: SCEP enrollment fails when cert/key database in
/var/lib/pki-ca/alias is set to FIPS mode.

Version-Release number of selected component (if applicable): Found in pki-core
9.0.17 and 9.0.19.  NSS version is 3.13.4, JSS is 4.2.6-24, NSPR is 4.9-2

How reproducible: Can reproduce every time.

Steps to Reproduce:
1. Create CA and RA using pkicreate commands
2. Before configuring the CA, place CA database in FIPS mode, change password
to meet FIPS 140-2 guidelines.  Change password in /etc/CS.cfg to match.
3. Configure CA.  Note: Need to rename "Server-Cert cert-pki-ca" to some other
cert nickname as it fails overwriting when DB is in FIPS mode.

Actual results:
When SCEP enrollment takes place the debug logs for the CA throw the following
exception and stack trace:
[20/May/2012:22:23:30][http-9444-1]: failed to unwrap PKCS10
[20/May/2012:22:23:30][http-9444-1]: handlePKIMessage exception
com.netscape.cms.servlet.cert.scep.CRSEnrollment$CRSFailureException: Could not
unwrap PKCS10 blob: null
com.netscape.cms.servlet.cert.scep.CRSEnrollment$CRSFailureException: Could not
unwrap PKCS10 blob: null
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.unwrapPKCS10(CRSEnr
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.decodePKIMessage(CR
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.service(CRSEnrollme
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
        at com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFi
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContext
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVa
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proc
        at java.lang.Thread.run(Thread.java:679)
[20/May/2012:22:23:30][http-9444-1]: ServletException
javax.servlet.ServletException: Failed to process message in CEP servlet: Could
not unwrap PKCS10 blob: null

Expected results:
Would normally expect the messageData portion of the PKCSReq message to be
decrypted (as it does in non-FIPS mode), and the certificate issued.

Additional info:
With Jack and Deon's help, I was able to get the NSS database to do enhanced
logging when run from the CA.  The following C_UnwrapKey is logged at the time
the SCEP message is processed:
-1874453648[9c75930]: C_UnwrapKey
-1874453648[9c75930]:   hSession = 0x80000033
-1874453648[9c75930]:   pMechanism = 0x90460534
-1874453648[9c75930]:   hUnwrappingKey = 0xcf692af0
-1874453648[9c75930]:   pWrappedKey = 0x9cc4df0
-1874453648[9c75930]:   ulWrappedKeyLen = 256
-1874453648[9c75930]:   pTemplate = 0x90460444
-1874453648[9c75930]:   ulAttributeCount = 3
-1874453648[9c75930]:   phKey = 0x9b3383c
-1874453648[9c75930]:     CKA_CLASS = CKO_SECRET_KEY [4]
-1874453648[9c75930]:     CKA_KEY_TYPE = CKK_DES3 [4]
-1874453648[9c75930]:     CKA_DECRYPT = CK_TRUE [1]
-1874453648[9c75930]:       mechanism = CKM_RSA_PKCS
-1874453648[9c75930]:   *phKey = 0x1f
-1874453648[9c75930]:   rv = CKR_OK

The values for CKA_SENSITIVE and CKA_EXTRACTABLE are not set, so I assume the
token gets to set the defaults.  For a database in FIPS 140-2 mode, it must
assume that CKO_SECRET_KEY objects are default sensitive (or something like
that).  When the unwrap finishes, unwrapPKCS10's implementation calls
getDESKeyGenerator().clone() which according to the comments in the
implementation is designed to get a key replicated on another token.

Not 100% sure but from looking at modutil output it looks like maybe 3DES isn't
an advertised mechanism on the "NSS Certificate DB" token in the default,
non-FIPS case.  So the clone is required in order to copy the 3DES key to the
"NSS Generic Crypto Services" PKCS#11 token and do the decryption from there.

This breaks down however when the database is running in FIPS-140 mode.  In
that case, there's only one PKCS#11 token and it handles key storage and crypto
services.  What's more the key appears to be marked sensitive.

The clone() method appears to do C_GetAttributeValue, which is the next PKCS#11
call following the C_UnwrapKey:

-1874453648[9c75930]: C_GetAttributeValue
-1874453648[9c75930]:   hSession = 0x80000001
-1874453648[9c75930]:   hObject = 0x1f
-1874453648[9c75930]:   pTemplate = 0x904605c4
-1874453648[9c75930]:   ulCount = 1
-1874453648[9c75930]:     CKA_VALUE = [0x0] [-1]
-1874453648[9c75930]:   rv = CKR_ATTRIBUTE_SENSITIVE

...Which is a no-go because the key is sensitive in the FIPS mode database.  It
may well be sensitive with other HSMs though I have no external PKCS#11 token I
could attach to my CA to test that hypothesis.

Metadata Update from @nkinder:
- Issue assigned to awnuk
- Issue set to the milestone: UNTRIAGED

6 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.