8000 CA throws exception while processing SCEP PKCSReq message when cert DB is in FIPS mode · Issue #1013 · dogtagpki/pki · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

CA throws exception while processing SCEP PKCSReq message when cert DB is in FIPS mode #1013

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pki-bot opened this issue Oct 2, 2020 · 3 comments
Labels
Milestone

Comments

@pki-bot
Copy link
pki-bot commented Oct 2, 2020

This issue was migrated from Pagure Issue #442. Originally filed by nkinder (@nkinder) on 2012-12-10 22:31:35:


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
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(CRSEnr
ollment.java:1109)
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.decodePKIMessage(CR
SEnrollment.java:564)
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.service(CRSEnrollme
nt.java:307)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
licationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
FilterChain.java:206)
        at com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFi
lter.java:176)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
licationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
FilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
Valve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContext
Valve.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(StandardEngineVa
lve.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.proc
ess(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" PKCS11 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 PKCS11 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 PKCS11
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 PKCS11 token I
could attach to my CA to test that hypothesis.
@pki-bot pki-bot added this to the UNTRIAGED milestone Oct 2, 2020
@pki-bot
Copy link
Author
pki-bot commented Oct 2, 2020

Comment from nkinder (@nkinder) at 2017-02-27 14:03:59

Metadata Update from @nkinder:

  • Issue assigned to awnuk
  • Issue set to the milestone: UNTRIAGED

Copy link

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Mar 29, 2025
Copy link
github-actions bot commented May 3, 2025

This issue will be closed for inactivity. If the problem is still present reopen this or create a new issue.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant
0