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
