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:

• How to extract CN from X509Certificate in Java?
• Parsing the CN out of a certificate DN (Borrowed DN example from)
• Nginx Info
• X500Principal Distinguished Name order
• https://wiki.nikhef.nl/grid/How_to_handle_OpenSSL_and_not_get_hurt_background_information
• https://www.openssl.org/docs/manmaster/apps/x509.html#item_oneline

Answer 1

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