CMP and SCEP problem
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
 |
CMP and SCEP problem
by Juraj Michalak
::
Rate this Message:
Hello,
Thanks for your response (Peter and Tomas). All files which will be mentioned are available here: http://student.fiit.stuba.sk/~michalak04/zdielane/problem.zip CMP === So I changed settings of EJBCA (mulholland CA) to interact in "RA mode" - means that my cryptlib CMP client will act as RA. PBM authentication is working then and it's better for my solution because in "RA mode" because I don't need to have precreated end user in EJBCA. So I have new "generate_cmp.c". With this EJBCA created successfully new end user and signed his certificate. But when response is sent from EJBCA cryptlib generate_cmp.c client fails with: error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -20 (what is CRYPT_ERROR_NOTAVAIL) The tcpdump/wireshark dumped file of that communication is "br0.cap" I have tried to download that signed certificate of new end-user from browser and imported it into "cryptlib" via "import_cert.c". It was working, certificate imported successfully. So question for Tomas: When you tested cryptlib, have you checked also the return value of cryptSetAttribute( cmp_session, CRYPT_SESSINFO_ACTIVE, 1 ); ? So for now I can download all certificates manually and import themm into my cryptlib solution. But it's only a big trade-off. SCEP ==== So I decided to try SCEP. I have created new CA (router) in EJBCA with "Key encipherment" key usage - according to EJBCA docs. Cryptlib's client is written in "generate_scep.c". This time there is no communication because cryptlib encounters error earlier: error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -15 (what is CRYPT_ERROR_FAILED) I have little bit debugged and this is my observation (cryptlib's sources): session/scep_cli.c:168 "Couldn't create SCEP request signing attributes" END === Peter can you look at "generate_scep.c" created by me to tell if I have done some misuse with SCEP? And what about CMP? 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. |
|
|
|
|
|
Re: CMP and SCEP problem
by Peter Gutmann
::
Rate this Message:
Juraj Michalak <juraj.michalak@...> writes:
>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 CMP hard-codes various assumptions into the protocol in bizarre ways... in fact this particular one is so complicated that it's not even easy to explain (the RFC authors must have come up with this one as the result of losing a bet), but the end result is that if you don't use MD5 or SHA-1 then odd things happen (or at least if you use it with two different implementations then odd things happen). >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? Could you send me the DER-encoded object? Or alternatively the dumpasn1 output for it? >Why SHA256 is problem? Is it bed to provide stronger security (SHA1 has also >some possible weakness...)? See above, with two different implementations both sides can make different guesses at what the standard is expecting. For this reason cryptlib explicitly checks for the two algorithms that were in use at the time, MD5 and SHA-1, because for those at least the different implementers could agree on what to do. I can add an attempt at SHA-256 support, but it's not guaranteed that it'll interoperate. >When I was implementing my S/MIME enveloping I made notice to ask you, how to >use SHA384 or SHA512? These aren't enabled because they require a 64-bit CPU (although in theory you can do it on a 32-bit system where the compiler has long long support), and that's too much of a portability nightmare to enable. >So I decided to try SCEP. I have created new CA (router) in EJBCA with "Key >encipherment" key usage - according to EJBCA docs. Cryptlib's client is >written in "generate_scep.c". This time there is no communication because >cryptlib encounters error earlier: > >error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -15 (what is CRYPT_ERROR_FAILED) > >session/scep_cli.c:168 "Couldn't create SCEP request signing attributes" Hmm, it looks like you used SHA-256 here as well, SCEP had an even worse problem in that it hardcoded MD5 as the only allowed algorithm. There is a way to kludge in other algorithms (by sending an HTTP request containing an argument other than a standard SCEP request, which is supposed to return a text page containing information about what new algorithms are supported) but the last time I tried it it wasn't supported very well (there are lots of old, mininal SCEP implementations built into routers and the like) and lead to strange failures if you use it. In general it seems safe to assume SHA-1 (which is what cryptlib does), but trying to push it beyond that is kind of risky. Peter. _______________________________________________ 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. |
|
|
|
|
|
Re: CMP and SCEP problem
by Juraj Michalak
::
Rate this Message:
Peter Gutmann wrote:
>> error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -15 (what is CRYPT_ERROR_FAILED) >> >> session/scep_cli.c:168 "Couldn't create SCEP request signing attributes" >> > > Hmm, it looks like you used SHA-256 here as well, SCEP had an even worse > problem in that it hardcoded MD5 as the only allowed algorithm. There is a > way to kludge in other algorithms (by sending an HTTP request containing an > argument other than a standard SCEP request, which is supposed to return a > text page containing information about what new algorithms are supported) but > the last time I tried it it wasn't supported very well (there are lots of old, > mininal SCEP implementations built into routers and the like) and lead to > strange failures if you use it. In general it seems safe to assume SHA-1 > (which is what cryptlib does), but trying to push it beyond that is kind of > risky. > > Peter. > > SHA-1 also with scep but there is no difference. It's still the -15 error with "Couldn't create SCEP request signing attributes". My scep CA certificate and scep source code is available here: http://student.fiit.stuba.sk/~michalak04/zdielane/scepca.der http://student.fiit.stuba.sk/~michalak04/zdielane/generate_scep.c It is not possible to try MD5 because EJBCA doesn't allow it. CMP === Is the DER encoded object from EJBCA log or what Tomas provided enough for you?: MIH8MIHBAgECpCQwIjELMAkGA1UEBhMCU0sxEzARBgNVBAMUCmxhbGFAdGlua3mk OzA5MRMwEQYDVQQDDAptdWxob2xsYW5kMRUwEwYDVQQKDAxFSkJDQSBTYW1wbGUx CzAJBgNVBAYTAlNLoQ8wDQYJKoZIhvZ9B0INBQCiDAQKbGFsYUB0aW5reaQSBBCc 3xJ8jgerIBweDQdHl/UkpRIEELr9RaGdtggdMcq3mt4z4QCmEgQQOkmvuW/uI1mw AI92BLRo2bgdMBswGQQUrlaasgqkT51Gg8Oj4PYdf14KmWQCAQCgFwMVAGy5nP+4 rPtLB+tiNndmywHlsXrd Juraj. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Tomas Gustavsson-3
::
Rate this Message:
Hi Juraj, EJBCA does support MD5 for SCEP message protection. It's the default since it's the default in the standard. We try to be nice though and will use whatever digest algorithms the request message uses. That's for message protection... For the issued certificates we also allow (reluctantly since EJBCA 3.4.2) MD5WithRSA. SHA1 is usually supported though and is inter-operable with all routers we have tested such as Juniper and Cisco. they support certificates issued using SHA1WithRSA. Did you check my test code if you do anything different when creating the SCEP session (I did not compare it to your code myself)? Peter: If you are interested I'll try to save you some work. I try to attach the DER coded CMP messages I decoded form the log file (foo1.der is the init request and foo the confirm). Cheers, Tomas Juraj Michalak wrote: > Peter Gutmann wrote: >>> error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -15 (what is >>> CRYPT_ERROR_FAILED) >>> >>> session/scep_cli.c:168 "Couldn't create SCEP request signing attributes" >>> >> >> Hmm, it looks like you used SHA-256 here as well, SCEP had an even worse >> problem in that it hardcoded MD5 as the only allowed algorithm. There >> is a >> way to kludge in other algorithms (by sending an HTTP request >> containing an >> argument other than a standard SCEP request, which is supposed to >> return a >> text page containing information about what new algorithms are >> supported) but >> the last time I tried it it wasn't supported very well (there are lots >> of old, >> mininal SCEP implementations built into routers and the like) and lead to >> strange failures if you use it. In general it seems safe to assume SHA-1 >> (which is what cryptlib does), but trying to push it beyond that is >> kind of >> risky. >> >> Peter. >> >> > After the knowledge that CMP has problem with SHA256 I have tried to use > SHA-1 also with scep but there is no difference. It's still the -15 > error with "Couldn't create SCEP request signing attributes". My scep CA > certificate and scep source code is available here: > http://student.fiit.stuba.sk/~michalak04/zdielane/scepca.der > http://student.fiit.stuba.sk/~michalak04/zdielane/generate_scep.c > > It is not possible to try MD5 because EJBCA doesn't allow it. > > CMP > === > Is the DER encoded object from EJBCA log or what Tomas provided enough > for you?: > > MIH8MIHBAgECpCQwIjELMAkGA1UEBhMCU0sxEzARBgNVBAMUCmxhbGFAdGlua3mk > OzA5MRMwEQYDVQQDDAptdWxob2xsYW5kMRUwEwYDVQQKDAxFSkJDQSBTYW1wbGUx > CzAJBgNVBAYTAlNLoQ8wDQYJKoZIhvZ9B0INBQCiDAQKbGFsYUB0aW5reaQSBBCc > 3xJ8jgerIBweDQdHl/UkpRIEELr9RaGdtggdMcq3mt4z4QCmEgQQOkmvuW/uI1mw > AI92BLRo2bgdMBswGQQUrlaasgqkT51Gg8Oj4PYdf14KmWQCAQCgFwMVAGy5nP+4 > rPtLB+tiNndmywHlsXrd > > Juraj. > > > _______________________________________________ > 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. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Peter Gutmann
::
Rate this Message:
Juraj Michalak <juraj.michalak@...> writes:
>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. The parameter part is actually optional, with absent parameters meaning "same as last time". This was one of the (many) problems discovered during the (non-)interop tests, you can in theory use completely different MAC parameters for every message, which it turned out almost no-one could actually handle correctly (you could also have fun with the values, for example in one case I wanted to see what would happen if I sent a very high iteration count and a large salt. The server stopped responding after that :-). Anyway, the de facto solution was to omit the parameters to indicate that the MAC keying and whatnot was unchanged. If you look at writeMacInfo() in session/cmp_wr.c there's a flag 'parametersSent' that controls this, you can comment that out and cryptlib will always send the full set of parameters, although now you have to parse them all in order to find out that nothing's changed. I'll fix this for the next release. There's also a large pile of complex logic in readMacInfo() in session/cmp_rd.c to handle all the different interpretations of the spec for this. For every unusual-case check in there there'll be at least one implementation out there that triggers it (or did at the time, I don't know how many of those implementations are still around). Incidentally (for Tomas, CC'd in to this reply), one reason why cryptlib sends out a GenMsg with a cryptlib magic ID in it is that it then knows that the other side will adopt certain common-sense measures, for example it'll always send an ESSCertID to identify certs rather than using an X.500 DN, which can't actually usefully identify a certificate and which lead to some interesting failures during the (non-)interop. If you're interested I can send you a list of things that the magic ID ensures, e.g. keep the MAC parameters constant across messages, send an ESSCertID to identify certs, that sort of thing. Peter. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Peter Gutmann
::
Rate this Message:
Tomas Gustavsson <tomasg@...> writes:
>SHA1 is usually supported though and is inter-operable with all routers we >have tested such as Juniper and Cisco. they support certificates issued using >SHA1WithRSA. I've found the same thing, everything I've managed to test against (including really old routers and embedded devices) supports SHA-1 automatically even if it predates any SCEP RFC draft that mentions it, SHA-1 is sort of the universal substrate of security mechanisms so it seems you can always rely on it. OTOH for anything newer it's risky because even the mechanism to determine whether you can use something better than SHA-1 isn't well-supported and leads to strange failures. Peter. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Artur Pietrzyk
::
Rate this Message:
-----Original Message----- From: Artur Pietrzyk [mailto:sviss@...] Sent: Monday, April 13, 2009 7:36 PM To: 'Peter Gutmann'; 'cryptlib@...'; 'tomasg@...' Subject: RE: [Cryptlib] CMP and SCEP problem Hi, How to unsubscribe from this mailing group? Thanks, Artur Pietrzyk -----Original Message----- From: cryptlib-bounces@... [mailto:cryptlib-bounces@...] On Behalf Of Peter Gutmann Sent: Monday, April 13, 2009 5:07 PM To: cryptlib@...; tomasg@... Subject: Re: [Cryptlib] CMP and SCEP problem Tomas Gustavsson <tomasg@...> writes: >SHA1 is usually supported though and is inter-operable with all routers we >have tested such as Juniper and Cisco. they support certificates issued using >SHA1WithRSA. I've found the same thing, everything I've managed to test against (including really old routers and embedded devices) supports SHA-1 automatically even if it predates any SCEP RFC draft that mentions it, SHA-1 is sort of the universal substrate of security mechanisms so it seems you can always rely on it. OTOH for anything newer it's risky because even the mechanism to determine whether you can use something better than SHA-1 isn't well-supported and leads to strange failures. Peter. _______________________________________________ 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. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Artur Pietrzyk
::
Rate this Message:
-----Original Message----- From: Artur Pietrzyk [mailto:sviss@...] Sent: Monday, April 13, 2009 8:17 PM To: 'Artur Pietrzyk'; 'Peter Gutmann'; 'cryptlib@...'; 'tomasg@...' Subject: RE: [Cryptlib] CMP and SCEP problem -----Original Message----- From: Artur Pietrzyk [mailto:sviss@...] Sent: Monday, April 13, 2009 7:36 PM To: 'Peter Gutmann'; 'cryptlib@...'; 'tomasg@...' Subject: RE: [Cryptlib] CMP and SCEP problem Hi, How to unsubscribe from this mailing group? Thanks, Artur Pietrzyk -----Original Message----- From: cryptlib-bounces@... [mailto:cryptlib-bounces@...] On Behalf Of Peter Gutmann Sent: Monday, April 13, 2009 5:07 PM To: cryptlib@...; tomasg@... Subject: Re: [Cryptlib] CMP and SCEP problem Tomas Gustavsson <tomasg@...> writes: >SHA1 is usually supported though and is inter-operable with all routers we >have tested such as Juniper and Cisco. they support certificates issued using >SHA1WithRSA. I've found the same thing, everything I've managed to test against (including really old routers and embedded devices) supports SHA-1 automatically even if it predates any SCEP RFC draft that mentions it, SHA-1 is sort of the universal substrate of security mechanisms so it seems you can always rely on it. OTOH for anything newer it's risky because even the mechanism to determine whether you can use something better than SHA-1 isn't well-supported and leads to strange failures. Peter. _______________________________________________ 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. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Juraj Michalak
::
Rate this Message:
Tomas Gustavsson wrote:
> Hi Juraj, > > Did you check my test code if you do anything different when creating > the SCEP session (I did not compare it to your code myself)? > Yes, I have checked and I cannot see any difference. I have tried many stupid things, now I think I need some clever :-). With SCEP I'm still with "Couldn't create SCEP request signing attributes". But SCEP is not so important for me. CMP is important. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Juraj Michalak
::
Rate this Message:
Peter Gutmann wrote:
>> >> Anyway, the de facto solution was to omit the parameters to indicate that the >> MAC keying and whatnot was unchanged. If you look at writeMacInfo() in >> session/cmp_wr.c there's a flag 'parametersSent' that controls this, you can >> comment that out and cryptlib will always send the full set of parameters, >> although now you have to parse them all in order to find out that nothing's >> changed. I'll fix this for the next release. >> Great. Thanks a lot. I have commented it out and it's working. It's enough for me for now, and I will wait for next release :-). By the way, do you have some idea about my SCEP problem? Juraj _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Peter Gutmann
::
Rate this Message:
Juraj Michalak <juraj.michalak@...> writes:
>Yes, I have checked and I cannot see any difference. I have tried many stupid >things, now I think I need some clever :-). With SCEP I'm still with >"Couldn't create SCEP request signing attributes". But SCEP is not so >important for me. CMP is important. I've just tried it (using the code and cert you posted) and it works fine, or at least as far as trying to connect to the SCEP server, which isn't present. Did you run into the problem before that point? Peter. _______________________________________________ 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. |
|
|
|
|
|
Re: CMP and SCEP problem
by Juraj Michalak
::
Rate this Message:
Peter Gutmann wrote:
> > Oh, and as a corollary: Could you set a breakpoint in createScepAttributes() > in session/scep.c and see where the error comes from? > > Peter. > cert/ext_add.c:245 checkTextStringData(data, dataLength,...): data = "skuska@neviem" dataLength = 13 ... if( !( nativeCharFlags[ ch ] & charTypeMask ) ) return( FALSE ); ... problem with '@' - in asn1CharFlags - it is only I (not PI) But I have not studied standards. Can you explain a little bit? It probably bad idea to have user name with @ but why not :-) Juraj. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Juraj Michalak
::
Rate this Message:
I have changed '@' to PI in asn1CharFlags (cert/dnstring.c) and I moved
to another error: error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -32 INFO: Invalid PKCS #7 certificate chain in CA response Juraj. _______________________________________________ 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. |
|
|
Re: CMP and SCEP problem
by Tomas Gustavsson-3
::
Rate this Message:
Yes, I meant those. /Tomas Juraj Michalak skrev: > Tomas Gustavsson wrote: >> >> In EJBCA you can configure if the complete certificate chain should be >> returned in the reply or not, simply by using a different URL. This is >> one thing I found out during compatibility testing that some expectes >> the full chain in the response and some don't want it. > Do you mean these? : > > http://localhost:8080/ejbca/publicweb/apply/scep/pkiclient.exe > http://localhost:8080/ejbca/publicweb/apply/scep/noca/pkiclient.exe > > because I have tried both of them and result is same. > > >> >> Cheers, >> Tomas >> >> >> Juraj Michalak skrev: >>> I have changed '@' to PI in asn1CharFlags (cert/dnstring.c) and I >>> moved to another error: >>> >>> error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -32 >>> INFO: Invalid PKCS #7 certificate chain in CA response >>> >>> Juraj. >>> >>> >>> _______________________________________________ >>> 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. >> _______________________________________________ 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. |
|
|
|
|
|
|
|
|
Re: CMP and SCEP problem
by Peter Gutmann
::
Rate this Message:
Juraj Michalak <juraj.michalak@...> writes:
>cert/ext_add.c:245 checkTextStringData(data, dataLength,...): > >data = "skuska@neviem" >dataLength = 13 > >... >if( !( nativeCharFlags[ ch ] & charTypeMask ) ) > return( FALSE ); >... Oh, that was information at a slightly lower level than I was expecting :-). Could you send me a stack trace showing how things got there (e.g. with a 'bt' command from gdb, preferably from a debug build)? CRYPT_ERROR_FAILED is something that you'd normally never see, it only occurs when cryptlib can't think of any other type of error code that it could use to report a problem (it's not present anywhere in the cert code, for example) so it'd be good to know how things got to that point. (Incidenally, we can also do this off-list if others aren't interested in all the details). Peter. _______________________________________________ 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. |
foo.der (348 bytes) | Free embeddable forum powered by Nabble | Forum Help |
