|
« Return to Thread: CMP and SCEP problem
Re: CMP and SCEP problem
by Juraj Michalak
::
Rate this Message:
[This is message from TOMAS GUSTAVSSON]
Hi,
Regarding the error in EJBCA
---------------------------
What happens is that it finds that the message have a protectionAlgoritm
of 1.2.840.113533.7.66.13, which is passwordBasedMac. Then it gets the
parameters from this and tries to decode it, and find out it is not an
asn.1 sequence.
I'd checked the asn.1 of the messages more carefully to see what
happened. The messages can be found in base64 in the the ejbca log:
In the first message CertInit that protection is (from openssl asn1parse):
-----
109:d=2 hl=2 l= 62 cons: cont [ 1 ]
111:d=3 hl=2 l= 60 cons: SEQUENCE
113:d=4 hl=2 l= 9 prim: OBJECT
:1.2.840.113533.7.66.13
124:d=4 hl=2 l= 47 cons: SEQUENCE
126:d=5 hl=2 l= 16 prim: OCTET STRING [HEX
DUMP]:E1FB6013DE2451F5340145A9EAD9D7E8
144:d=5 hl=2 l= 9 cons: SEQUENCE
146:d=6 hl=2 l= 5 prim: OBJECT :sha1
153:d=6 hl=2 l= 0 prim: NULL
155:d=5 hl=2 l= 2 prim: INTEGER :01F4
159:d=5 hl=2 l= 12 cons: SEQUENCE
161:d=6 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.8.1.2
171:d=6 hl=2 l= 0 prim: NULL
-----
Which is something expected, the PBMParameter (rfc4210 section 5.1.3.1)
is an octet string, an oid, an integer and in oid.
In the CertConfirm message that EJBCA fails to verify the protection is:
-----
108:d=2 hl=2 l= 15 cons: cont [ 1 ]
110:d=3 hl=2 l= 13 cons: SEQUENCE
112:d=4 hl=2 l= 9 prim: OBJECT :1.2.840.113533.7.66.13
123:d=4 hl=2 l= 0 prim: NULL
-----
Here the PBMParameter seems to be missing, which is consistent with the
stack trace in EJBCA.
Is this correct in CMP Peter? Or is it a mistake in Jurajs code?
My interpretation of the standard is that the PBMParameters should be there.
Kind regards,
Tomas
Juraj Michalak wrote:
>> Hi Tomas and Peter,
>>
>> Yes I have "cmp.responseprotection=pbe". My whole EJBCA config is:
>> http://student.fiit.stuba.sk/~michalak04/zdielane/ejbca_conf.zip
>>
>> All below mentioned file are at:
>> http://student.fiit.stuba.sk/~michalak04/zdielane/problem2.zip
>>
>> CMP
>> ===
>> I'm so sorry and I want to apologize. I've done a big mistake - I've
>> missed the CRYPT_ATTRIBUTE_INT_ERRORMESSAGE in CRYPTLIB manual. So now:
>>
>> My CMP error with extended error info is:
>> error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -20
>> INFO: Can't confirm certificate issue using algorithm 205
>>
>> 205 is SHA256 (according to cryptlib.h). So I switched to new CA in
>> EJBCA with:
>> ca.signaturealgorithm=SHA1WithRSA
>>
>> I was so happy that my problem will be solved but there is new problem
>> :-( :
>>
>> "generate_cmp.c":
>> error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -41
>> INFO: HTTP response status: Internal Server Error
>>
>> On the EJBCA side (full EJBCA log is in "ejbca_failure.log"):
>> ===============================================
>> ...
>> 12:19:03,259 INFO [Log4jLogDevice] April 11, 2009 12:19:03 PM CEST,
>> CAId : 1961146099, CA, EVENT_INFO_CHANGEDENDENTITY, Administrator :
>> RACMDLINE, User : lala@tinky, Certificate : No certificate involved,
>> Comment : Changed status to STATUS_GENERATED.
>> 12:19:03,275 INFO [CmpServlet] Sent a CMP response to: 192.168.101.1.
>> 12:19:03,285 INFO [CmpServlet] CMP message received from:192.168.101.1.
>> 12:19:03,292 ERROR [CmpServlet] Error in CmpServlet:
>> java.lang.IllegalArgumentException: unknown object in factory
>> at
>>
com.novosec.pkix.asn1.crmf.PBMParameter.getInstance(PBMParameter.java:68)
>> at
>>
org.ejbca.core.protocol.cmp.CmpPbeVerifyer.verify(CmpPbeVerifyer.java:70)
>> at
>>
org.ejbca.core.protocol.cmp.ConfirmationMessageHandler.handleMessage(ConfirmationMessageHandler.java:88)
>>
>> at
>>
org.ejbca.core.protocol.cmp.CmpMessageDispatcher.dispatch(CmpMessageDispatcher.java:139)
>>
>> at
org.ejbca.ui.web.protocol.CmpServlet.service(CmpServlet.java:225)
>> at
org.ejbca.ui.web.protocol.CmpServlet.doPost(CmpServlet.java:186)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>> 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
>>
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>>
>> 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:235)
>>
>> at
>>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>>
>> at
>>
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>>
>> at
>>
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>>
>> at
>>
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
>>
>> at
>>
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
>>
>> at
>>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>
>> at
>>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>
>> at
>>
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>>
>> at
>>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>
>> at
>>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>> at
>>
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>> at
>>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
>>
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> at java.lang.Thread.run(Thread.java:619)
>> ...
>> ===============================================
>>
>> For now it seems that error is on EJBCA side but:
>>
>> I have also tcpdump "cmp_dump.cap" of that communication and in last
>> response (confirm) from my cryptlib client (generate_cmp.c) is some BER
>> encoding Error - in PBM. Could it cause that EJBCA above failure?
>>
>> For Peter
>> ======
>> Why SHA256 is problem? Is it bed to provide stronger security (SHA1 has
>> also some possible weakness...)?
>> When I was implementing my S/MIME enveloping I made notice to ask you,
>> how to use SHA384 or SHA512?
>> in cryptlib.h:
>> CRYPT_ALGO_SHA2, /* SHA2 (SHA-256/384/512)*/
>> because also your crypt/sha2.c contains functions for full
>> SHA-256/384/512 support.
>>
>>
>> best regards,
>>
>> Juraj Michalak
_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.
Hi,
Regarding the error in EJBCA
---------------------------
What happens is that it finds that the message have a protectionAlgoritm
of 1.2.840.113533.7.66.13, which is passwordBasedMac. Then it gets the
parameters from this and tries to decode it, and find out it is not an
asn.1 sequence.
I'd checked the asn.1 of the messages more carefully to see what
happened. The messages can be found in base64 in the the ejbca log:
In the first message CertInit that protection is (from openssl asn1parse):
-----
109:d=2 hl=2 l= 62 cons: cont [ 1 ]
111:d=3 hl=2 l= 60 cons: SEQUENCE
113:d=4 hl=2 l= 9 prim: OBJECT
:1.2.840.113533.7.66.13
124:d=4 hl=2 l= 47 cons: SEQUENCE
126:d=5 hl=2 l= 16 prim: OCTET STRING [HEX
DUMP]:E1FB6013DE2451F5340145A9EAD9D7E8
144:d=5 hl=2 l= 9 cons: SEQUENCE
146:d=6 hl=2 l= 5 prim: OBJECT :sha1
153:d=6 hl=2 l= 0 prim: NULL
155:d=5 hl=2 l= 2 prim: INTEGER :01F4
159:d=5 hl=2 l= 12 cons: SEQUENCE
161:d=6 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.8.1.2
171:d=6 hl=2 l= 0 prim: NULL
-----
Which is something expected, the PBMParameter (rfc4210 section 5.1.3.1)
is an octet string, an oid, an integer and in oid.
In the CertConfirm message that EJBCA fails to verify the protection is:
-----
108:d=2 hl=2 l= 15 cons: cont [ 1 ]
110:d=3 hl=2 l= 13 cons: SEQUENCE
112:d=4 hl=2 l= 9 prim: OBJECT :1.2.840.113533.7.66.13
123:d=4 hl=2 l= 0 prim: NULL
-----
Here the PBMParameter seems to be missing, which is consistent with the
stack trace in EJBCA.
Is this correct in CMP Peter? Or is it a mistake in Jurajs code?
My interpretation of the standard is that the PBMParameters should be there.
Kind regards,
Tomas
Juraj Michalak wrote:
>> Hi Tomas and Peter,
>>
>> Yes I have "cmp.responseprotection=pbe". My whole EJBCA config is:
>> http://student.fiit.stuba.sk/~michalak04/zdielane/ejbca_conf.zip
>>
>> All below mentioned file are at:
>> http://student.fiit.stuba.sk/~michalak04/zdielane/problem2.zip
>>
>> CMP
>> ===
>> I'm so sorry and I want to apologize. I've done a big mistake - I've
>> missed the CRYPT_ATTRIBUTE_INT_ERRORMESSAGE in CRYPTLIB manual. So now:
>>
>> My CMP error with extended error info is:
>> error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -20
>> INFO: Can't confirm certificate issue using algorithm 205
>>
>> 205 is SHA256 (according to cryptlib.h). So I switched to new CA in
>> EJBCA with:
>> ca.signaturealgorithm=SHA1WithRSA
>>
>> I was so happy that my problem will be solved but there is new problem
>> :-( :
>>
>> "generate_cmp.c":
>> error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -41
>> INFO: HTTP response status: Internal Server Error
>>
>> On the EJBCA side (full EJBCA log is in "ejbca_failure.log"):
>> ===============================================
>> ...
>> 12:19:03,259 INFO [Log4jLogDevice] April 11, 2009 12:19:03 PM CEST,
>> CAId : 1961146099, CA, EVENT_INFO_CHANGEDENDENTITY, Administrator :
>> RACMDLINE, User : lala@tinky, Certificate : No certificate involved,
>> Comment : Changed status to STATUS_GENERATED.
>> 12:19:03,275 INFO [CmpServlet] Sent a CMP response to: 192.168.101.1.
>> 12:19:03,285 INFO [CmpServlet] CMP message received from:
>> 12:19:03,292 ERROR [CmpServlet] Error in CmpServlet:
>> java.lang.IllegalArgumentException: unknown object in factory
>> at
>>
com.novosec.pkix.asn1.crmf.PBMParameter.getInstance(PBMParameter.java:68)
>> at
>>
org.ejbca.core.protocol.cmp.CmpPbeVerifyer.verify(CmpPbeVerifyer.java:70)
>> at
>>
org.ejbca.core.protocol.cmp.ConfirmationMessageHandler.handleMessage(ConfirmationMessageHandler.java:88)
>>
>> at
>>
org.ejbca.core.protocol.cmp.CmpMessageDispatcher.dispatch(CmpMessageDispatcher.java:139)
>>
>> at
org.ejbca.ui.web.protocol.CmpServlet.service(CmpServlet.java:225)
>> at
org.ejbca.ui.web.protocol.CmpServlet.doPost(CmpServlet.java:186)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>> 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
>>
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>>
>> 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:235)
>>
>> at
>>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>>
>> at
>>
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>>
>> at
>>
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>>
>> at
>>
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
>>
>> at
>>
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
>>
>> at
>>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>
>> at
>>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>
>> at
>>
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>>
>> at
>>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>
>> at
>>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>> at
>>
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>> at
>>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
>>
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> at java.lang.Thread.run(Thread.java:619)
>> ...
>> ===============================================
>>
>> For now it seems that error is on EJBCA side but:
>>
>> I have also tcpdump "cmp_dump.cap" of that communication and in last
>> response (confirm) from my cryptlib client (generate_cmp.c) is some BER
>> encoding Error - in PBM. Could it cause that EJBCA above failure?
>>
>> For Peter
>> ======
>> Why SHA256 is problem? Is it bed to provide stronger security (SHA1 has
>> also some possible weakness...)?
>> When I was implementing my S/MIME enveloping I made notice to ask you,
>> how to use SHA384 or SHA512?
>> in cryptlib.h:
>> CRYPT_ALGO_SHA2, /* SHA2 (SHA-256/384/512)*/
>> because also your crypt/sha2.c contains functions for full
>> SHA-256/384/512 support.
>>
>>
>> best regards,
>>
>> Juraj Michalak
_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.
« Return to Thread: CMP and SCEP problem
| Free embeddable forum powered by Nabble | Forum Help |
