[keycloak-dev] Certificate subject DN is provider dependent

John Dennis jdennis at redhat.com
Tue Feb 12 15:43:15 EST 2019

On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
> Pretty much, but not the same. The fix for this still does not seem to 
> solve the problem being discussed in the other thread.
> The change provided by Sebastian does solve this problem while still 
> backwards compatible with certificates with subject dn containing an 
> emailAddress. My point though is whether or not we should be backward 
> compatible given that emailAddress is a deprecated RDN in the subject DN.
> As you mentioned, RFC-2253 was superseded by RFC-4514 and there you 
> can't have emailAddress in subject DN but prefer a SAN. So, my question 
> is ... Is OK in 2019 to assume that certificates are using RFC-4514 ? So 
> we could just use the canonical format in our side and avoid any 
> additional configuration.
> You are right, java defaults to RFC-2253, I'm not sure if the 
> "canonical" format is related with the support for 4514 (at least 
> removing emailAddress from subject DN).

No, RFC's 2253 and 4514 *only* describe the process by which a binary DN 
in ASN.1 format is converted to a string representation. These RFC's do 
not define the permissible members of a DN in an X509 certificate. In 
fact the subject member of an X509 certificate was originally *under* 
specified leading to all sorts of compatibility problems. The usual 
solution adopted only by convention and not by specification is to 
extract the CommonName (i.e. CN) RDN value and use that as the subject 
name (usually in the scope of the issuer). But as you can imagine that 
also has it's own problems (e.g. name collisions that would otherwise be 
uniquely determined by the other RDN values and/or scoping to the issuer).

I go back to my original assertion when I first replied weeks ago. If 
you want to compare DN's for equality you're going to have to do so by 
breaking the DN down into it's component parts and comparing them 
individually or reformat the string representation of the DN into a 
canonical form and perform a string comparison (note that forming a 
canonical string representation also requires breaking the components 
apart so there is little actual difference between doing an equality 
test between DN objects and an equality comparison on the resulting 
canonical strings, the later just adds the cycles needed to format the 
individual components).

John Dennis

More information about the keycloak-dev mailing list