Red Hat Bugzilla – Bug 439052
CMC CRMF requests cause exception in logging: Unmatched braces in the pattern
Last modified: 2015-01-05 20:18:39 EST
Description of problem: When I submit some CMC requests to the CA, I get an error that appears to be audit log related. Version-Release number of selected component (if applicable): Dogtag 1.0.0 How reproducible: Always Steps to Reproduce: 1. Go to the end-entity url for the CA instance in question (e.g., https://ca.host.tld:9443/ca/agent/ca/) 2. Choose the Signed CMC-Authenticated User Certificate Enrollment profile 3. Paste in my problematic CMC request (attached) and submit it 4. error will be presented on the following page Actual results: The next page shows the following text after pressing submit: "The Certificate System has encountered an unrecoverable error. Error Message: java.lang.IllegalArgumentException: Unmatched braces in the pattern. Please contact your local administrator for assistance." The CA does not appear to issue a certificate for the request. Here's the stack trace from catalina.out: Mar 26, 2008 1:58:39 PM org.apache.catalina.core.ApplicationContext log INFO: caProfileSubmit: java.lang.IllegalArgumentException: Unmatched braces in the pattern. at java.text.MessageFormat.applyPattern(MessageFormat.java:494) at java.text.MessageFormat.<init>(MessageFormat.java:368) at com.netscape.certsrv.logging.SignedAuditEvent.toString(SignedAuditEvent.java:328) at com.netscape.cms.logging.LogFile.logEvt2String(LogFile.java:1050) at com.netscape.cms.logging.LogFile.log(LogFile.java:1029) at com.netscape.cms.logging.RollingLogFile.log(RollingLogFile.java:458) at com.netscape.cmscore.logging.LogQueue.log(LogQueue.java:104) at com.netscape.cmscore.logging.Logger.log(Logger.java:205) at com.netscape.cmscore.logging.Logger.log(Logger.java:127) at com.netscape.cms.authentication.CMCAuth.audit(CMCAuth.java:994) at com.netscape.cms.authentication.CMCAuth.authenticate(CMCAuth.java:617) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.authenticate(ProfileSubmitServlet.java:145) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:383) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:482) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:675) Expected results: no error, certificate issued Additional info:
Created attachment 299207 [details] agent certificate that signed CMC request
Created attachment 299208 [details] sub-ca that signed agent cert
Created attachment 299209 [details] root ca that signed sub-ca
Created attachment 299210 [details] cmc request, base64 encoded, you can paste this into the form in ee interface to kick off error
Hi, I tried successfully in enrolling for a signed CMC request on my development machine, both with an agent cert off of a root CA, and with an agent cert off of a subordinate CA. In other words, I could not reproduce your problem. In order to help you further, I need a few more pieces of information just to see if I can reproduce the problem you are seeing: 1. Did you customize the CS.cfg, especially in regard to auditing? If so, please attach a copy of your CS.cfg 2. How did you generate the CMC request? Please list step by step procedure. 3. Please supply more debug log messages surrounding the error, to give me more context on where the error occured. 4. Did you modify the CMC enrollment profile? If you did, please attach the new profile.
1. I haven't manually edited CS.cfg 2. CMC requests were created with a java application (we wrote) using JSS libraries. I'd be happy to send you the code for the request generation, but I'd prefer not to post it on here publicly. 3. logs: <see below> 4. No, The only thing I did to the CA was enroll it as a sub-ca to our root, add another sub-ca (a "peer" of this one) that my agent certificate was issued from and added myself and my cert as an agent so I could authenticate. The ee webpage I reference in the original bug report and below uses the caCMCUserCert profile. We use the caProfileSubmitCMCFull servlet (defined in /var/lib/pki-<instance>/webapps/ca/WEB-INF/web.xml) which uses the caFullCMCUserCert profile by default. I could have been a little more complete in my description. We have an application that generates keys and certificate requests, inserts the CSRs into agent-signed CMC requests, sends them to the CMC servlet and parses the CMC responses from the CA. For the vast majority of requests we send, everything works fine. There are just a few that seem to consistently cause this error to occur. As I said above, in operation we don't use the 'Signed CMC-Authenticated User Certificate Enrollment" webpage and paste in the Base64, however, the same result is obtained (the error). I attached a sample CMC request along with the certs needed to be added to the CA to allow the agent to be added so my specific request could be tested. If you guys want/need, I can give you more requests that cause the same problem. As far as we can see, it's just slight variations in the DN that cause the problem and we're only using ascii characters, numbers, periods, commas, and equal signs in the DNs. For example: CN=XBaron.Christopher.G.1111111115,OU=USA,OU=PKI,OU=DoD,O=U.S. Government,C=US CN=XBaron.Christophe.G.1111111115,OU=USA,OU=PKI,OU=DoD,O=U.S. Government,C=US As you can see the only difference is the r at the end of the first name being there or not. The first DN will cause the unmatched braces error, the second will not. Length doesn't appear to be the issue as I just tested one successfully with a 72 char CN vs the 31 that the XBaron example above has. I've added new attachment for the debug log at the time of issuance. - access log has the following lines for that time: 192.168.1.200 - - [01/Apr/2008:06:55:37 -0400] "POST /ca/ee/ca/profileSubmit HTTP/1.1" 200 272 192.168.1.200 - - [01/Apr/2008:06:55:37 -0400] "GET /favicon.ico HTTP/1.1" 404 988 192.168.1.200 - - [01/Apr/2008:06:55:37 -0400] "GET /favicon.ico HTTP/1.1" 404 988 - system has the following line 5637.http-9443-Processor25 - [01/Apr/2008:06:55:37 EDT] [6] [3] Agent authentication cannot evaluate the revocation status. - the signed audit log doesn't have anything for that time as that is where the error is occurring. The signed audit log uses a lot of braces in it. - the only things in catalina.out besides the stacktraces for the unmatched braces are the tomcat startup messages As I said before, I can generate up sample signed CMC requests, both good and bad, if you would like them for testing. If you want more, let me know if you prefer base64 or DER encoding. I don't know what tools you have available, but I typically parse the binary CMC request using Peter Gutman's dumpasn1 utility (http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c). You can convert the attached base64 request to binary using openssl (openssl base64 -d -in cmc.b64 -out cmc.bin).
Created attachment 299878 [details] debug log from CA during the problematic CMC request processing
Can you also give me the base-64 encoded cmc request that works (the one with one less letter, "Christophe") just for me to compare with? I was able to see the error(s) with your other CMC request, but with my own CMC generation tool, with the same subject DN, I can't reproduce that. thanks.
Created attachment 300294 [details] another bad one with the name requested (Christopher)
Created attachment 300295 [details] a good request (Christohpe)
Created attachment 301315 [details] fix note that this problem only affected CMC CRMF enrollment requests. This fix fixes this.
id: 301315 jmagne+
[cfu@jaw pki]$ svn status | grep -v ^$ | grep -v ^P | grep -v ^X M linux/common/pki-common.spec M base/common/src/com/netscape/cms/authentication/CMCAuth.java [cfu@jaw pki]$ svn commit Sending base/common/src/com/netscape/cms/authentication/CMCAuth.java Sending linux/common/pki-common.spec Transmitting file data .. Committed revision 16.
Created attachment 301317 [details] try again... to make it recognized as text file
The following new packages have been pushed: 32-bit RPMS: pki-common-1.0.0-2.fc8.noarch.rpm pki-common-javadoc-1.0.0-2.fc8.noarch.rpm 64-bit RPMS: pki-common-1.0.0-2.fc8.noarch.rpm pki-common-javadoc-1.0.0-2.fc8.noarch.rpm SRPMS: pki-common-1.0.0-2.fc8.src.rpm
I tested the new rpm this morning doing both the "cut and paste" and using our application going straight to the CMC servlet and both worked fine with the entries that were previously *always* giving us errors.
Bug already MODIFIED. setting target CS8.0 and marking screened+