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

时间:2019-06-12 00:45:59

标签: openssl ssl-certificate

我想知道是否有一种简便的方法可以在创建SSL证书并将其添加到主题字段时自动生成“全局”唯一ID? 参阅OpenSSL bash命令/示例将很有帮助。

与此类似:enter image description here

1 个答案:

答案 0 :(得分:1)

首先,“主题”字段和“主题替代名称”扩展名(缩写为SAN)虽然是设计为与同一个真实世界实体相关的,但它们是不同且独立的事物。您的标题和文字仅指第一个,而您的示例仅指第二个。

从技术上讲,主题字段非常灵活。(类似于Issuer)是X.501“专有名称”(DN;不要与域名混淆),它由(类型-值对的潜在集合,其中每种类型均由ASN.1对象标识符(缩写为OID)定义;有几种标准化的OID,例如'country','locality','organization'和'commonName'被广泛使用,但是格式允许任何OID,并且OID方案是可扩展的-任何人都可以分配“ arc”并创建几乎无限数量的新OID,但有一个重要的限制,只有您编写的程序和运行的系统才能知道您创建的新OID,除非并且直到其他人或组织采用它们为止。所有标准DN OID的值都必须为字符串,尽管ASN.1支持的几个字符串中的哪个确切取决于您阅读并遵循的标准。具体请参见DirectoryString的类型定义;其他OID不需要遵循这种做法,但是可能应该简化实现和使用。 SAN不太通用; 它支持多种类型的值选择,其中两种使用类似于主题和颁发者的可扩展OID +值方案,但另一种(且更常见) SAN的选择更加具体且受限制。 技术要求最初是由X.509v3定义的,但要在Internet上使用 (不是唯一使用证书的场所),并且一定程度上要在与Internet兼容的网络(即Intranet)或系统上使用,控制定义现在主要是RFC 5280(加上一些其他RFC中的相关位)。对于HTTPS,RFC2818指定如果存在SAN,则客户端(浏览器)必须使用它并忽略Subject;其他一些协议具有相似(但不总是相同)的规则,RFC6125建议将其用于任何新协议。

但是,公开密钥证书的目的是向可识别主体(并具有各种条件和约束)传递对密钥的信任;这就要求实际的证书能为使用证书的实体足够准确地识别主题,这些实体通常称为依赖方;例如,对于HTTPS网站,依赖方是代表访问网站的人的浏览器。 对于公共Web(HTTPS和WSS),实际上,对于公共网络上的大多数其他SSL / TLS协议,这些标准由the CA/Browser Forum设置。参见基线要求的7.1.4,以及3.2.2中特别是3.2.2.4和3.2.2.5中引用的部分;他们通常要求主题和SAN除包含DNS名称以及可能被确认为属于申请人的IP地址(见下)之外,还必须包含人类可理解且无误导性的内容。标识符,例如公司名称。 (但请参阅下文。)未公开使用/信任的CA(例如,企业,代理机构,协会或工作组中的私人CA)不一定必须遵循这些规则,尽管违反它们可能会导致在计算机上设计的软件出现问题。期望或假设。

DNS名称在全球范围内是唯一的。更确切地说,是在适用的“权威” DNS服务器中配置的完全合格域名(FQDN)。唯一允许您从CABforum CA获得证书的种类,在整个公共Internet上都是唯一的。实际上,这是自里根时代创建以来DNS的目的和主要设计目标之一。尽管它们 可以自动生成,但通常由人们选择并使用助记符(对于某些助记符而言)。例如,恶意软件作者和僵尸网络运营商经常使用自动生成且快速更改的域名作为其“命令和控制”系统,以防止执法人员发现并关闭它们。一些(合法的)人还使用长随机或至少类似于随机的子域名来尝试保持其站点或部分站点“隐藏”,但这是否有效尚有争议;我已经看到许多问号(IIRC security.SX以及webmasters.SX)的影响,“我使用了这个随机域名,我相信没人能猜到,但它仍然在搜索中受到攻击/被拒绝/被发现?! '

IP地址也是全局唯一的,至少是“真实的”可分配地址(不是多播,任播,专用,本地链接,环回等)。 (同样,您只能针对可分配的地址(如果有的话)获得CABforum证书。)IPv4地址的分配主要基于您所连接的ISP,这是自动的。 IPv6地址部分基于ISP,其余通常是自动的(伪随机或任意的,例如接口的MAC地址)。除经验丰富的网络工程师外,它们大多是非助记符的。但是,它们通常不是长期稳定的,对于移动/蜂窝/无线或某些云甚至不是短期稳定的。

您还没有解释为什么您认为“自动生成的” ID有什么好处。是否某些人或所有人能够找出特定人员,实体或站点的ID?他们将如何做到这一点,以及您如何确保信息不会被篡改或篡改,并且不会过时?有些人或所有人能够验证给定的ID是他们希望与之通信的某个人,实体或站点吗?这比我们现在拥有的ID好吗?

一种模糊地类似于您的问题的方法是,CABforum允许向TOR“隐藏服务”地址(也称为'.onion' addresses)颁发EV =扩展验证证书(成本更高);请参阅《 EV准则附录F》。(维基百科错误地将选票144描述为将其添加到基准中,但是基准变更仅针对 revoke .onion证书;对 issue 的变更是由于TOR服务处于活动状态(程序可以与之通信),并且永久绑定到公钥,因此CA可以验证您“拥有”它,并且可以使用特殊TLD来验证。 “洋葱”保留,CA可以创建一个DNS格式的名称以放入CommonName和/或SAN.dnsName,即使它不是严格说来是真实的DNS名称(您也不能在权威服务器中查找它) 。该地址是自动生成的,完全不是助记符,并且在统计上是唯一的(因为v3对已经相当随机的数据使用了良好的加密哈希)。

就使用OpenSSL命令行而言,这不是编程问题,应该离题; 很多 Q大多在其他堆栈中,涉及使用OpenSSL生成CSR(证书签名请求)和证书,包括自签名(即根或伪根)证书,以及您自己签署的证书CA(由您签名,但不是自签名的)。从
开始 How can I generate a self-signed certificate with SubjectAltName using OpenSSL?
How do you sign a Certificate Signing Request with your Certification Authority?
Add SAN with private CA
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信息,他们将拒绝或忽略它,而仅将其(理解和)验证的内容放入证书中。