首先,主题字段和主题替代名称扩展(缩写为 SAN)是不同且独立的事物,尽管它们都被设计为与相同的现实世界实体相关;您的标题和文字仅指第一个,您的示例仅指第二个。
从技术上讲,主题字段非常灵活。它(与发行者一样)是一个 X.501“专有名称”(DN;不要与域名混淆),由一系列(可能是一组)类型值对组成,其中每种类型由 ASN.1 对象定义标识符(缩写为OID);有几种标准化的 OID,如“国家”、“地点”、“组织”和“commonName”,它们的使用非常广泛,但格式允许任何 OID,并且 OID 方案是可扩展的——任何人都可以获得分配的“弧”并创建几乎无限数量的新 OID,但有一个重要的限制:只有您编写的程序和您操作的系统才会知道您创建的新 OID,除非您让其他人或组织采用它们。所有标准 DN OID 都要求其值是字符串,尽管 ASN.1 支持的几个字符串中的哪一个具体取决于您阅读并尝试遵循的标准;具体参见DirectoryString的类型定义;其他 OID 不需要遵循这种做法,但可能应该使实施和使用更容易。SAN 不太通用;它支持多种值类型选择,其中两种使用类似于主题和发行者的可扩展 OID+值方案,但 SAN 的其他(也是更常见)选择更加具体和受限制。
该技术要求最初由 X.509v3 定义,但用于使用在互联网上(这不是唯一使用证书的地方)并且在某种程度上在互联网兼容的网络(即内部网)或系统上,控制定义现在主要是RFC 5280 https://www.rfc-editor.org/rfc/rfc5280#section-4(加上其他一些 RFC 中的相关位)。对于 HTTPSRFC2818 https://www.rfc-editor.org/rfc/rfc2818指定如果 SAN 存在,客户端(浏览器)必须使用它并忽略主题;其他一些协议也有类似的(但并不总是相同的)规则RFC6125 https://www.rfc-editor.org/rfc/rfc6125推荐将其用于任何新协议。
然而,公钥证书的目的是向可识别主体的密钥传达信任(并具有各种条件和约束);这要求实际证书能够足够准确地为使用该证书的实体(通常称为依赖方)识别主体;例如,对于 HTTPS 网站,依赖方是代表访问网站的人的浏览器。对于公共网络(HTTPS 和 WSS),并且在实践中,对于公共网络上的大多数其他 SSL/TLS 协议,这些标准是由CA/浏览器论坛 https://cabforum.org。参见基准要求的 7.1.4 以及 3.2.2 中引用的章节,尤其是 3.2.2.4 和 3.2.2.5;除了 DNS 名称和可能的 IP 地址之外,它们通常还要求主题和 SAN 包含确认属于申请人(见下文),只有人类可理解且非误导性的标识符,例如公司名称。 (但见下文。)未公开使用/信任的 CA,例如企业、机构、社会或工作组内的私有 CA,不一定必须遵守这些规则,尽管违反这些规则可能会导致在该规则上设计的软件出现问题。他们被遵循的期望或假设。
DNS 名称是全球唯一的。更准确地说,完全合格在适用的“权威”DNS 服务器中配置的域名 (FQDN) 是您可以从 CABforum CA 获取证书的唯一类型,并且在整个公共互联网上是唯一的。事实上,这是 DNS 自里根时代创建以来的目的和主要设计目标之一。然而,它们通常是由人们选择的,并且是助记符(对于助记符的某些价值),尽管它们can自动生成;例如,恶意软件作者和僵尸网络运营商经常使用自动生成且快速变化的域名作为其“命令和控制”系统,以试图阻止执法部门发现它们并关闭它们。一些(合法的)人还使用长随机或至少类似随机的子域名来尝试“隐藏”他们的网站或部分网站,但这种做法的效果如何是值得商榷的;我见过许多 Q(IIRC security.SX,也许还有 webmasters.SX),大意是“我使用了这个随机域名,我相信没有人能猜到,但它仍然受到攻击/DoSed/在搜索中发现?!” '
IP 地址也是全球唯一的,至少是“真正的”可分配地址(不是多播、任播、专用、链路本地、环回等)。 (同样,您只能获得可分配地址(如果有)的 CABforum 证书。) IPv4 地址主要根据您连接到的 ISP 进行分配,这是自动分配的; IPv6 地址部分基于 ISP,其余部分通常是自动的(伪随机或任意,例如接口的 MAC 地址)。除了经验丰富的网络工程师之外,它们大多是难以记忆的。然而,它们通常不是长期稳定的,对于移动/蜂窝/无线或某些云来说甚至不是短期稳定的。
您还没有解释为什么您认为“自动生成”的 id 会有任何好处。部分或所有人是否能够找出特定个人、实体或网站的 ID 应该是什么?他们将如何做到这一点,您将如何确保信息不会被伪造或篡改,并且不会过时?部分或所有人是否能够验证给定的 IDis他们希望与之沟通的某个人、实体或网站?这比我们现在的 id 好在哪里?
一种与您的问题有点相似的方法是,CABforum 允许向 TOR“隐藏服务”地址(又名)颁发 EV = 扩展验证证书(成本更高)“.onion”地址 https://en.wikipedia.org/wiki/.onion;请参阅 EV 指南附录 F。(维基百科错误地将选票 144 描述为将其添加到基线中,但基线更改只是为了revoke.洋葱证书;的变化issue它们在 EV 中。)因为 TOR 服务处于活动状态(程序可以与其通信)and永久绑定到公钥,CA 可以验证您“拥有”它,并且由于保留了特殊的 TLD“.onion”,CA 可以创建一个 DNS 格式的名称来放入 CommonName 和/或 SAN.dnsName,甚至尽管严格来说它不是真正的 DNS 名称(您无法在权威服务器中查找它)。该地址是自动生成的,根本不具有助记符,并且在统计上是唯一的(因为 v3 对已经相当随机的数据使用了良好的加密哈希)。
至于使用 OpenSSL 命令行,这不是一个编程问题,应该是题外话;有manyQs 主要在其他堆栈中,涵盖使用 OpenSSL 生成 CSR(证书签名请求)和证书,包括自签名(即根或伪根)证书以及您使用自己的 CA 签名的证书(由您签名,但不是自签名)。从...开始
如何使用 OpenSSL 生成带有SubjectAltName 的自签名证书? https://stackoverflow.com/questions/21488845/how-can-i-generate-a-self-signed-certificate-with-subjectaltname-using-openssl
如何与您的证书颁发机构签署证书签名请求? https://stackoverflow.com/questions/21297139/how-do-you-sign-openssl-certificate-signing-requests-with-your-
添加具有私有 CA 的 SAN https://stackoverflow.com/questions/43527040/openssl-san-with-custom-ca-selfsign
https://security.stackexchange.com/questions/44251/openssl-generate- different-type-of-self-signed-certificate 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/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/74345/provide-subjectaltname-to-openssl-directly-on-command-line
https://security.stackexchange.com/questions/190905/subject-alternative-name-in-certificate-signing-request- https://security.stackexchange.com/questions/190905/subject-alternative-name-in-certificate-signing-request-
https://serverfault.com/questions/845766/generate-a-self-signed-cert-with-openssl-that-works-in-chrome-58 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 https://serverfault.com/questions/845806/how-to-generate-ssl-certificate-having-ca-keys
但是您自己签署的任何证书(包括自签名)可能不会被其他任何人信任。如果您向 CA(至少是公共 CA)提交 CSR,并要求提供任意主题和/或 SAN 信息,他们将拒绝或忽略它,并且仅将他们(理解和)验证的内容放入证书中。