Re: Certificate problem - SOLVED
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 20:33 On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 16:20 ... 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. So countryName is not PrintableString? countryName IS PrintableString. countryName is specified as exactly PrintableString, unlike other fields which are specified as DirectoryString where DirectoryString is CHOICE that includes PrintableString as one option so those fields MAY BE PrintableString. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Comparison trickery (Was: Certificate problem - SOLVED)
Op 9 jul. 2014, om 02:33 heeft Jeffrey Walton noloa...@gmail.com het volgende geschreven: On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 16:20 ... 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. So countryName is not PrintableString? Slightly off topic - we did encounter a situation not very long ago where an attempt was made to evade specific firewall rules on a DN by having one of the RDNs (from memory it was the CN) not be the usual UTF8String(0xC) but an IA5String(0x16) - while relying on the app-side infrastructure to match them at application/java compareTo(). Dw.
RE: Certificate problem - SOLVED
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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt multiline,show_type -in CA.pem issuer= countryName = PRINTABLESTRING:US stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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? Again, thanks for all the help everybody! CHAD From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Dave Thompson [dthomp...@prinpay.com] Sent: Monday, July 07, 2014 4:03 PM To: openssl-users@openssl.org Subject: RE: Certificate problem From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles Sent: Sunday, July 06, 2014 22:42 I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? You are installing in the correct placeS which can be different per browser, right? The only thing that springs to mind that could be invisible is string types and some options of the cert Issuer fields vs the CA Subject. RFC 5280 requires a fairly complicated Unicode-aware comparison algorithm which I believe openssl does (it definitely canonicalizes before comparison, but I haven't gone through the canonicalization to make sure it exactly matches the RFC); browsers might not do the same (perhaps indirectly) although I'd be surprised if NONE do. I would first try x509 -noout -subject|issuer -nameopt multiline,show_type and see if that helps. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org CA.pem Description: CA.pem CertA.pem Description: CertA.pem
Re: Certificate problem - SOLVED
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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt multiline,show_type -in CA.pem issuer= countryName = PRINTABLESTRING:US stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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): 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. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate problem - SOLVED
Yet openssl verify said OK to both of my certificates against the CA certificate... so is it incorrectly neglecting to compare the types when it tries to build the chain of certificates? Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 charles.ba...@allworx.com | 585.421.5565 From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Jeffrey Walton [noloa...@gmail.com] Sent: Tuesday, July 08, 2014 4:19 PM To: OpenSSL Users List Subject: Re: Certificate problem - SOLVED 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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt multiline,show_type -in CA.pem issuer= countryName = PRINTABLESTRING:US stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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): 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. Jeff __ 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
RE: Certificate problem - SOLVED
Also don't these lines of the spec: countryName ATTRIBUTE ::= { WITH SYNTAX PrintableString (SIZE (2)) -- IS 3166 codes only ID id-at-countryName } indicate that countryName is restricted to the PrintableString (SIZE (2)) type which is a restricted subset of DirectoryString? Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 charles.ba...@allworx.com | 585.421.5565 From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Barbe, Charles [charles.ba...@allworx.com] Sent: Tuesday, July 08, 2014 4:44 PM To: openssl-users@openssl.org Subject: RE: Certificate problem - SOLVED Yet openssl verify said OK to both of my certificates against the CA certificate... so is it incorrectly neglecting to compare the types when it tries to build the chain of certificates? Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 charles.ba...@allworx.com | 585.421.5565 From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Jeffrey Walton [noloa...@gmail.com] Sent: Tuesday, July 08, 2014 4:19 PM To: OpenSSL Users List Subject: Re: Certificate problem - SOLVED 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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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 stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt multiline,show_type -in CA.pem issuer= countryName = PRINTABLESTRING:US stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view 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): 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. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http
Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 4:48 PM, Barbe, Charles charles.ba...@allworx.com wrote: Also don't these lines of the spec: countryName ATTRIBUTE ::= { WITH SYNTAX PrintableString (SIZE (2)) -- IS 3166 codes only ID id-at-countryName } indicate that countryName is restricted to the PrintableString (SIZE (2)) type which is a restricted subset of DirectoryString? That may apply. I see it under A.1. Explicitly Tagged Module, 1988 Syntax, but I'm not sure what the introduction is telling me in Appendix A. If it matters... looking at CA and server certificates I created using OpenSSL's API (a few months ago) show the country code is PRINTABLESTRING in both. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate problem - SOLVED
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 16:20 ... 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. So countryName is not PrintableString? Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org