Nginx为什么以相反的顺序提供客户端SSL DN? [英] Why does Nginx Provide the Client SSL DN in reverse order?

问题描述

我很好奇为什么某些Web服务器(例如Nginx)以相反的顺序提供客户端SSL DN.

一个Web应用正在将DN发布到Java Web Service，该Java Web Service试图创建Java

反向订单(OpenSSL Oneline格式)(Nginx返回为_ $ ssl_client_s_dn_的内容):

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

这是为什么?

哪个与LDAP RFC匹配?

它们都是吗?

关于LDAP RFC的注释:

有许多与LDAP相关的RFC: https://www.ldap.com/ldap-specifications-defined-in-rfcs

许多人引用了不同的人，这是他们的简要历史尝试:

• 1993年7月:RFC 1485-专有名称的字符串表示形式
• 1995年3月:RFC 1779-专有名称的字符串表示形式
• 1997年12月:RFC 2253-轻型目录访问协议(v3):专有名称的UTF-8字符串表示形式
• 2002年9月:RFC 3377-轻型目录访问协议(v3):技术规范(更新RFC 2253)
• 2003年3月:RFC 3494-轻型目录访问协议版本2(LDAPv2)转换为历史状态(退出RFC 1485，RFC 1779)
• 2006年6月:RFC 4514 -轻型目录访问协议(LDAP):专有名称的字符串表示

最近的一个，使其他人过时了: RFC 4514:轻型目录访问协议(LDAP):专有名称的字符串表示

Java库:

是否有Java库可以来回转换(从反向转换为不反向转换)?LdapName引发InvalidNameException.似乎应该有，向后格式经常出现.

Java库:

• javax.naming.ldap.LdapName支持RFC 2253
• Spring LdapUtils 包装LdapName
• 有关使用BouncyCastle X509Name解析和压缩DN的文章: http://nginx.org/en/docs/http/ngx_http_ssl_module.html

链接:

• 如何从Java的X509Certificate中提取CN?
• 从证书 DN 中解析出 CN (借来的DN示例，来自)
• Nginx信息
• X500Principal 专有名称顺序
• https://wiki.nikhef.nl/grid/How_to_handle_OpenSSL_and_not_get_hurt_background_liformation
• https://www.openssl.org/docs/manmaster/apps/x509.html#item_oneline

解决方案

这是为什么?

因为这是OpenSSL返回的.Apache HTTPD做同样的事情，因为它也使用OpenSSL.

哪个与LDAP RFC匹配?

您描述为标准订单"的订单.但是，这是一个SSL证书和一个SSL API.它与LDAP没有任何关系，也没有理由要遵循任何LDAP RFC.这只是提供证书主题DN的另一种方法.这是由X.509而不是LDAP定义的(尽管最终它们都是由X.500定义的，至少是最初定义的).

是否有一个Java库来回转换(从反向转换为非反向转换)

不是主题，不是我所知道的，但是编写起来很容易:

 公共类OpenSSLSubjectName{私有字符串名称；公共OpenSSLSubjectName(字符串名称){this.name =名称；}公共字符串getX500Name()引发NamingException{返回getLdapName().toString();}公共LdapName getLdapName()引发NamingException{List< Rdn>rdns = new LinkedList<>();String []部分= name.split("/");for (int i = 1; i  

E& OE

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

解决方案

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

这篇关于Nginx为什么以相反的顺序提供客户端SSL DN?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！