Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?
Bonjour, Le 13/11/2013 11:35, Igor Sverkos a écrit : Hi, please see the following certificate: -BEGIN CERTIFICATE- MIIEbTCCA1WgAwIBAgICLgAwDQYJKoZIhvcNAQEFBQAwQDELMAkGA1UEBhMCVVMx [...] uKnvqzQP10A7f3PBsGYRA2DCeMDavaEoizJnNyjCOQx4 -END CERTIFICATE- It seems to be a valid certificate for OpenSSL, right? OpenSSL can parse it, yes. But it isn't, see the OID 2.5.4.8 (stateOrProvinceName): 0b0: 310b 3009 0603 5504 0613 0244 4531 0930 1.0...UDE1.0 0c0: 0706 0355 0408 1300 3112 3010 0603 5504 ...U1.0...U. 0d0: 0713 094b 6172 6c73 7275 6865 3114 3012 ...Karlsruhe1.0. Octal sequence 3109300706035504081300.. The value has zero length. According to RFC 3280, which defines X.509 certficates, these entries, if they exist, must not have an empty value. RFC5280 doesn't define X.509 certificates, it defines a profile of X.509 certificates. X.509 defines X.509 certificates. Reading X.520 shows that the DirectoryString type disallows 0-sized elements. So you're right, this isn't a valid X.509 certificate. I found this problem while using FileZilla (which uses GnuTLS), which denied to connect to a host using such a (broken) certificate: Error: GnuTLS error -71 in gnutls_x509_crt_get_dn: ASN1 parser: Generic parsing error. Error: Could not get distinguished name of certificate subject, gnutls_x509_get_dn failed Error: Could not connect to server Following gnutls code is hard, but I think I tracked down to the faulty function. String objects are decoded as OCTETSTRING ones, and the ASN.1/DER parser can't parse OCTETSTRING objects whose length is = 0. The error returned is ASN1_GENERIC_ERROR. For further details please see: https://forum.filezilla-project.org/viewtopic.php?f=2t=31046 I am wondering why OpenSSL doesn't complain. Because it has a more tolerant parser. GNUtls is primitive in some aspects, DN parsing is one of them. Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL.
Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?
Hello, thank you for your response. There's one thing in your reply I don't understand: Erwann Abalea wrote: It seems to be a valid certificate for OpenSSL, right? OpenSSL can parse it, yes. [...] Reading X.520 shows that the DirectoryString type disallows 0-sized elements. So you're right, this isn't a valid X.509 certificate. [...] GNUtls is primitive in some aspects, DN parsing is one of them. Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL. If it isn't a valid X.509 certificate as you agreed, shouldn't openssl complain when I verify/establish a connection using AUTH TLS which will use this certificate? So for me it is not a question about tolerance like you said OpenSSL's ASN1 parser is more tolerant than GnuTLS (it uses libtasn1 BTW): If the certificate is invalid, OpenSSL should tell it and verify shouldn't pass. Not? -- Regards, Igor
Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?
Le 13/11/2013 13:30, Igor Sverkos a écrit : Hello, thank you for your response. There's one thing in your reply I don't understand: Erwann Abalea wrote: It seems to be a valid certificate for OpenSSL, right? OpenSSL can parse it, yes. [...] Reading X.520 shows that the DirectoryString type disallows 0-sized elements. So you're right, this isn't a valid X.509 certificate. [...] GNUtls is primitive in some aspects, DN parsing is one of them. Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL. If it isn't a valid X.509 certificate as you agreed, shouldn't openssl complain when I verify/establish a connection using AUTH TLS which will use this certificate? Well. It could be very strict. Would it solve the problem you have with gnutls? No. Does this tolerance have any security impact? No. So for me it is not a question about tolerance like you said OpenSSL's ASN1 parser is more tolerant than GnuTLS (it uses libtasn1 BTW): If the certificate is invalid, OpenSSL should tell it and verify shouldn't pass. Verifying the presented certificate with certtool from gnutls version 3.0.11 on my Ubuntu 13.10 works (haven't checked if they have special patches for this). Place your certificate+issuingCA+rootCA in a file, and run certtool -e --infile allcerts.pem.
