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):
00000b0: 310b 3009 0603 5504 0613 0244 4531 0930 1.0...U....DE1.0
00000c0: 0706 0355 0408 1300 3112 3010 0603 5504 ...U....1.0...U.
00000d0: 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=2&t=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.
