Hi Paul, > 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.
That's because, according to the documentation and examples, NSS certutil follows RFC 1485 when it comes to string representations of DNs, which states: The name is presented/input in a little-endian order (most significant component last). The latest RFC that replaced it, RFC 4514, states it this way, which is a bit clearer: Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence ..., starting with the last element of the sequence and moving backwards toward the first. Why the last RDN first? Could be to see the CN immediately, which usually identifies the actual entity. What you see in OpenSSL is the physical representation in the ASN.1 encoding of the certificate, i.e. the RDNs in their actual order in the RDNSequence. We follow the same principle in strongSwan when logging and parsing 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? In strongSwan we have an option (charon.rdn_matching) that allows changing how DNs in certificates are matched against configured IKE identities. It defaults to 'strict', which results in what RFC 5280 describes, i.e. all RDNs have to match in the same order (wildcards to ignore the values of RDNs are always allowed). With 'reordered', all RDNs have to be there, but their order doesn't matter. Finally, with 'relaxed', the certificate's DN may additionally contain RNDs that are not configured, which are then treated like wildcards. For example, with 'relaxed' you could configure CN=server which would be the same as configuring C=*, ST=*, L=*, O=*, OU=*, CN=server which matched both certificates with 'relaxed' and 'reordered' but only one with 'strict'. Using 'reordered' and 'relaxed' causes some overhead (memory and runtime) so 'strict' continues to be the default. Regards, Tobias _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
