☰

使用 IP 地址的证书

tag-icon • tag-icon ssl-certificate ipv6
使用 IP 地址的证书

例如，是否有可能获得 IPv6 地址的 SSL 证书https://[1234:5678:9000:abcd:9876:5432:10ab:cdef]？如果可以，是否有此类用法的示例？假设在这种情况下设置个人根 CA 并安装在设备上是一个可行的选择。

这个问题类似于：“公共 IP 地址的 SSL 证书？“，但并不完全相同，因为：

  • 我询问的是 IPv6 SSL 证书
  • 我只是想问是否可以制作这些证书，而不是如何实现（尽管如果能解释一下如何实现的话会更好）

答案1

从技术上讲，您可以在 X.509 证书的 SAN 部分拥有一个 IP 地址（v4 或 v6，无所谓），但这并非没有预防措施。

使用 IP 地址的证书

它们在 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 的搜索条件，但我根本无法使其发挥作用）。

它们确实是较新的“HTTP 上的 DNS“ 和 ”基于 TLS 的 DNS“协议。

注意：

  • 对于 DoT 来说，证书并不像底层公钥那么重要，因为客户端应该事先将其固定住
  • 对于 DOH，有关于证书的讨论：

当 HTTP 请求需要解析 DNS URI 的主机名部分时，DoH 客户端可能会面临类似的引导问题。正如
传统 DNS 名称服务器的地址最初无法
从同一服务器确定一样，DoH 客户端无法使用其 DoH
服务器将服务器的主机名最初解析为地址。
客户端可能采用的替代策略包括 1) 将
初始解析作为配置的一部分，2) 基于 IP 的 URI 和
相应的基于 IP 的 HTTPS 证书，或 3)
通过传统 DNS 或另一个 DoH 服务器解析 DNS API 服务器的主机名
，同时仍通过 HTTPS 对生成的连接进行身份验证。

但请注意，带有 IP 地址的证书早在 DoT 和 DoH 成为主流之前就已经存在，但在另一个鲜为人知的领域：RPKI。这涉及保护 BGP 交换：当某人通过其获得 IP 地址块的 RIR 宣布给定的 IP 地址块时，它可以获得一个证书（因此由 RIR CA 签名），其中包含其 IP 地址块和 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

生成证书/CSR

请参阅 RFC 5280，正如 womble 在他的回答中所说。请特别注意，您需要在主题备用名称中使用“IPAddress”字段，而不是通常默认/常见的仅适用于名称的“DNSname”。

该 RFC 正确地满足了 IPv4 和 IPv6 地址的要求：

当 subjectAltName 扩展包含 iPAddress 时，该地址必须按照 [RFC791] 中规定的“网络字节顺序”存储在八位字节字符串中。每个八位字节的最低有效位 (LSB) 是网络地址中相应字节的 LSB。对于 IP 版本 4，如 [RFC791] 中所述，八位字节字符串必须恰好包含四个八位字节。对于 IP 版本 6，如
[RFC2460] 中所述，八位字节字符串必须恰好包含十六个八位字节。

如果您控制 CA，那么签署适当构建的 CSR 就不成问题。如果您希望由知名 CA 签署，则需要找到一家愿意这样做的 CA，虽然我没有列表，但我相信它们存在，但不是大多数。

由“信誉良好”的 CA 进行验证

大多数 CA 以及浏览器认可的 CA 都遵循 CAB 论坛要求指南。除其他事项外，它们还描述了 CA 需要根据要颁发的证书的内容进行哪种验证。

看https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf

在您的具体情况下：

7.1.4.2.1 主题备用名称扩展证书字段：extensions:subjectAltName必需/可选：必需内容：此扩展必须包含至少一个条目。每个条目必须是包含完全合格域名的 dNSName 或包含服务器 IP 地址的 iPAddress。CA 必须确认申请人控制完全合格域名或 IP 地址，或已被域名注册人或 IP 地址受让人授予使用权（视情况而定）。允许使用通配符 FQDN

第 3.2.2.5 节详细说明了如何验证 IP 地址，有以下几种可能性（详情请参阅文档）：

  • 3.2.2.5.1. 商定的网站变更
  • 3.2.2.5.2. 通过电子邮件、传真、短信或邮寄方式联系 IP 地址
  • 3.2.2.5.3. 反向地址查找
  • 3.2.2.5.4. 任何其他方法（由于“2019 年 7 月 31 日之后 CA 不得使用此方法进行验证”，因此该方法现已无效）。
  • 3.2.2.5.5. 电话联系与 IP 地址联系
  • 3.2.2.5.6 ACME“http-01” IP 地址方法
  • 3.2.2.5.7 ACME “tls-alpn-01” IP 地址方法

特别是最后两点，您还可以在https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-04#section-4其中详细引用了最近以 RFC 形式发布的 ACME 协议：https://www.rfc-editor.org/rfc/rfc8555

CAB 论坛指南的小暗角

有些要点通常不为人所知，CA 也不会特别严格执行。但总而言之，一旦底层属性不再有效，他们就应该撤销任何证书。例如，如果域名未由当前所有者续订并由另一个所有者注册，则应撤销现有证书。

IP 地址也是如此：如果块所有者发生变化，则应撤销现有证书。

答案2

是的，subjectAltName扩展允许使用iPAddressOID，它可以包含按网络字节顺序排列的 16 个八位字节的 IPv6 地址。请参阅RFC5280 s4.2.1.6更多细节。

答案3

对于生产用途，cloudflare-dns.com 更常见的名称是 1.1.1.1。证书的 SAN 包括该服务的 IPv4 和 IPv6 地址。

我怀疑这种证书的原因是为了实现 DNS over TLS。此外，它还响应 https，您可以在浏览器中看到该证书：https://[2606：4700：4700::1111]

支持 subjectAltName 但不支持 v6 iPAddress 的实现是一个错误。

目前 iPAddress 证书请求的示例很少，而 v6 的则更少。感谢用于测试 v6 的 FreeIPA当他们最近添加了 IP 地址证书时。可以使用 NSS 生成证书请求，如下所示：

certutil --extSAN dns:host.example.com,ip:2001:db8:3902:3468::443

答案4

是的，可以为 IPv6 地址获取 SSL 证书。证书可以是自签名证书，也可以来自受信任的 CA（例如 DigiCert）。

请参阅下文 IPv6 具有 SSL 证书。（它由 1.1.1.1 服务提供）

https://[2606：4700：4700::1111]

相关内容