dogtagpki

#1219 CA fails to issue ECC based SCEP certificate
Closed: Invalid Opened by alsifius.

Closed: Invalid
Reopen Issue

The dogtag certificate system will not produce certificates via scep for Juniper SRX 550 routers (OS version is JUNOS 12.1X46-D15.3) based on request submitted using ECC modules. When attempted, the following error is seen:

handlePKIMessage exception java.lang.NullPointerException
java.lang.NullPointerException
at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:106)
at com.netscape.cms.servlet.cert.scep.CRSEnrollment.handlePKIOperation(CRSEnrollment.java:821)
at com.netscape.cms.servlet.cert.scep.CRSEnrollment.service(CRSEnrollment.java:370)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:238)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:221)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
[12/Nov/2014:14:59:31]http-bio-8080-exec-8: ServletException javax.servlet.ServletException: Failed to process message in CEP servlet: null

Steps t reproduce:

  1. Install the Dogtag version 10.2.0

  2. Enable router certificates in CS.cfg

change ca.scep.enable parameter to true

  1. Adjust the router profile as follows:

The profile that needs to be changed is /var/lib/pki/pki-tomcat/ca/profiles/ca/caRouterCert.cfg

Currently if you look at the profile, by default the key constraint is limiting you to RSA
policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl
policyset.serverCertSet.3.constraint.name=Key Constraint
policyset.serverCertSet.3.constraint.params.keyType=RSA
policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096

You want to change it so that it accepts both RSA and ECC.

policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl
policyset.serverCertSet.3.constraint.name=Key Constraint
policyset.serverCertSet.3.constraint.params.keyType=-
policyset.serverCertSet.3.constraint.params.keyParameters=2048,3072,4096,nistp256,nistp384,nistp521

  1. Add the router IP and pin to the CA authentication file, /etc/pki/pki-tomcat/ca/flatfile.txt, e.g.:

UID:10.0.2.15
PWD:1212

  1. Issue a request to the CA directly from the router and specify ECC as the key module and the one of the curves specified in the caRouterCert.cfg file.

The aforementioned error can be seen in the debug log of the CA.

Tests were done to make sure that the server could produce ECC certificates in general; both server and user certificates were produced using requests generated by openssl that were ECC based. We were also able to produce certificates via scep where the request was RSA based. The above scenario is the same whether the CA certificate is RSA or ECC based.

After discussion with cfu on 12/11/2014, it was determined that this ticket could be moved to 10.2.2.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1182392

I do not have knowledge or access to the router. Please try the following with a router and let me know if it works for you.

The following are steps I took to get the ECC Dogtag CA to issue ECC certs via SCEP:

The client, sscep:
I downloaded the sscep src rpm from
http://koji.fedoraproject.org/koji/buildinfo?buildID=569746
I edited the mkrequest so that it generates ECC keys, let's call it mkrequestEC so not to confuse with the stock mkrequest on fedora.

Now, since the CA's signing cert is ECC, and I do not want to tackle with the client to handle that, I am using an alternative RSA signing cert from the CA as the SCEP signing cert.
I am using the auditSigningCert just because it is there, and it is RSA. In production, you might want to generate a different cert for this purpose, if policy dictates.
So, with that in mind, I put the CA's auditSigning cert on my client side by creating a file called
auditSigningCert.crt in PEM format.

Next, instead of the self-sign cert, we want to use an RSA cert to do this. What I did was to issue a cert that has signing and encryption capability and put its cert and keys in PEM format:
sign.key and sign.crt

Now I begin
1. get ca cert:
./sscep getca -c ca.crt -u 'http://example.example.com:8080/ca/cgi-bin/pkiclient.exe'

  1. to generate keys and csr:
    ./mkrequestEC -ip xx.xx.xx.xxx 1111

  2. enroll
    ./sscep enroll -c ca.crt -e auditSigning.crt -k local.key -r local.csr -K sign.key -O sign.crt -E 3des -S sha256 -l cert.crt -u 'http://example.example.com:8080/ca/cgi-bin/pkiclient.exe'

I could see on the ee page that the cert was issued:
Subject Public Key Info:
Algorithm: EC - 1.2.840.10045.2.1
Public Key:
04:9F:1D:34:59:9E:D3:4E:17:FC:E8:BF:F9:BA:CE:B0:
....
Signature:
Algorithm: SHA256withEC - 1.2.840.10045.4.3.2
Signature:
30:45:02:21:00:94:03:A0:1D:F6:4E:38:27:DA:28:0F
....

and I see the result of the successful SCEP response and the cert.crt file. I ran examined it with dumpasn1 and it appears to be correct serial number and key type:
259 89: SEQUENCE {
261 19: SEQUENCE {
263 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
: (ANSI X9.62 public key type)
272 8: OBJECT IDENTIFIER '1 2 840 10045 3 1 7'
: }

https://bugzilla.redhat.com/show_bug.cgi?id=1195502

closing as not a bug with workaround.

Metadata Update from @alsifius:
- Issue assigned to cfu
- Issue set to the milestone: 10.2.2

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:
https://github.com/dogtagpki/pki/issues/1781

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
None
None
None
Lowest
defect
SCEP
ECC SCEP router
RHCust
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.