在SSL证书主题字段中添加ID

Question

我想知道在创建SSL证书并将其添加到subject字段时，是否有一种简单的方法可以自动生成“全局”唯一Id？查看opensslbash命令/示例将很有帮助。

Answer 1

首先，Subject字段和Subject Alt[ernative]Name extension（缩写为SAN）是不同的、独立的东西，尽管它们都被设计为与同一个真实世界实体相关；您的标题和文本仅指第一个，您的示例仅指第二个。

从技术上讲，主题领域非常灵活。它（与发卡机构一样）是一个X.501“可分辨名称”（DN；不要与域名混淆），由一系列（可能是一组）类型-值对组成，其中每个类型由ASN定义。1个对象标识符（缩写为OID）；有几种标准化的OID，如“国家”、“地区”、“组织”和“公共名称”，使用非常广泛，但格式允许任何OID，并且OID方案是可扩展的——任何人都可以分配“arc”，并创建几乎无限数量的新OID，有一个重要的限制，只有你编写的程序和你操作的系统才会知道你创建的新OID，除非你让其他人或组织采用它们。所有标准DN OID都要求它们的值为字符串，尽管确切地说是ASN中的哪个字符串。1支持根据您阅读和尝试遵循的标准而有所不同；具体参见DirectoryString的类型定义；其他OID不需要遵循此实践，但可能应该这样做，以使实现和使用更容易。SAN有点不一般；它为其值支持多种类型的选择，其中两种使用类似于Subject和Issuer的可扩展OID值方案，但SAN的其他（和更常见的）选择更为具体和受限。技术要求最初由X.509v3定义，但对于在互联网上使用（这不是使用证书的唯一场所）以及在某种程度上在互联网兼容网络（即内部网）或系统上使用，控制定义现在主要是RFC 5280（加上一些其他RFC中的相关位）。对于HTTPS，RFC2818指定如果存在SAN，客户端（浏览器）必须使用它并忽略主题；其他一些协议具有类似（但并不总是相同）的规则，RFC6125建议将其用于任何新协议。

然而，公钥证书的目的是为可识别的主体（以及各种条件和约束）向密钥传递信任；这就要求实际证书对使用证书的实体（通常称为依赖方）足够准确地识别主体；例如，对于HTTPS网站，依赖方是代表访问网站的人的浏览器。对于公共网络（HTTPS和WSS），以及公共网络上的大多数其他SSL/TLS协议，这些标准由CA/浏览器论坛制定。见7.1。4的基线要求，以及3.2中的参考章节。2特别是3.2。2.4和3.2。2.5; 它们通常要求主题和SAN除了包含验证为属于申请人的DNS名称和可能的IP地址（见下一步）外，还必须包含人类可以理解且不误导的标识符，如公司名称。（但请参见下文。）非公开使用/信任的CA（如企业、机构、社会或工作组中的私有CA）不一定必须遵守这些规则，尽管违反这些规则可能会导致基于预期或假设遵循这些规则而设计的软件出现问题。

DNS名称是全局唯一的。更准确地说，在适用的“权威”DNS服务器中配置的完全限定域名（FQDN）是唯一允许您从CABforum CA获取证书的类型，在整个公共互联网上被构造为唯一的。事实上，这是DNS的目的和主要设计目标之一，因为它创建于里根时代。然而，它们通常是由人们选择的，并且是助记符（对于助记符的某些价值而言），尽管它们可以自动生成；例如，恶意软件作者和僵尸网络运营商经常为他们的“指挥和控制”系统使用自动生成和快速变化的域名，试图阻止执法部门发现并关闭它们。一些（合法的）人也使用长随机或至少随机的子域名来试图保持他们的网站或其部分“隐藏”，但这是否有效还存在争议；我见过很多Qs（IIRC security.SX，可能还有webmasters.SX），大意是“我使用了这个随机域名，我相信没有人能猜到，但它仍然在搜索中被攻击/使用/发现？！”

IP地址也是全局唯一的，至少是“真实”的可分配地址（不是多播、选播、私人使用、本地链接、环回和类似的地址）。（同样，您只能获得可分配地址的CABforum证书（如果有）IPv4地址主要根据您连接到的ISP分配，这是一种自动分配；IPv6地址部分基于ISP，其余地址通常是自动的（伪随机或任意，如您接口的MAC地址）。除了有经验的网络工程师之外，它们大多是非助记符的。然而，它们通常不是长期稳定的，对于移动/蜂窝/无线或某些云甚至不是短期稳定的。

您还没有解释为什么您认为“自动生成”id会有任何好处。某些人或所有人是否能够找出特定个人、实体或站点的id？他们将如何做到这一点，您将如何确保信息不会被伪造或篡改，并且不会过时？一些人或所有人是否能够验证给定的id是他们希望（ed）与之通信的某个人、实体或站点？这比我们现在的身份证好多少？

一种有点像你的问题的方法是，CABforum允许向TOR“隐藏服务”地址（又名“隐藏服务”）颁发EV=扩展验证证书（成本更高）。洋葱的地址；参见EV指南附录F。（维基百科错误地描述为将此添加到基线中，但基线更改仅用于撤销。洋葱证书；发布证书的更改在EV中。）因为TOR服务是活动的（程序可以与其通信）并且永久绑定到公钥，CA可以验证您是否“拥有”它，并且因为一个特殊的TLD”。如果保留“onion”，CA可以创建DNShtml" target="_blank">格式名称以放入CommonName和/或SAN中。dnsName，即使严格来说它不是一个真正的DNS名称（您不能在权威服务器中查找它）。这个地址是自动生成的，完全不是助记符，并且在统计上是唯一的（因为v3对已经相当随机的数据使用了一个很好的加密哈希）。

至于使用OpenSSL命令行，这不是一个编程问题，应该是离题的；有许多Q，主要在其他堆栈中，包括使用OpenSSL生成CSR（证书签名请求）和证书，包括自签名（即根或伪根）证书，以及您使用自己的CA签名的证书（由您签名，但不是自签名）。从
开始，如何使用OpenSSL生成具有SubjectAltName的自签名证书
如何与您的证书颁发机构签署证书签名请求
使用专用CA添加SAN
https://security.stackexchange.com/questions/44251/openssl-generate-different-type-of-self-signed-certificate
https://security.stackexchange.com/questions/150078/missing-x509-extensions-with-an-openssl-generated-certificate
https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line
https://security.stackexchange.com/questions/190905/subject-alternative-name-in-certificate-signing-request-
https://serverfault.com/questions/845766/generating-a-self-signed-cert-with-openssl-that-works-in-chrome-58
https://serverfault.com/questions/845806/how-to-generate-ssl-certificate-having-ca-keys

但是你自己签署的任何证书（包括自己签署的）可能不会被任何人信任。如果您向CA（至少是公共CA）提交CSR，并要求提供任意主题和/或SAN信息，他们将拒绝或忽略该信息，并且只在证书中放入他们（理解和）验证的内容。