Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?

Simner, John
Dear All,
I am working on an embedded product which has the OpenSSL 0.9.8w library and acts as a client.
It is communicating with another product which has the OpenSSL 0.9.8e library and acts as a server.
 
A customer has supplied the client certificate for the server and the associated root CA that signed the client certificate.
The client certificate is installed on the server, the root CA is installed on the client, and the client is authenticating the server.
Unfortunately, the client is failing the authentication with the error 20 cant find local issuer certificate.
 
Having spent sometime investigating why this is, I found the server certificate has the issuer in the form C=... ST=... L=... O=... OU=... CN=...
and the root CA has the identical string for both issuer and subject in the reverse order CN=... OU=... O=... L=... St.. C...
As a result X509_Name_cmp fails the comparison.
 
I thought the ordering of the distinguished name in X509 is unimportant, yet it appears to be in OpenSSL.
Is this true?
 
I have trawled the web and found the following statement...
According to X.500, both forms should be acceptable and a order-insensitive way to compare DN is defined. Unfortunately, looking up in their keystore for trusted certificates, many libraries compare issuer DN in the same order they are encoded. This problem affects especially OpenSSL-based software, which computes hash on DN to speed up certificate search.

My reason for seeking assistance is to have the facts so that I can present them to the customer and suggest any restrictions that may be appropriate to the creation of the certificates.
 
Thank you for your assistance and I look forward to your response.
 
Thanks..
John
 

John Simner BSc(Hons) MSc CEng. MIET
Software Engineer
Siemens Enterprise Communications Limited

Tel: + 44 (0) 1908 817378
Please Note New Telephone number from 11/09/10: + 44 (0) 1908 817378
Email: [hidden email]

www.siemens.co.uk/enterprise

<a title="blocked::blocked::blocked::http://www.siemens.co.uk/open blocked::blocked::http://www.siemens.co.uk/open" href="blocked::blocked::http://www.siemens.co.uk/open">Communication for the open minded

Siemens Enterprise Communications Limited.

Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.

Registered No: 5903714, England.

Siemens Enterprise Communications Ltd is a Trademark Licensee of Siemens AG.

This communication contains information which is confidential and may also be privileged.  It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this email.

P Please consider the environment - do you really need to print this email?

 
Reply | Threaded
Open this post in threaded view
|

RE: Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?

Salz, Rich

I think either you mis-read the web page, or the author is confused.

 

Looking at RFC 2253, it quotes X.501 which says:

DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF

AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {

type  AttributeType,

value AttributeValue }

 

Note that a DN is defined as a SEQUENCE OF not a SET OF. This means that in a DN the order is important.  Within an RDN, which is defined as SET OF, the order is not important.  Unfortunately, given the standard output formats for DN, it is hard to tell if you are seeing one RDN or multiple.  In order to know, you have to look at the schema for the directory, if you can find it. L Or hope that people read and follow the RFC very carefully (such as the examples in section 5).

 

Shor t answer: order counts.

 

                /r$

 

-- 

Principal Security Engineer

Akamai Technology

Cambridge, MA

 

Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?

Erwann ABALEA
In reply to this post by Simner, John
Since you need authoritative elements, start by downloading and reading authoritative documents (all are freely available from ITU-T website).

X.509, section 7:
-----
[...]
The issuer and subject fields of each certificate are used, in part, to identify a valid path. For each pair of adjacent certificates in a valid certification path, the value of the subject field in one certificate shall match the value of the issuer field in the subsequent certificate. In addition, the value of the issuer field in the first certificate shall match the DN of the trust anchor. Only the names in these fields are used when checking validity of a certification path.
Names in certificate extensions are not used for this purpose. A certification path logically forms an unbroken chain of trusted points in the Directory Information Tree between two users wishing to authenticate. The precise method employed by users A and B to obtain certification paths A→B and B→A may vary. One way to facilitate this is to arrange a hierarchy of CAs, which may or may not coincide with all or part of the DIT hierarchy. The benefit of this is that users who have CAs in the hierarchy may establish a certification path between them using the Directory without any prior information. In order to allow for this each CA may store one certificate and one reverse certificate designated as corresponding to its superior CA. The distinguishedNameMatch matching rule, defined in 13.5.2 of ITU-T Rec. X.501 | ISO/IEC 9594-2, should be used to compare the Distinguished Name (DN) in the issuer field of one certificate with the DN in the subject field of another.
[...]
-----
The last sentence is the most important for your answer.

Then follow X.501, section 13.5.2 (with annotations from me):
-----
[...]
distinguishedNameMatch MATCHING-RULE ::= {
  SYNTAX DistinguishedName
  ID id-mr-distinguishedNameMatch }

A presented distinguished name value matches a target distinguished name value if and only if all of the following are true:
  a) the number of RDNs in each is the same;
  b) corresponding RDNs have the same number of AttributeTypeAndValue; [EA: first RDNs are compared together, then second RDNs, etc]
  c) corresponding AttributeTypeAndValue (i.e., those in corresponding RDNs and with identical attribute types) have attribute values which match as described in 9.4. [EA: order in AVAs isn't important, only their value once normalized is]
[...]
-----

You can further download and read X.520 for exact name comparison rules (to be able to compare each name element, read the normalization process, etc).

In case it's not clear, subject and issuer are sequences of RDNs (RelativeDistinguishedName), and an RDN is a set of AVA (AttributeTypeAndValue).

If you have a name that is represented as "C=DE, O=Siemens, CN=John Simner", then you have 3 RDNs, and each one has only 1 AVA. "C=DE" is the AVA of the first RDN (C is the type, DE is the value).

When an RDN is composed of several AVAs, AVAs are generally separated by '+' character (instead of ','). For example, "C=DE, O=Siemens, GN=John+SN=Simner", which is equal to "C=DE, O=Siemens, SN=Simner+GN=John".

This string representation is only informative.

-- 
Erwann ABALEA

Le 08/02/2013 16:42, Simner, John a écrit :
Dear All,
I am working on an embedded product which has the OpenSSL 0.9.8w library and acts as a client.
It is communicating with another product which has the OpenSSL 0.9.8e library and acts as a server.
 
A customer has supplied the client certificate for the server and the associated root CA that signed the client certificate.
The client certificate is installed on the server, the root CA is installed on the client, and the client is authenticating the server.
Unfortunately, the client is failing the authentication with the error 20 cant find local issuer certificate.
 
Having spent sometime investigating why this is, I found the server certificate has the issuer in the form C=... ST=... L=... O=... OU=... CN=...
and the root CA has the identical string for both issuer and subject in the reverse order CN=... OU=... O=... L=... St.. C...
As a result X509_Name_cmp fails the comparison.
 
I thought the ordering of the distinguished name in X509 is unimportant, yet it appears to be in OpenSSL.
Is this true?
 
I have trawled the web and found the following statement...
According to X.500, both forms should be acceptable and a order-insensitive way to compare DN is defined. Unfortunately, looking up in their keystore for trusted certificates, many libraries compare issuer DN in the same order they are encoded. This problem affects especially OpenSSL-based software, which computes hash on DN to speed up certificate search.

My reason for seeking assistance is to have the facts so that I can present them to the customer and suggest any restrictions that may be appropriate to the creation of the certificates.
 
Thank you for your assistance and I look forward to your response.
 
Thanks..
John
 

John Simner BSc(Hons) MSc CEng. MIET
Software Engineer
Siemens Enterprise Communications Limited

Tel: + 44 (0) 1908 817378
Please Note New Telephone number from 11/09/10: + 44 (0) 1908 817378
Email: [hidden email]

www.siemens.co.uk/enterprise

<a moz-do-not-send="true" title="blocked::blocked::blocked::http://www.siemens.co.uk/open blocked::blocked::http://www.siemens.co.uk/open" href="blocked::blocked::http://www.siemens.co.uk/open">Communication for the open minded

Siemens Enterprise Communications Limited.

Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.

Registered No: 5903714, England.

Siemens Enterprise Communications Ltd is a Trademark Licensee of Siemens AG.

This communication contains information which is confidential and may also be privileged.  It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this email.

P Please consider the environment - do you really need to print this email?

 

Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?

Peter Sylvester-3
Ording is important. unfortunately the default order shown in the textual
form is not the same as for ldap tools. using openssl asn1parse shows
the encoding, country code should come first.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]