hua*_*glx 6 ipv6 ssl-certificate
例如，是否有可能获得 IPv6 地址的 SSL 证书https://[1234:5678:9000:abcd:9876:5432:10ab:cdef]？如果是这样，是否有任何此类用法的示例？假设在这种情况下设置个人根 CA 并在设备上安装是一个合理的选择。
这个问题类似于：“公共 IP 地址的 SSL 证书？ ”，但并不完全相同，因为：
是的，subjectAltName扩展允许iPAddressOID，它可能包含一个 IPv6 地址作为网络字节顺序的 16 个八位字节。有关更多详细信息，请参阅RFC5280 s4.2.1.6。
从技术上讲，您可以在 X.509 证书的 SAN 部分拥有一个 IP 地址（v4 或 v6，没关系），但并非没有预防措施。
它们在 HTTPS 世界中很少见（因为它们击败了大量的 HTTPS 虚拟主机），但确实存在，这https://1.1.1.1/是一个著名的案例。使用证书透明度日志搜索，您可以找到更多在其主题备用名称扩展中具有 IP 地址的证书，这里是搜索一些的链接：https : //censys.io/certificates?q=parsed.extensions.subject_alt_name.ip_addresses% 3A*
（我也找不到专门搜索 IPv6 地址的方法；https ://crt.sh/ 也有一个关于 Identity/iPAddress 的搜索条件，但我根本无法使该条件起作用）。
较新的“ DNS over HTTP ”和“ DNS over TLS ”协议确实需要它们。
注意：
当 HTTP 请求需要解析 DNS URI 的主机名部分时，DoH 客户端可能面临类似的引导问题。正如
传统 DNS 名称服务器的地址最初无法
从同一服务器确定一样，DoH 客户端也无法使用其 DoH
服务器将服务器的主机名初始解析为地址。
客户端可能采用的替代策略包括 1) 将
初始解析作为配置的一部分，2)
HTTPS 的基于IP 的 URI 和相应的基于 IP 的证书，或 3)
通过传统 DNS 或其他 DoH 服务器解析DNS API 服务器的主机名，
同时仍然通过 HTTPS 对生成的连接进行身份验证。
但请注意，带有 IP 地址的证书在 DoT 和 DoH 成为主流之前就已经有效并存在，但在另一个鲜为人知的领域：RPKI。这涉及保护 BGP 交换：当有人宣布给定的 IP 地址块时，通过他从中获取 IP 地址块的 RIR，它可以获得包含其 IP 地址块和它的 IP 地址块的证书（因此由 RIR CA 签名）。 AS号码。这使其他人能够验证 IP 地址是否由正确的 AS 编号宣布。有关所有这些的入门信息，请参阅https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure。
这些证书在RFC 6487中标准化，它们看起来像这样：
Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer
Data:
Version: 3 (0x2)
Serial: 1500 (0x5dc)
Signature Algorithm: SHA256WithRSAEncryption
Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
Validity
Not Before: Oct 25 12:50:00 2008 GMT
Not After : Jan 31 00:00:00 2010 GMT
Subject: CN=A91872ED
Subject Public Key Info:
[...]
X509v3 extensions:
[...]
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
24021
38610
131072
131074
sbgp-ipAddrBlock: critical
IPv4:
203.133.248.0/22
203.147.108.0/23
请参阅 womble 在他的回答中所说的 RFC 5280。请特别注意您需要在主题备用名称中使用“IPAddress”字段而不是仅适用于名称的“DNSname”的默认/常见情况。
该 RFC 正确地满足 IPv4 和 IPv6 地址：
当subjectAltName 扩展包含一个iPAddress 时，地址必须以[RFC791] 中规定的“网络字节顺序”存储在八位字节串中。每个八位字节的最低有效位 (LSB) 是网络地址中相应字节的 LSB。对于 [RFC791] 中规定的 IP 版本 4，八位字节串必须正好包含四个八位字节。对于
[RFC2460] 中规定的 IP 版本 6，八位字节串必须正好包含 16 个八位字节。
如果您控制 CA，那么签署适当构建的 CSR 就不是问题。如果您希望它由知名 CA 签名，那么您需要找到一个接受这样做的人，虽然我没有列表，但我相信它们存在但不是大多数。
大多数 CA 以及浏览器认可的 CA 都应用 CAB 论坛要求指南。除了其他内容之外，它们还描述了 CA 需要根据要颁发的证书的内容进行哪种验证。
请参阅https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf
在您的具体情况下：
7.1.4.2.1 主题备用名称 ExtensionCertificate 字段：extensions:subjectAltNameRequired/Optional：RequiredContents：该扩展必须包含至少一个条目。每个条目必须是包含完全限定域名的 dNSName 或包含服务器 IP 地址的 iPAddress。CA 必须确认申请人控制完全限定域名或 IP 地址，或已被域名注册人或 IP 地址受让人授予使用权（视情况而定）。允许使用通配符 FQDN
第 3.2.2.5 节详细说明了如何验证 IP 地址，具有以下可能性（有关详细信息，请参阅文档）：
特别是对于最后两点，您还将在https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4 中看到更多详细信息，其中很好地引用了最近作为RFC：https : //tools.ietf.org/html/rfc8555
有一些观点通常并不为人所知，也不是由 CA 强制执行的。但总而言之，一旦基础属性不再有效，他们就应该撤销任何证书。例如，如果一个域不是由当前所有者续订并由另一个人注册，则应撤销现有证书。
IP 地址也会发生同样的情况：如果块所有者发生更改，则应撤销现有证书。
关于生产使用，cloudflare-dns.com 更常被称为 1.1.1.1。证书的 SAN 包括服务的 IPv4 和 IPv6 地址。
我怀疑这种证书的一个原因是通过 TLS 实现 DNS。同样响应 https，您可以在浏览器中看到证书：https://[2606:4700:4700::1111]
支持 subjectAltName 但不支持 v6 iPAddress 的实现是一个错误。
iPAddress 证书请求的例子很少，v6 的例子更少。感谢FreeIPA在他们最近添加 IP 地址证书时测试了 v6。可以使用 NSS 生成证书请求，如下所示：
certutil --extSAN dns:host.example.com,ip:2001:db8:3902:3468::443