Paul Wouters writes: > > Recently I had an interesting issue come up. I needed to generate a > certificate with a specific OU= content that our openssl/python > code couldn't do, and I switched to nss's cert-util to generate > a cert of sets for a test. > > Then I noticed something strange. Let's say you have the following > DN specified for certificate generation: > > C=CZ, ST=Moravia, L=Brno, O=Test Example, OU="Global, Support, > Services", CN=server > > For openssl, when checking the subject of the cert, it matches in this > order. but when I generated the same certificate with nss cert-util > and re-read it back in openssl, it showed me: > > CN=server, OU="Global, Support, Services", O=Test Example, L=Brno, > ST=Moravia, C=CZ > > Note that C= and CN= are swapped. These are differences in the binary data, > not the presentation.
Most likely another assumes bitwise DN order, and other used LDAP DN order. Another is most significant part first, another is least significant part first. I.e., I assume you made certificate incorrectly when you switched to new tool, as you assumed it takes DN in same order than openssl tools took it. Most of the tools just take the DN you give to them and do not look at the order of C, ST, L, etc parts, but just encode the sequence in the order you gave them in. But some tools assume you give the DN in LDAP order which is reversed order from what you have in the actual binary DER, so they reverse the list before doing this encoding. >From RFC4514: ---------------------------------------------------------------------- 2.1. Converting the RDNSequence If the RDNSequence is an empty sequence, the result is the empty or zero-length string. Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first. ---------------------------------------------------------------------- If you look at the https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_certutil page you notice that examples do have DN in reverse order, i.e. CN first etc, while openssl takes them in other order. So it clearly assumes you give the DN in ldap order, not in the most significant part first order. BTW, If I remember right the reason for LDAP to use the least significant part first order was that it allowed searching the database using partial searches like "CN=kivinen" without the need to fill in the OU, O, C etc parts and search could then simply assume default values for those omitted parts. Or something like that. > When reading https://tools.ietf.org/html/rfc5280#section-7.1 we see: > > Two distinguished names DN1 and DN2 match if they > have the same number of RDNs, for each RDN in DN1 there is a matching > RDN in DN2, and the matching RDNs appear in the same order in both > DNs. > > > So technically, when we expect one, receiving the other order would be > wrong. So should we really do matching based on the same order of RDNs. > What do other implementations do? You MUST match them in order. If the order is wrong then the DNs do not match. Note, that there can be multiple OU fields in the same certificate and the order of those must be preserved, and also those are reversed depending on the string format used, so you cannot just take the attributes and sort them in some order, you must know which order is supposed to be used and use that. I.e., if you have C=FI, O=example Corp, OU=Development, OU=Support, CN=server and C=FI, O=example Corp, OU=Support, OU=Development, CN=server then they are two different sub devisions inside the same organization, and you must be able to limit developments version control server so that only support people of the development division can access it and the global support devision do not have any access to it.... Same goes with other things for example for DC attributes. And when you reverse those for least significant part first order, you do reverse the order of OU fields too. > Now, I guess I can weasel myself out of here, by claiming that we are > not comparing two certificates. We just get one via CERT payload and > validate it, and _then_ compare its DN against our IKE ID (which is a > DN, sorta kinda). So perhaps I can say the IKE ID can take RDN's in > any order. As we are dealing with (private) CA's, we can probably be > ensured it would not create two certs that only differ in RDN ordering. It is better to properly make the certificates so that the most significant part of the DN is first in sequence (i.e., C first inside ASN.1 sequence) and make sure you give then DN in the order that will result in that to the tool you are using. If you ever use any string representation for the DN you must clarify in your documentation which format you use, i.e., whether you use most significant part first, or least siginifanct part first. And when you encode and print them you always consistently do the encoding and printing in same order. And do matching using binary representation in the order they are in the DER sequence. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
