Why does Nginx Provide the Client SSL DN in reverse order?

Question

I'm curious why some web servers (eg. Nginx) provides the Client SSL DN in reverse order.

A web app is posting the DN to a Java Web Service, which is attempting to create a Java javax.naming.ldap.LdapName.

Standard Order (LDAP or X500Name):

"CN=Jimmy Blooptoop,OU=Someplace,OU=Employees,DC=Bloopsoft-Inc"

Reverse Order (OpenSSL Oneline Format) (What Nginx Returns as _$ssl_client_s_dn_):

"/DC=Bloopsoft-Inc/OU=Employees/OU=Someplace/CN=Jimmy Blooptoop"

Why is this?

Which one matches the LDAP RFC?

Do they both?

Notes on LDAP RFC:

There are many RFC's related to LDAP: https://www.ldap.com/ldap-specifications-defined-in-rfcs

Many people references different ones, here is an attempt at a quick history of them:

~~July 1993: RFC 1485 - A String Representation of Distinguished Names~~
~~March 1995: RFC 1779 - A String Representation of Distinguished Names~~
Dec 1997: RFC 2253 - Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
September 2002: RFC 3377 - Lightweight Directory Access Protocol (v3): Technical Specification (Updating RFC 2253)
~~March 2003: RFC 3494 - Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status (Retiring RFC 1485, RFC 1779)~~
June 2006: RFC 4514 - Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names

Most Recent One, which obsoleted others: RFC 4514: Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names

Java Library:

Is there a Java library to convert back and forth (from reverse to not revers)? LdapName throws an InvalidNameException. Seems like there should be, the backwards format appears frequently.

Java Libraries:

javax.naming.ldap.LdapName Supports RFC 2253
org.apache.directory.api.ldap.model.filter.FilterEncoder Supports RFC 4514
Spring LdapUtils Wraps LdapName
Article on using BouncyCastle X509Name to parse and compre DN's: http://www.sivachandran.in/2012/11/comparing-x509-distinguished-name-with.html

Ngninx Notes:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html

Linking:

Apache HTTPD does the same thing. It's not attempting to conform to any LDAP RFCs. This just another representation of the DN from the client certificate. — user207421, Nov 18 '15 at 20:42
Problem is that if you look at RFC 5280 that defines the X.509v3 certificates that there is a description that indicates how implementations should match DN's. Problem is that TLS on the other hand usually requires a binary compare where the values within the cert *are* ordered. — Maarten Bodewes, Jun 01 '22 at 08:43

user207421 · Answer 1 · 2015-12-09T23:13:00.670

Why is this?

It's because that's what's returned by OpenSSL. Apache HTTPD does the same thing, because it also uses OpenSSL.

Which one matches the LDAP RFC?

The one you describe as 'standard order'. However this is an SSL certificate and an SSL API. It doesn't have anything to do with LDAP and there is no reason why it should conform to any LDAP RFC. It's just another way of providing the DN of the certificate subject. This is defined by X.509, not by LDAP (although ultimately they are all defined by X.500, at least originally).

Is there a Java library to convert back and forth (from reverse to not reverse)

Off topic, and not that I'm aware of, but it's easy enough to write:

public class OpenSSLSubjectName
{
    private String  name;

    public OpenSSLSubjectName(String name)
    {
        this.name = name;
    }

    public String   getX500Name() throws NamingException
    {
        return getLdapName().toString();
    }

    public LdapName getLdapName() throws NamingException
    {
        List<Rdn>   rdns = new LinkedList<>();
        String[]    parts = name.split("/");
        for (int i = 1; i < parts.length; i++)
        {
            rdns.add(new Rdn(parts[i]));
        }
        return new LdapName(rdns);
    }
}

E&OE

Why does Nginx Provide the Client SSL DN in reverse order?

1 Answers1

Linked