> From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton > Sent: Tuesday, July 08, 2014 16:20
> On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles > <charles.ba...@allworx.com> wrote: > > I figured it out and am now wondering if there is a defect in the openssl > verify command. This suggestion from Dave Thompson: > > I would first try x509 -noout -subject|issuer -nameopt multiline,show_type > > and see if that helps. > > Pointed me in the right direction. What i found was that Issuer for > certificate A, which was the one that was NOT working, looked like this: > > [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer - > nameopt multiline,show_type -in CertA.pem > > issuer= > > countryName = UTF8STRING:US <snip> > > While the issuer for certificate B and subject for my CA looked like this: > > [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer - > nameopt multiline,show_type -in CertB.pem > > issuer= > > countryName = PRINTABLESTRING:US <snip> > > So it looks like openssl verify is not taking the type of countryName into > account while the browsers are. Is this expected behavior or a defect? > > > Not sure if this is any consolation, but countryName is a > DirectoryString, and PrintableString is OK per RFC 5280 > (http://tools.ietf.org/html/rfc5280#section-4.1.2.6): Actually it's not. 4.1.2.4 Issuer says Name.RDN.AVA values are 'generally' DirectoryString, but see appendix A on p115: countryName is PrintableString size(2), presumably because its allowed values are from ISO 3166 which in turn uses ASCII letters. Similarly dnQualifier is PrintableString and emailAddress is IA5String. > > DirectoryString ::= CHOICE { > teletexString TeletexString (SIZE (1..MAX)), > printableString PrintableString (SIZE (1..MAX)), > universalString UniversalString (SIZE (1..MAX)), > utf8String UTF8String (SIZE (1..MAX)), > bmpString BMPString (SIZE (1..MAX)) } > > However, there is the following on page 23: > > When encoding attribute values of type DirectoryString, conforming > CAs MUST use PrintableString or UTF8String encoding, with the > following exceptions: > > (a) When the subject of the certificate is a CA, the subject > field MUST be encoded in the same way as it is encoded in the > issuer field (Section 4.1.2.4) in all certificates issued by > the subject CA. Thus, if the subject CA encodes attributes > in the issuer fields of certificates that it issues using the > TeletexString, BMPString, or UniversalString encodings, then > the subject field of certificates issued to that CA MUST use > the same encoding. > > So the DirectoryString must be the same type. You can't make it > utf8String in the server certificate's issuer and PrintableString in > the CA's subject. > 4.1.2.4 says name matching should use the rules in 7.1, which allow 'insignifcant' variations in the string values, and doesn't say anything specific I can find about the encoding. I'm not sure if X.509/X.has quite the same rules, or if CA's have historically done so (for certs that might still be usable). OpenSSL is generally pretty Postelian in accepting slightly 'broken' protocols and data to maximize interoperability. But 1.0.2 is slated to enhance chain validation, and checks like this might fit in there better than in the past "flag bits that always run out" approach. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
