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 org.mozilla.jss.crypto.SymmetricKey$NotExtractableException
[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(CRSEnrollment.java:1109)
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.decodePKIMessage(CRSEnrollment.java:564)
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.service(CRSEnrollment.java:307)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFilter.java:176)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        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.