Почему Nginx предоставляет DN SSL клиента в обратном порядке?

Мне любопытно, почему некоторые веб-серверы (например, Nginx) предоставляют клиентское SSL DN в обратном порядке.

Веб-приложение отправляет DN в веб-службу Java, которая пытается создать Java javax.naming.ldap.LdapName.

Стандартный заказ (LDAP или X500Name):

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

Обратный порядок (формат OpenSSL Oneline) (что Nginx возвращает как _$ssl_client_s_dn_):

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

Почему это?

Какой из них соответствует LDAP RFC?

Они оба?

Примечания к LDAP RFC:

Существует множество RFC, связанных с LDAP: https://www.ldap.com/ldap-specifications-defined-in-rfcs

Многие люди ссылаются на разные, вот попытка их краткой истории:

  • Июль 1993 г.: RFC 1485 — строковое представление различающихся имен
  • Март 1995 г.: RFC 1779 — строковое представление отличительных имен
  • Декабрь 1997 г .: RFC 2253 - Облегченный протокол доступа к каталогам (v3): строковое представление отличительных имен UTF-8.
  • Сентябрь 2002 г .: RFC 3377 - Облегченный протокол доступа к каталогам (v3): техническая спецификация (обновление RFC 2253)
  • Март 2003 г.: RFC 3494 — Облегченный протокол доступа к каталогам версии 2 (LDAPv2) до исторического статуса (упразднение RFC 1485, RFC 1779)
  • Июнь 2006 г.: RFC 4514 – Облегченный протокол доступа к каталогам (LDAP): строковое представление отличительных имен

Самый последний, который устарел от других: RFC 4514: облегченный протокол доступа к каталогам (LDAP): строковое представление Выдающиеся имена

Библиотека Java:

Есть ли библиотека Java для преобразования туда и обратно (с обратного на необратное)? LdapName создает исключение InvalidNameException. Вроде должно быть, часто появляется обратный формат.

Библиотеки Java:

Примечания Ngninx:

Связывание:


java nginx openssl ldap spring-ldap
person technocrat    schedule 18.11.2015    source источник
comment
Apache HTTPD делает то же самое. Он не пытается соответствовать каким-либо RFC LDAP. Это просто еще одно представление DN из клиентского сертификата.   -  person user207421    schedule 18.11.2015
comment
Я думаю, что это однострочная версия openssl.   -  person technocrat    schedule 21.11.2015

Ответы (1)


arrow_upward
6
arrow_downward

Почему это?

Это потому, что это то, что возвращает OpenSSL. Apache HTTPD делает то же самое, потому что он также использует OpenSSL.

Какой из них соответствует LDAP RFC?

Тот, который вы описываете как «стандартный заказ». Однако это сертификат SSL и API SSL. Он не имеет ничего общего с LDAP, и нет причин, по которым он должен соответствовать какому-либо LDAP RFC. Это просто еще один способ указать DN субъекта сертификата. Это определяется X.509, а не LDAP (хотя в конечном итоге все они определены X.500, по крайней мере, изначально).

Есть ли библиотека Java для преобразования туда и обратно (от обратного к не обратному)

Не по теме, и не то чтобы я в курсе, но достаточно легко написать:

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);
    }
}

Э&ОЕ

person user207421    schedule 01.12.2015