Re: Reg. type of certificate - CA / EE based on X509_check_ca().
Thanks for the reply Tom and Kyle H. Now i have below 2 questions: (1) Based on application's need, can we assume return codes 2, 3 and 4 as non-CA ? (2) If we get return code 4 basicConstraints absent but keyUsage present and keyCertSign asserted for a certificate, is this a valid certificate ? Because RFC 3280 says: The keyCertSign bit is asserted when the subject public key is used for verifying a signature on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (section 4.2.1.10) MUST also be asserted. Regards, Sanjaya On Tue, Jul 8, 2014 at 2:16 AM, Kyle Hamilton aerow...@gmail.com wrote: On 7/7/2014 2:40 AM, Sanjaya Joshi wrote: Hello, My application uses openssl 1.0.0, and it uses X509_check_ca() to find out if an X509 certificate is a CA certificate, or an End-entity (EE) certificate. The below are the possible return codes. /* return codes of X509_check_ca(): * 0 not a CA * 1 is a CA * 2 basicConstraints absent so maybe a CA * 3 basicConstraints absent but self signed V1. * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. */ My question here is, if we get return code as 4, should we consider this as a CA certificate or an EE certificate ? Any quick support in this regard is much appreciated. Regards, Sanjaya This depends on your environment, and the types of certificates that the CAs used issue. The reason the codes are differentiated is because the authors of the library can't make a blanket determination for the library's clients. :P -Kyle H
Re: Reg. type of certificate - CA / EE based on X509_check_ca().
This is unfortunately something that you need to figure out for yourself. The controlling standard is not RFC 3280, or in fact any of the RFCs. It is X.509, available from http://www.itu.int/. (You can get the latest ratified edition for no cost.) However: 2 should probably not be considered a CA if you are expecting RFC3280 compliance. 3 is usually considered a CA, because self-signed V1 CAs were kept in legacy production in many circumstances. This technically violates RFC3280, but there at least used to be many examples of things that expected it anyway. 4 should probably not be considered a CA if you are expecting RFC3280 compliance. -Kyle H On 7/8/2014 1:13 AM, Sanjaya Joshi wrote: Thanks for the reply Tom and Kyle H. Now i have below 2 questions: (1) Based on application's need, can we assume return codes 2, 3 and 4 as non-CA ? (2) If we get return code 4 basicConstraints absent but keyUsage present and keyCertSign asserted for a certificate, is this a valid certificate ? Because RFC 3280 says: The keyCertSign bit is asserted when the subject public key is used for verifying a signature on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (section 4.2.1.10) MUST also be asserted. Regards, Sanjaya On Tue, Jul 8, 2014 at 2:16 AM, Kyle Hamilton aerow...@gmail.com mailto:aerow...@gmail.com wrote: On 7/7/2014 2:40 AM, Sanjaya Joshi wrote: Hello, My application uses openssl 1.0.0, and it uses X509_check_ca() to find out if an X509 certificate is a CA certificate, or an End-entity (EE) certificate. The below are the possible return codes. /* return codes of X509_check_ca(): * 0 not a CA * 1 is a CA * 2 basicConstraints absent so maybe a CA * 3 basicConstraints absent but self signed V1. * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. */ My question here is, if we get return code as 4, should we consider this as a CA certificate or an EE certificate ? Any quick support in this regard is much appreciated. Regards, Sanjaya This depends on your environment, and the types of certificates that the CAs used issue. The reason the codes are differentiated is because the authors of the library can't make a blanket determination for the library's clients. :P -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
Re: Reg. type of certificate - CA / EE based on X509_check_ca().
The controlling standard is not RFC 3280, or in fact any of the RFCs. It is X.509, available from http://www.itu.int/. (You can get the latest ratified edition for no cost.) If its a server certificate issued by a CA intended to be consumed by browsers (or other related services), then the CA likely issued under the CA/Browser Forums Baseline Requirements and EV Guide; not RFCs like 5280 and 6125. You can find them at http://cabforum.org/baseline-requirements-documents/ and http://cabforum.org/extended-validation-2/. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OS/390 z/OS Help Needed
I am new to this forum so please excuse me if I do not do this right. I am working on a z/OS 1.13 system aka OS/390 aka MVS. We have the need to parse X509 certificates. We were using an older version, 0.9.6a, but found that it did not interpret new signing algorithms correctly. I pulled down 1.0.1h and after a few known glitches, I was able to compile it. It does what I need in the sense that it now interprets the newer algorithms but it fails on the certificate time fields. I am doing this command openssl x509 -noout -in certfile -text and I get this output (serial number and signer removed): Certificate: Data: Version: 3 (0x2) Serial Number: Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ... Validity Not Before: Bad time value I am not sure how to proceed. If anyone could instruct me or direct me, I would appreciate it. Tim T.
Re: OS/390 z/OS Help Needed
Am 08.07.2014 18:10, schrieb T. Travers: I am new to this forum so please excuse me if I do not do this right. I am working on a z/OS 1.13 system aka OS/390 aka MVS. We have the need to parse X509 certificates. We were using an older version, 0.9.6a, but found that it did not interpret new signing algorithms correctly. I pulled down 1.0.1h and after a few known glitches, I was able to compile it. It does what I need in the sense that it now interprets the newer algorithms but it fails on the certificate time fields. I am doing this command opensslx509 -noout-in /certfile/ -text and I get this output (serial number and signer removed): Certificate: Data: Version: 3 (0x2) Serial Number: Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ... Validity Not Before: Bad time value I am not sure how to proceed. If anyone could instruct me or direct me, I would appreciate it. Tim T. Iirc some parts of the ASN1 code was rewritten in the 0.9.7 line (with EBCDIC specific parts being commented out). Please look at bug tracker entry #843 (http://rt.openssl.org/Ticket/Display.html?id=843), which contains a patch set for 0.9.7c and 0.9.7j. Unfortunately i still found not enough time for submitting a correspondig patch for the 1.0.x lines, but maybe the crypto/asn1/* files haven't changed too much for the patches still being useful. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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
Re: undefined reference to FIPS_mode_set'
You need to compile the FIPS module and then a version of OpenSSL that uses that module. See https://www.openssl.org/docs/fips/UserGuide.pdf for links to appropriate documentation, depending on which version of the FIPS module you need to use (probably the latest one if you don't know you need the 1.0 module). Finally, after you've done that, you need to make sure your application is linking the OpenSSL library(ies) that you just compiled for FIPS mode, and not whatever was distributed with the OS. If you don't really need FIPS mode (or don't know why you need FIPS mode), though, don't call FIPS_mode_set(). :) TOM -- Original Message -- From: Kay Shamsa kay.sha...@jci.com To: openssl-users@openssl.org openssl-users@openssl.org Sent: 7/7/2014 8:30:16 PM Subject: undefined reference to FIPS_mode_set' Hi; I am using encryption to broadcast messages in Linux environment. When using FIPS_mode_set(1) I get the error message of undefined reference to FIPS_mode_set'. How can I fix this error. Thanks Kay --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
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
On Mon, Jul 07, 2014, Dave Thompson wrote: 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. OpenSSL currently doesn't perform the full canonicalisation of RFC5280. 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
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
