[keycloak-dev] Certificate subject DN is provider dependent
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
More information about the keycloak-dev