AW: Accessing unknown certificate extensions by OID
Alright, I got it.
After inserting the structs etc. in order to hop through the extension, I got
down to the ASN1_OBJECT representing the professionOID.
OBJ_obj2txt(buf,buflen,obj,1) gives the OID I was looking for (first approach
was to create an object with that OID and use obj_cmp, which also works as
expected) and I can work with that.
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
Von: Natanael Mignon - michael-wessel.de
Gesendet: Freitag, 21. August 2009 14:00
An: openssl-users@openssl.org
Betreff: AW: Accessing unknown certificate extensions by OID
Hello,
ok, what I did so far is get the extension by OID. At least I know by now,
whether the extension is present or not:
[...]
X509 *client_cert = X509_STORE_CTX_get_current_cert(ctx);
const char *admoid = 1.3.36.8.3.3;
ASN1_OBJECT *admobj = NULL;
X509_EXTENSION *admext = NULL;
int extpos;
admobj = OBJ_txt2obj(admoid, 0);
if (admobj) {
extpos = X509_get_ext_by_OBJ(client_cert, admobj,-1);
if (extpos)
admext = X509_get_ext(client_cert, extpos);
if (!admext) {
ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, conn,
MWDE/nm: Extension '%s' (admission) not found in cert!,
admoid);
ok = FALSE;
[...]
Testing is positive: The extension is found by mod_ssl. But now I need to read
and compare the field professionOID (see specs in my initial post). So welcome
to asn1 parsing, I guess (because I'm not really familiar with that, I can only
guess)...
Any help welcome, as usual. :)
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
Von: Natanael Mignon - michael-wessel.de
Gesendet: Dienstag, 18. August 2009 16:13
An: openssl-users@openssl.org
Betreff: Accessing unknown certificate extensions by OID
Dear list,
another trial. ;)
We need to validate the existence and value of an X.509 extension in a client
certificate from within Apache/mod_ssl. The extension Admission is described
by ISIS-MTT and has OID 1.3.36.8.3.3:
AdmissionSyntax ::= SEQUENCE {
admissionAuthority GeneralName OPTIONAL,
contentsOfAdmissions SEQUENCE OF Admissions }
Admissions ::= SEQUENCE {
admissionAuthority [0] EXPLICIT GeneralName OPTIONAL,
namingAuthority [1] EXPLICIT NamingAuthority OPTIONAL,
professionInfos SEQUENCE OF ProfessionInfo }
NamingAuthority ::= SEQUENCE {
namingAuthorityId OBJECT IDENTIFIER OPTIONAL,
namingAuthorityUrl IA5String OPTIONAL,
namingAuthorityText DirectoryString(SIZE(1..128)) OPTIONAL}
ProfessionInfo ::= SEQUENCE {
namingAuthority [0] EXPLICIT NamingAuthority OPTIONAL,
professionItems SEQUENCE OF DirectoryString (SIZE(1..128)),
professionOIDs SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
registrationNumber PrintableString(SIZE(1..128)) OPTIONAL,
addProfessionInfo OCTET STRING OPTIONAL }
This does not exactly match what I found here:
http://vijairaj.blogspot.com/2009/01/parsing-and-using-custom-extension-in.html,
but is taken from the exact specifications we need to comply to.
This extension is not known to our OpenSSL version (0.9.8d) and I don't think
later versions do know it?!
Furthermore, the suggested code at the abovementioned article does not really
fit into mod_ssl and I am hesitating to customize OpenSSL itself as well now.
It should be possible to read and parse the extension by using ASN1 functions
without defining the whole extension for OpenSSL, as it can be displayed with
it's OID and raw data by openssl asn1parse -in cert, I think? What I am
looking for is a feasible approach to doing so from within mod_ssl.
Any help appreciated!
In other news: what I achieved already is validating the certificate's signing
algorithm and keylength, it's ExtendedKeyUsage data, the signing algorithm and
the producedAt date of the OCSP response from within mod_ssl - if anybody is
interested... I also 'fixed' the receipt of the actual OCSP response, which
failed, if their was an empty line read at the beginning of the response, maybe
due to a lag in traffic... (not valid code style according to Apache/httpd, I
guess :( ).
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
IT - beraten | planen | umsetzen | betreiben
__
michael-wessel.de Informationstechnologie GmbH
Krausenstraße 50
30171 Hannover
Germany
fon (+49) 511 260 911-0 (DW -13)
fax (+49) 511 318 039-9
eMailn...@michael-wessel.de
web www.michael-wessel.de
Geschäftsführer: Michael Wessel Dipl. Phys.
Amtsgericht Hannover
HR B 59031
Alle Produktnamen und Firmennamen sind ggfs. eingetragene Warenzeichen und/oder
Markennamen der jeweiligen Hersteller.
Angebote freibleibend, Irrtümer und Druckfehler vorbehalten.
Lieferung vorbehaltlich ausreichender Selbstbelieferung.
© 2009 michael-wessel.de
__
OpenSSL Project
AW: Accessing unknown certificate extensions by OID
Hi and thanks for your continued help! Meanwhile I did indeed define the syntax of the extension and get my way through to the leaf being an ASN1_OBJECT representing the professionOID. Now my lack of knowledge strikes back: I want to check, whether a professionOID of 1.2.276.0.76.4.88 is included in the extension. What I get from i2d_ASN1_OBJECT(profoid, NULL) is plain and simple 9. I still fail to find the method that will present this notation of an OID... Mit freundlichen Grüßen / Kind regards Natanael Mignon Von: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] im Auftrag von Dr. Stephen Henson [st...@openssl.org] Gesendet: Samstag, 22. August 2009 13:50 An: openssl-users@openssl.org Betreff: Re: Accessing unknown certificate extensions by OID Yes you can call X509_EXTENSION_get_data() to get the encoded extension as an ASN1_OCTET_STRING structure. From that ASN1_STRING_length() and ASN1_STRING_data() will get you the data itself. Then it is ASN1 parsing time... there are numerous examples in the OpenSSL code itself, see crypto/cms/cms_asn1.c for a more recent one. Once you have an appropriate ASN1 module you can use d2i_foo() (or whatever you call it) to decode the data you extracted above. Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: Undocumented functions/macros/structs
Hello, what I've been doing lately is repeatedly grep-ing my way through OpenSSL source code in order to find examples and definitions of such functions. Very helpful to my mind. :) Mit freundlichen Grüßen / Kind regards Natanael Mignon -Ursprüngliche Nachricht- Von: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] Im Auftrag von barcaroller Gesendet: Samstag, 22. August 2009 00:17 An: openssl-users@openssl.org Betreff: Undocumented functions/macros/structs I was looking at the OpenSSL source code and some open-source applications using OpenSSL, and I came across functions like X509_get_issuer_name() and X509_get_pubkey(), and macros like X509_extract_key(). These seem to be very useful but I could not find them anywhere in the online OpenSSL documentation or the OpenSSL man pages. Nor could I find any information about the fields of many of the important structs (e.g. EVP_PKEY), which means I won't know how to reliably read/write from/to these structs. Are these functions/macros/structs documented somewhere? If not, what would be the recommended method of getting more information about them? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: Accessing unknown certificate extensions by OID
Hello,
ok, what I did so far is get the extension by OID. At least I know by now,
whether the extension is present or not:
[...]
X509 *client_cert = X509_STORE_CTX_get_current_cert(ctx);
const char *admoid = 1.3.36.8.3.3;
ASN1_OBJECT *admobj = NULL;
X509_EXTENSION *admext = NULL;
int extpos;
admobj = OBJ_txt2obj(admoid, 0);
if (admobj) {
extpos = X509_get_ext_by_OBJ(client_cert, admobj,-1);
if (extpos)
admext = X509_get_ext(client_cert, extpos);
if (!admext) {
ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, conn,
MWDE/nm: Extension '%s' (admission) not found in cert!,
admoid);
ok = FALSE;
[...]
Testing is positive: The extension is found by mod_ssl. But now I need to read
and compare the field professionOID (see specs in my initial post). So welcome
to asn1 parsing, I guess (because I'm not really familiar with that, I can only
guess)...
Any help welcome, as usual. :)
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
Von: Natanael Mignon - michael-wessel.de
Gesendet: Dienstag, 18. August 2009 16:13
An: openssl-users@openssl.org
Betreff: Accessing unknown certificate extensions by OID
Dear list,
another trial. ;)
We need to validate the existence and value of an X.509 extension in a client
certificate from within Apache/mod_ssl. The extension Admission is described
by ISIS-MTT and has OID 1.3.36.8.3.3:
AdmissionSyntax ::= SEQUENCE {
admissionAuthority GeneralName OPTIONAL,
contentsOfAdmissions SEQUENCE OF Admissions }
Admissions ::= SEQUENCE {
admissionAuthority [0] EXPLICIT GeneralName OPTIONAL,
namingAuthority [1] EXPLICIT NamingAuthority OPTIONAL,
professionInfos SEQUENCE OF ProfessionInfo }
NamingAuthority ::= SEQUENCE {
namingAuthorityId OBJECT IDENTIFIER OPTIONAL,
namingAuthorityUrl IA5String OPTIONAL,
namingAuthorityText DirectoryString(SIZE(1..128)) OPTIONAL}
ProfessionInfo ::= SEQUENCE {
namingAuthority [0] EXPLICIT NamingAuthority OPTIONAL,
professionItems SEQUENCE OF DirectoryString (SIZE(1..128)),
professionOIDs SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
registrationNumber PrintableString(SIZE(1..128)) OPTIONAL,
addProfessionInfo OCTET STRING OPTIONAL }
This does not exactly match what I found here:
http://vijairaj.blogspot.com/2009/01/parsing-and-using-custom-extension-in.html,
but is taken from the exact specifications we need to comply to.
This extension is not known to our OpenSSL version (0.9.8d) and I don't think
later versions do know it?!
Furthermore, the suggested code at the abovementioned article does not really
fit into mod_ssl and I am hesitating to customize OpenSSL itself as well now.
It should be possible to read and parse the extension by using ASN1 functions
without defining the whole extension for OpenSSL, as it can be displayed with
it's OID and raw data by openssl asn1parse -in cert, I think? What I am
looking for is a feasible approach to doing so from within mod_ssl.
Any help appreciated!
In other news: what I achieved already is validating the certificate's signing
algorithm and keylength, it's ExtendedKeyUsage data, the signing algorithm and
the producedAt date of the OCSP response from within mod_ssl - if anybody is
interested... I also 'fixed' the receipt of the actual OCSP response, which
failed, if their was an empty line read at the beginning of the response, maybe
due to a lag in traffic... (not valid code style according to Apache/httpd, I
guess :( ).
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
IT - beraten | planen | umsetzen | betreiben
__
michael-wessel.de Informationstechnologie GmbH
Krausenstraße 50
30171 Hannover
Germany
fon (+49) 511 260 911-0 (DW -13)
fax (+49) 511 318 039-9
eMailn...@michael-wessel.de
web www.michael-wessel.de
Geschäftsführer: Michael Wessel Dipl. Phys.
Amtsgericht Hannover
HR B 59031
Alle Produktnamen und Firmennamen sind ggfs. eingetragene Warenzeichen und/oder
Markennamen der jeweiligen Hersteller.
Angebote freibleibend, Irrtümer und Druckfehler vorbehalten.
Lieferung vorbehaltlich ausreichender Selbstbelieferung.
© 2009 michael-wessel.de
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Accessing unknown certificate extensions by OID
Dear list,
another trial. ;)
We need to validate the existence and value of an X.509 extension in a client
certificate from within Apache/mod_ssl. The extension Admission is described
by ISIS-MTT and has OID 1.3.36.8.3.3:
AdmissionSyntax ::= SEQUENCE {
admissionAuthority GeneralName OPTIONAL,
contentsOfAdmissions SEQUENCE OF Admissions }
Admissions ::= SEQUENCE {
admissionAuthority [0] EXPLICIT GeneralName OPTIONAL,
namingAuthority [1] EXPLICIT NamingAuthority OPTIONAL,
professionInfos SEQUENCE OF ProfessionInfo }
NamingAuthority ::= SEQUENCE {
namingAuthorityId OBJECT IDENTIFIER OPTIONAL,
namingAuthorityUrl IA5String OPTIONAL,
namingAuthorityText DirectoryString(SIZE(1..128)) OPTIONAL}
ProfessionInfo ::= SEQUENCE {
namingAuthority [0] EXPLICIT NamingAuthority OPTIONAL,
professionItems SEQUENCE OF DirectoryString (SIZE(1..128)),
professionOIDs SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
registrationNumber PrintableString(SIZE(1..128)) OPTIONAL,
addProfessionInfo OCTET STRING OPTIONAL }
This does not exactly match what I found here:
http://vijairaj.blogspot.com/2009/01/parsing-and-using-custom-extension-in.html,
but is taken from the exact specifications we need to comply to.
This extension is not known to our OpenSSL version (0.9.8d) and I don't think
later versions do know it?!
Furthermore, the suggested code at the abovementioned article does not really
fit into mod_ssl and I am hesitating to customize OpenSSL itself as well now.
It should be possible to read and parse the extension by using ASN1 functions
without defining the whole extension for OpenSSL, as it can be displayed with
it's OID and raw data by openssl asn1parse -in cert, I think? What I am
looking for is a feasible approach to doing so from within mod_ssl.
Any help appreciated!
In other news: what I achieved already is validating the certificate's signing
algorithm and keylength, it's ExtendedKeyUsage data, the signing algorithm and
the producedAt date of the OCSP response from within mod_ssl - if anybody is
interested... I also 'fixed' the receipt of the actual OCSP response, which
failed, if their was an empty line read at the beginning of the response, maybe
due to a lag in traffic... (not valid code style according to Apache/httpd, I
guess :( ).
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
IT - beraten | planen | umsetzen | betreiben
__
michael-wessel.de Informationstechnologie GmbH
Krausenstraße 50
30171 Hannover
Germany
fon (+49) 511 260 911-0 (DW -13)
fax (+49) 511 318 039-9
eMailn...@michael-wessel.de
web www.michael-wessel.de
Geschäftsführer: Michael Wessel Dipl. Phys.
Amtsgericht Hannover
HR B 59031
Alle Produktnamen und Firmennamen sind ggfs. eingetragene Warenzeichen und/oder
Markennamen der jeweiligen Hersteller.
Angebote freibleibend, Irrtümer und Druckfehler vorbehalten.
Lieferung vorbehaltlich ausreichender Selbstbelieferung.
© 2009 michael-wessel.de
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
AW: OCSP_basic_verify:root ca not trusted
-Ursprüngliche Nachricht- Von: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] Im Auftrag von Dr. Stephen Henson Gesendet: Dienstag, 28. Juli 2009 23:43 An: openssl-users@openssl.org Betreff: Re: OCSP_basic_verify:root ca not trusted On Tue, Jul 28, 2009, Randy Turner wrote: Is the OCSP response verification algorithm described below implemented exclusively by OpenSSL, or is the algorithm an implementation of a particular RFC algorithm? It is follows the rules in RFC2560. The CA signing and delegate signing are taked directly from RFC2560. It also allows a CA which Matches a local configuration of OCSP signing authority for the certificate in question and that's the global responder configuration option. [NM] RFC2560 says: All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: -- the CA who issued the certificate in question -- a Trusted Responder whose public key is trusted by the requester -- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA We have the second case: The responder has to be trusted to answer requests in this manner. That's why we already have the responder's signer certificate in /etc/ssl/certs. Still, the response verification fails. We probably have to trust the root CA for OCSP signing as stated in http://www.openssl.org/docs/apps/ocsp.html: If the OCSP responder is a ``global responder'' which can give details about multiple CAs and has its own separate certificate chain then its root CA can be trusted for OCSP signing. For example: openssl x509 -in ocspCA.pem -addtrust OCSPSigning -out trustedCA.pem So that's what we are going to test next... Mit freundlichen Grüßen / Kind regards Natanael Mignon IT-Dienstleistungen: beraten | planen | umsetzen | betreiben __ fon (+49) 511 260 911-0 (DW: - 13) fax (+49) 511 318 039-9 eMail n...@michael-wessel.de web www.michael-wessel.de Bitte senden Sie wichtige E-Mails stets auch an serv...@michael-wessel.de, um sicherzustellen, dass diese zeitnah bearbeitet werden. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OCSP_basic_verify:root ca not trusted
Dear list, another problem with the OCSP-handling in Apache/mod_ssl: [Tue Jul 28 14:27:12 2009] [error] SSL Library Error: error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted [Tue Jul 28 14:27:12 2009] [error] failed to verify the OCSP response! Now, of course this could be just correct and there could be an error with the certificate store etc. But we get this error, when a client authenticates using certificate b3, which is issued by CA3 and the OCSP request is sent to ocsp3. CA3 is trusted for Apache and also present and symlinked in /etc/ssl/certs. If the client authenticates using cert b2, which is issued by CA2 and the responder is ocsp2, everything is fine. CA2 is trusted in the same way as CA3. If the client authenticates using cert b1, which is issued by CA1 and the responder is ocsp1, everything is fine. CA1 is trusted in the same way as CA2 and CA3. To verify the OCSP handling, we execute the requests manually: openssl ocsp -issuer CA1 -serial serial of b1 -uri ocsp1... -- GOOD, verify OK. openssl ocsp -issuer CA2 -serial serial of b2 -uri ocsp2... -- GOOD, verify OK. openssl ocsp -issuer CA3 -serial serial of b3 -uri ocsp3... -- GOOD, verify FAIL. openssl ocsp -issuer CA1 -serial serial of b3 -uri ocsp3... -- GOOD, verify OK! So obviously the OCSP signer certificate of ocsp3 has been issued by CA1 (what we found in the OCSP response itself, of course). What we did not get straight so far: How is the issuer certificate determined to validate the OCSP signer certificate against in the library functions (i.e. when Apache calls the OCSP verify functions)? What might be needed here to get OpenSSL validate against the correct issuer certificate? Mit freundlichen Grüßen / Kind regards Natanael Mignon IT-Dienstleistungen: beraten | planen | umsetzen | betreiben __ michael-wessel.de Informationstechnologie GmbH Krausenstraße 50 30171 Hannover Germany fon (+49) 511 260 911-0 (DW: - 13) fax (+49) 511 318 039-9 eMail n...@michael-wessel.demailto:n...@michael-wessel.de webwww.michael-wessel.dehttp://www.michael-wessel.de/ Bitte senden Sie wichtige E-Mails stets auch an serv...@michael-wessel.demailto:serv...@michael-wessel.de, um sicherzustellen, dass diese zeitnah bearbeitet werden. Geschäftsführer: Michael Wessel Dipl. Phys. Amtsgericht Hannover HR B 59031
AW: Re: OCSP_basic_verify:root ca not trusted
Hello Steve,
thanks for the quick and enlightening reply - I was wondering about the ocsp
signer cert being issued by a different CA as unusual, but the idea of global
responders was not familiar. We will check this with the provider/trustcenter.
Mit besten Grüßen
- Natanael Mignon
Blackberry - Dienste erhalten Sie bei uns!
- Originalnachricht -
Von: owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org
An: openssl-users@openssl.org openssl-users@openssl.org
Gesendet: Tue Jul 28 18:41:30 2009
Betreff: Re: OCSP_basic_verify:root ca not trusted
On Tue, Jul 28, 2009, Natanael Mignon - michael-wessel.de wrote:
Dear list,
another problem with the OCSP-handling in Apache/mod_ssl:
[Tue Jul 28 14:27:12 2009] [error] SSL Library Error: error:27069070:OCSP
routines:OCSP_basic_verify:root ca not trusted
[Tue Jul 28 14:27:12 2009] [error] failed to verify the OCSP response!
Now, of course this could be just correct and there could be an error with
the certificate store etc. But we get this error, when a client authenticates
using certificate b3, which is issued by CA3 and the OCSP request is sent
to ocsp3. CA3 is trusted for Apache and also present and symlinked in
/etc/ssl/certs.
If the client authenticates using cert b2, which is issued by CA2 and the
responder is ocsp2, everything is fine. CA2 is trusted in the same way as
CA3.
If the client authenticates using cert b1, which is issued by CA1 and the
responder is ocsp1, everything is fine. CA1 is trusted in the same way as
CA2 and CA3.
To verify the OCSP handling, we execute the requests manually:
openssl ocsp -issuer CA1 -serial serial of b1 -uri ocsp1... -- GOOD,
verify OK.
openssl ocsp -issuer CA2 -serial serial of b2 -uri ocsp2... -- GOOD,
verify OK.
openssl ocsp -issuer CA3 -serial serial of b3 -uri ocsp3... -- GOOD,
verify FAIL.
openssl ocsp -issuer CA1 -serial serial of b3 -uri ocsp3... -- GOOD,
verify OK!
So obviously the OCSP signer certificate of ocsp3 has been issued by CA1
(what we found in the OCSP response itself, of course).
What we did not get straight so far: How is the issuer certificate determined
to validate the OCSP signer certificate against in the library functions
(i.e. when Apache calls the OCSP verify functions)? What might be needed here
to get OpenSSL validate against the correct issuer certificate?
I'm not sure what the problem is here. According to your description the
responder ocsp3 is misconfigured and OpenSSL is behaving as you would expect.
That error is due to the way OCSP responses are verified. It first tries to
see if the response should be automatically accepted (responder certificate is
issued by the CA or is the CA itself) if that fails it checks to see if the
certificate is allowed to sign responses for *any* CA, so called global
responders. If thet fails you get the root CA not trusted meaning it isn't
trusted as a global responder.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
+--+
| - michael-wessel.de Secure E-Mail Status - |
+--+
| - Die Nachricht war weder verschluesselt noch digital unterschrieben |
+--+
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
AW: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data
Updated details. If we do compare the two requests (one failing because of not enough data, one working fine), there are obvious differences in receiving the response. Working fine: [Tue Jul 07 14:32:24 2009] [debug] ssl_util_ocsp.c(104): [client 10.200.48.140] sending request to OCSP responder [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Date: Tue, 07 Jul 2009 13:32:52 GMT [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Server: Apache-Coyote/1.1 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Content-Type: application/ocsp-response [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Content-Length: 1585 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Connection: close [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(250): [client 10.200.48.140] OCSP response: got 1585 bytes, 1585 total [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(258): [client 10.200.48.140] MWDE/nm: OCSP response in data: 0\x82\x06-\n\x01 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(234): [client 10.200.48.140] OCSP response: got EOF Failing: [Tue Jul 07 14:38:23 2009] [debug] ssl_util_ocsp.c(104): [client 172.30.64.154] sending request to OCSP responder [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: Date: Tue, 07 Jul 2009 13:38:51 GMT [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: content-type: application/ocsp-response [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: content-length: 1212 [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: Connection: close [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(234): [client 172.30.64.154] OCSP response: got EOF [Tue Jul 07 14:38:24 2009] [error] SSL Library Error: error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough data [Tue Jul 07 14:38:24 2009] [error] [client 172.30.64.154] failed to decode OCSP response data This actually looks like we do not receive any response data except headers. The code branch, where we print out the response data is not even called, because the receive-bucket seems to be empty after the headers have been read out (Apache/mod_ssl/ssl_util_ocsp.c, while (!APR_BRIGADE_EMPTY(bb)) -- copies from bb to bio). What disturbes me: Doing the same request from the same system with a generic OCSP-client (Java-based, using Bouncycastle-lib) works fine (OCSP Response: GOOD). Any ideas? Mit freundlichen Grüßen / Kind regards Natanael Mignon Von: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] im Auftrag von Dr. Stephen Henson [st...@openssl.org] Gesendet: Freitag, 3. Juli 2009 18:39 An: openssl-users@openssl.org Betreff: Re: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data I suggest you check to see if you really get 1212 bytes of data in the response and log them somewhere. If you post the result it can be analysed to see if the response is valid. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data
Dear list, another update - we got it. [Fri Jul 10 10:28:39 2009] [error] [client 172.30.64.154] MWDE/nm: OCSP response line unstripped: HTTP/1.1 200 OK [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: Date: Fri, 10 Jul 2009 09:29:06 GMT [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: content-type: application/ocsp-response [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: content-length: 1212 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: Connection: close [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(260): [client 172.30.64.154] MWDE/nm, read turn 1: OCSP response read, but len == 0 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(284): [client 172.30.64.154] OCSP response: got 0 bytes, 0 total [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(292): [client 172.30.64.154] MWDE/nm, read turn 1: OCSP response in data: nul [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(284): [client 172.30.64.154] OCSP response: got 1212 bytes, 1212 total [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(292): [client 172.30.64.154] MWDE/nm, read turn 2: OCSP response in data: 0\x82\x04\xb8\n\x01 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(260): [client 172.30.64.154] MWDE/nm, read turn 3: OCSP response read, but len == 0 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(284): [client 172.30.64.154] OCSP response: got 0 bytes, 1212 total [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(292): [client 172.30.64.154] MWDE/nm, read turn 3: OCSP response in data: Solution was to change the break-conditions in Apache's mod_ssl (ssl_util_ocsp.c). The original code did break the loop reading response data from bucket to bio, if it read an EOF *or* it read data of length == 0. Now we got this strange responder, which sends 0 bytes in the first line of response. By only breaking the loop, if EOF is read, we get to the second (and third, until bucket is empty or an EOF is read) line of the response. And guess what's in the second line? :) Thanks for the pointers to really check the data received! Mit freundlichen Grüßen / Kind regards Natanael Mignon Von: Natanael Mignon - michael-wessel.de [...@michael-wessel.de] Gesendet: Freitag, 10. Juli 2009 09:35 An: openssl-users@openssl.org Betreff: AW: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data Updated details. If we do compare the two requests (one failing because of not enough data, one working fine), there are obvious differences in receiving the response. Working fine: [Tue Jul 07 14:32:24 2009] [debug] ssl_util_ocsp.c(104): [client 10.200.48.140] sending request to OCSP responder [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Date: Tue, 07 Jul 2009 13:32:52 GMT [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Server: Apache-Coyote/1.1 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Content-Type: application/ocsp-response [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Content-Length: 1585 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Connection: close [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(250): [client 10.200.48.140] OCSP response: got 1585 bytes, 1585 total [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(258): [client 10.200.48.140] MWDE/nm: OCSP response in data: 0\x82\x06-\n\x01 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(234): [client 10.200.48.140] OCSP response: got EOF Failing: [Tue Jul 07 14:38:23 2009] [debug] ssl_util_ocsp.c(104): [client 172.30.64.154] sending request to OCSP responder [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: Date: Tue, 07 Jul 2009 13:38:51 GMT [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: content-type: application/ocsp-response [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: content-length: 1212 [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: Connection: close [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(234): [client 172.30.64.154] OCSP response: got EOF [Tue Jul 07 14:38:24 2009] [error] SSL Library Error: error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough data [Tue Jul 07 14:38:24 2009] [error] [client 172.30.64.154] failed to decode OCSP response data This actually looks like we do not receive any response data except headers. The code branch, where we print out the response data
