[keycloak-dev] Certificate subject DN is provider dependent
jdennis at redhat.com
Tue Feb 12 14:27:36 EST 2019
On 2/12/19 1:05 PM, Pedro Igor Silva wrote:
> I think these threads are not talking about the same thing. The issue here
> is the email address within the subject dn, which is deprecated in favor of
> a specific subject alternative name extension in the certificate.
Actually I think the two issues are pretty much the same and presence of
an email address is a red herring . In both cases one is trying to
compare a DN for equality.
What is a bit troubling is the order of the RDN's as returned by the two
providers. Notice they are reversed. This is a common problem with
different X509 implementations. The RFC's are clear, the order of RDN's
in a string representation are supposed to be added by starting with the
LAST RDN in the binary format (ASN.1) and proceeds towards the first.
However this is often the opposite of how humans want to read these
strings and some implementations reverse the order (a classic example is
OpenSSL vs. NSS).
The other thing to note is one provider is using an alias for the email
address and the other isn't.
What is not clear to me from the email is how the string representations
from the two providers was obtained, clearly they are using different
algorithms. BUT the certificate subject is in binary form in the
certificate and the same X509 implementation SHOULD produce identical
string representations from the same binary data. Therefore be careful
and draw a sharp distinction between asking one implementation to
convert binary data to string format and the actual binary data.
FWIW the Java implementations refer to RFC 2253 but that has been
superseded by RFC 4514.
 Yes, email addresses are better specified in a SAN but for legacy
reasons it's perfectly fine to include them in the subject, things
should still work.
More information about the keycloak-dev