[keycloak-dev] Certificate subject DN is provider dependent

[John Dennis]

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 [1]. 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.

[1] 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.
-- 
John Dennis