为什么 Nginx 以相反的顺序提供客户端 SSL DN? [英] Why does Nginx Provide the Client SSL DN in reverse order?
问题描述
我很好奇为什么某些 Web 服务器(例如 Nginx)以相反的顺序提供客户端 SSL DN.
Web 应用程序将 DN 发布到 Java Web 服务，该服务试图创建 Java javax.naming.ldap.LdapName.
标准顺序(LDAP 或 X500Name):
"CN=Jimmy Blooptoop,OU=Someplace,OU=Employees,DC=Bloopsoft-Inc"逆序(OpenSSL 单行格式)(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):可分辨名称的字符串表示p>
Java 库:
是否有一个 Java 库可以来回转换(从反向到不反向)?LdapName 引发 InvalidNameException.好像应该有，倒退的格式经常出现.
Java 库:
- javax.naming.ldap.LdapName 支持 RFC 2253
- org.apache.directory.api.ldap.model.filter.FilterEncoder 支持 RFC 4514
- Spring LdapUtils 包装 LdapName
- 关于使用 BouncyCastle X509Name 解析和压缩 DN 的文章:http://www.sivachandran.in/2012/11/comparing-x509-distinguished-name-with.html
Ngninx 笔记:
链接:
- 如何在Java中从X509Certificate中提取CN?
- 从证书DN中解析CN (借用的 DN 示例)
- Nginx 信息
- X500Principal 专有名称顺序
- 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
这是为什么?
这是因为这是 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{列出<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 NamesMarch 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:
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屋！
