[keycloak-dev] Certificate subject DN is provider dependent

[Pedro Igor Silva]

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).

On Tue, Feb 12, 2019 at 5:27 PM John Dennis <jdennis at redhat.com> wrote:

> 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
>