我们即将从Let’s Encrypt的生产环境中开始签发包含IP地址SAN的证书。这些证书仅在shortlived配置文件下可用（有效期为6天），且该配置文件在一段时间内将仅限于白名单模式。
请注意：在正式向公众推出此功能前，我们还有更多工作需要完成。目前尚无具体时间表，且尚未准备好接受白名单申请。
以下是一个示例测试证书，以及使用该证书的网站：
- abadcafe.txt (3.0 KB)
https://[2602:ff3a:1:abad:c0f:fee:abad:cafe]/
如果您发现任何有趣、奇怪或错误的内容，请随时提出！
我认为我已经在 Firefox 显示 IP 地址 SAN 时发现了一个 bug；BZ #1973855。
那么，所有地址分配机构(例如互联网服务提供商和云服务提供商)都已参与其中，对吧？它们有时会以极快的速度轮换IP地址，至少比6天更快。
这里有很多操作空间，除非它们在重新分配IP地址前先对其进行冷却处理，或者在重新使用IP地址前先查询并撤销任何证书？
如果地址分配机构未参与，则用户需自行验证主机头并拒绝基于不受欢迎IP地址的连接，直至所有遗留证书消失/或撤销任何遗留证书。或者干脆等待使用你的全新IP？
我好奇不同云服务提供商能以多少资金获取多少IP证书。
>所以所有地址分配机构(如ISP和云服务提供商)都同意了，对吧？他们有时会以极快的速度轮换IP地址。至少比6天更快。
>这里有很多操作空间，除非他们可能在重新分配前先冷却IP地址，或者在重新使用IP前查询并撤销相关证书？
我看不出来这与从云服务提供商获取的自定义/个性化域名有何不同。例如在Azure上，你可以为虚拟机分配一个DNS名称，格式为myapp.westus.cloudapp.azure.com，证书颁发机构(CA)会乐意为此签发证书[1])。这些域名也没有冷却期，因此理论上如果你的虚拟机被退役，其他人可以抢走该域名。
[1] https://crt.sh/?identity=westus.cloudapp.azure.com&exclude=e…
事实上，这些云资源确实存在奇怪的冷却期。我对 AWS 不太熟悉，但我知道在 Azure 中，一旦你删除/释放其中一个子域，它仍会与你的组织/租户绑定 60 或 90 天。
在此期间你可以重新获取它，但其他租户/组织会收到该名称已被占用的错误提示。如果你能证明你拥有这两个组织，可以联系支持团队寻求帮助。我在跨组织迁移一些资源时遇到了这个问题
区别在于方向性。
这里的攻击不是“从之前获得过证书的人那里抢走域名”，而是“获取一个IP地址，申请一个证书，然后释放它，让某个有趣的人捡走”。
实际上，这似乎风险相对较低。你需要为该 IP 获取证书、释放它、让其他人接管，确保该人正在进行公开可见且值得进行中间人攻击的活动，然后劫持 BGP 或 DNS 以对该 IP 的流量进行中间人攻击。你大约有6天时间完成这些操作。此外，如果你能劫持目标的DNS或IP地址……你就可以跳过这些繁琐步骤，直接为该目标获取一个有效的全新证书。
这就是为什么Azure现在默认在主机名后附加一个唯一的哈希值(如有需要可更改)。如果你攻击一个指向哈希附加主机名的悬空CNAME子域记录，是无法成功的，而Azure允许你控制唯一性，无论是全局/租户/区域级别，因此你可以在该租户/区域内使用常见名称。
AWS 为其域名设置 CAA 记录，因此无法为其签发证书
> 那么所有地址管理机构(如 ISP 和云服务提供商)都已参与其中，对吧？
我的猜测是，这将以相反的方式处理。毕竟，ISP 的职责不是按照 TLS 标准分配 IP 地址；而是 TLS 提供商的职责是“验证身份”——即按照生态系统中其他部分为各种短暂资源(如 IP、FQDN 等)绑定身份的方式，签发符合 TLS 标准的证书。
这篇文章没有说明他们将如何处理这个问题，但我的直觉是，Let's Encrypt 将维护一个逐步扩大的白名单，用于长期存在的 IP 发行商 ASN，然后只为这些 ASN 下的 IP 颁发证书；如果某个 IP 被出售给列表中没有的其他 ASN，则会撤销该 IP 的证书。该列表很可能是一个类似于 Mozilla 的公共后缀列表(Public Suffix List)的公开数据库，LetsEncrypt 预计将与其他希望进行 IP 签发的 ACME 签发机构共享(并可能共同维护)该数据库。
我在 LetsEncrypt 的公告中并未看到任何表明这种情况的迹象。你能详细说明你是如何得出这种推论的吗？
你可以在域名到期前一天续签 HTTPS 证书，有效期为 90 天。你的证书颁发机构无法查看与你自动续签绑定的信用卡是否已达到额度限制。
我认为使用IP证书的人不会是那些在一周后放弃IP地址的人。我能想到最有用的可能是某些非常奇怪的遗留软件，或者无需共享IP(如Cloudflare)即可支持加密客户端问候/加密SNI。前者不会随意放弃IP地址，后者则无法成功建立与真实域名的连接。
> 我想知道不同云服务提供商能用多少钱购买多少个IP证书。
我好奇他们是否会在未来提供通配符证书。
如果你指的是Let's Encrypt，他们从2018年开始提供通配符证书。
据我所知，AWS应用程序负载均衡器(HTTP/L7)会以最快每30分钟的速度轮换IP地址(基于我大约5年前的跟踪数据)。我认为他们为DNS记录设置了10分钟的TTL
甚至更短——60秒TTL。
> 那么所有地址管理机构(如 ISP 和云服务提供商)都已配合实施了？它们有时会以极快速度轮换 IP 地址，至少比 6 天更快。…
或将多个客户同时分配到同一 IP 地址。但假设它们不会愿意完成必要流程来为以这种方式使用的地址获取证书。
不过，为了以防万一，最好对所有软件进行审计，确保它们不会使用基于IP的SAN来验证连接，即使有人在URL中嵌入原始IP地址。
这简直是疯狂。
在Let's Encrypt的历史中，曾有过对同一服务器上有多个客户的托管提供商的担忧。事实上，与之相关的现象导致了一种挑战方法被废弃，另一种方法被修改，因为重要的是，一个客户不能仅仅因为与另一个客户在同一服务器上托管，就能够代表另一个客户通过CA挑战。
但并未得出结论认为，同一服务器上的客户仅因共用服务器就无法获取证书，或合法控制某个 IP 地址默认服务器的实体无法获取证书。
如果客户端会将https://example.com/和https://96.7.128.175/视为相同的标识符或安全上下文，仅仅因为example.com解析为96.7.128.175， 但我尚未听说有客户端会这样做。您有吗？
如果客户端在某种自动安全机制中不会混淆这些内容，我看不出来IP地址证书比(或与)托管在同一IP地址上的不同客户的证书有何不同或更差。
它们更差的地方在于，IP地址通常不稳定且会被频繁更换，因为地址的最终用户通常并非其所有者。这类似于为myapp.github.io获取证书，虽然技术上完全有效，但GitHub随时可能夺走该名称，因为他们是所有者，而非你。
这是一个重要的区别。为了部分缓解这一问题，Let's Encrypt 将签发仅有效期为 6 天的 IP 地址证书(而非 90 天、365 天或其他任何时段)。
> 这些证书仅在短效配置文件下可用(有效期为 6 天)
那么，在多个用户位于NAT后方的情况下，针对96.7.128.175的证书将识别哪个实体控制该地址的443端口？
是的(如果使用了TLS-ALPN-01挑战方法)。CA/B论坛基础要求目前允许使用以下四个指定端口中的任何一个来证明控制权
> 授权端口：以下端口之一：80(HTTP)、443(HTTPS)、25(SMTP)、22(SSH)。
Let's Encrypt仅使用80和443端口。
对于域名和IP地址的证书，情况相同。
此外，HTTPS 证书用于传输过程中的加密，因此我认为同一服务器上的所有网站都可以使用同一证书。
也许我没有表达清楚。我认为 IP 证书不会被用于共享服务器，更不会以租户可以冒充彼此的方式发放。反正也不常发生，不用担心。
重点是这会影响该方案的实用性。
……别让我开始谈论那些“挑战方法”。光是想想就让人不寒而栗。我会开始抱怨X.509协议简直该被废除。看吧，我已经开始了。该吃药了……
CA/浏览器论坛用他们那严苛的政策声明来支持这一点，真是荒谬。
我明白这在技术层面如何运作，但它的预期使用场景是什么？
仅仅是ESNI/ECH就是个大问题。
我记得反对加密服务器名称指示(ESNI)的主要论点之一是，它仅对像Cloudflare这样的巨型HTTPS代理服务有效，而提出IP证书作为解决方案的构想最终被视为不切实际的幻想。借助IP地址证书，现在每个服务器都可以参与ESNI，而不仅仅是大型服务商。如果这种做法足够普及，以至于客户端默认所有网页服务器都拥有IP证书，并在每次连接时尝试使用ESNI，这将对互联网隐私保护带来巨大益处。
那么流程是这样的吗？
想要连接到 https://www.secret.com。
通过 DNS 解析，获得 1.2.3.4
连接到 1.2.3.4，验证证书
发送 ESNI，获得 http://www.secret.com 的单独证书，验证该证书
…而你正在缓解的威胁应该是，你不想在未确认与合法的1.2.3.4通信前透露“www.secret.com”这个名称，以免攻击者伪造1.2.3.4的IP流量，从而得知谁在连接到www.secret.com。这样理解正确吗？
但 DNS 解析步骤仍未受保护。因此，有两种主要情况：
1. 您的对手可以篡改 DNS。在这种情况下，IP 证书毫无价值，因为他们可以将您指向 5.6.7.8，而您会乐于向他们披露“www.secret.com”。而且您没有其他途径来传达任何关于信任哪些密钥的信息。
2. 攻击者无法篡改DNS。但如果你能依赖DNS，就可以将其用作传输密钥信息的通道；你可以在DNS记录中包含用于加密www.secret.com的ESNI密钥。即使攻击者能够伪造1.2.3.4的实际IP流量，也无济于事，因为他们不会拥有与该ESNI密钥对应的私有密钥。而这些密钥已经标准化。
那么，哪些攻击者会被IP证书阻止，而这些攻击者已经被DNS中的ESNI密钥记录阻止了？
当然，我同意，隐私的下一个提升来自于使用DoT/DoH(事实上，一些浏览器要求使用DoT/DoH才能使用ESNI)。接下来可能需要添加DNSSEC。拥有IP证书只是朝着这个方向迈出的又一小步。
>你在DNS记录中包含一个用于加密“www.secret.com”的ESNI密钥
我从未听说过这种做法，这在今天是否已经存在？(编辑以删除不必要的评论)
>我从未听说过这种做法，这在今天是否已经存在？你是否在用一个不存在的假设来论证，认为这一小步改进是多余的？
参见：https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypt…
谢谢。
> 另一个互联网草稿引入了通过HTTPS和SVCB DNS记录类型传输ECH公钥的参数，从而缩短握手过程。[24][25]
[25]: 通过DNS服务绑定初始化TLS加密的ClientHello | https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
DNSSEC 是完整性控制，而非隐私控制。
gp提出了一种情景，即完整性漏洞被提升为隐私漏洞，坚持严格区分似乎在此背景下并不实用。
我认为这是一个合理的补充。在安全讨论中，若不极度谨慎，绝不能随意“加入一点DNSSEC”。
关键在于不向监视的对手显示任何DNS名称。你使用DoH，你使用IP证书，你在命名任何名称之前进入TLS。www.secret.com在明文中从未可见。
只有当IP本身不具有指控性或揭示性时才有用，也就是说，它是来自Cloudflare、GCP、AWS等大型池的IP。
依我之见，验证像1.1.1.1或8.8.8.8这样的地址是否如其所称更为有趣，但通过TLS运行UDP DNS仍可能不切实际，且DoH已存在，因此我看不出来这有什么帮助。
显然你在加密DNS。
> 如果客户端普遍假设所有网页服务器都拥有 IP 证书
这绝非安全假设；私有和/或动态分配的 IP 地址始终存在。
其他回复中提到了许多良好用例，但未提及 NTS。
如果您想使用NTS，但无法获得IP证书，那么您将需要先通过DNS获取可信时间。如果DNS不可用，那么您就无法获取时间。DNSSEC的一个常见问题是时间不正确，导致验证失败。如果您启用了DNSSEC且时间不正确，但NTS依赖于DNS，那么您将无法恢复。将IP作为证书的一部分，可以实现无需DNS即可获取可信时间，从而修复您损坏的DNSSEC强制执行。
如果您不知道时间，如何验证X.509证书？
假设您的设备通过DHCP获取IP地址，有一种解决方案无需在软件中硬编码IP地址。
DHCP选项42(定义于RFC 2132)可用于指定多个NTP服务器IPv4地址。
(还有DHCP选项4，但该选项用于指定较旧的RFC 868时间协议的IP地址。)
DHCPv6通过已废弃的RFC 4075提供选项31用于SNTP，通过RFC 5908提供选项56用于NTP。
因此，这可能是最佳方案：从 DHCP 或 DHCPv6 获取 NTP 地址，使用该地址设置时钟，然后执行所需操作！
(是的，这需要您信任 DHCP 源及其 NTP 参考。)
哦，这是一个很好的观点！查看我的 DNSSEC 域名(由 CloudFlare 托管)在 https://dnssec-debugger.verisignlabs.com 上的信息——初始时间和过期时间似乎有效期为… 3.5天？我平时不太关注这个，但我想这取决于具体实现。新的短效证书有效期为6天。因此，从粗略判断来看，我预计X.509证书的时间敏感性会比DNSSEC低一些——但仅差几天。而且，这很可能取决于具体实现细节。这是一个很好的观点。
实际上，在获得网络时间之前，你依赖于硬件时间。
ChromeOS 对此有一个相当有趣的设计：https://www.chromium.org/chromium-os/chromiumos-design-docs/…
本质上：保留一些时间的最小值。然后进行一次 HTTPS 请求，最初忽略证书日期的验证，但使用 Date 标头在后续验证时与最小值/最大值进行对比。此方法的优势在于仍为HTTPS请求，因此无法被中间人攻击(MiTM)，且根据实现方式可较好地验证时间(即使设备已断电，仍可能在磁盘上保存了最近的时间戳，因此通过定期使用设备，旧证书将不再有效，从而保留了证书有效期这一核心特性)。
我认为它不会这样做，但你可以不使用 DNS，因为 8.8.8.8 等已经拥有 IP 地址证书：
curl -sI https://1.1.1.1 | grep -i ‘^date:’ curl -sI https://8.8.8.8 | grep -i ‘^date:’ curl -sI https://9.9.9.9 | grep -i ‘^date:’不过这需要自定义工具，因为 curl 仅支持 –insecure 选项，无法跳过证书的 notBefore/notAfter 验证。
(这并非唯一使用此技术的方法，OpenBSD 的 ntpd 支持通过 HTTP 头部限制时间： https://man.openbsd.org/ntpd.conf#CONSTRAINTS — 默认的 ntpd.conf 文件通过 IP 地址配置了 Quad9。)
似乎可以通过配置同时提供 IP 和主机名来避免此问题，其中主机名用于 TLS 验证。
是的，这绝对可行，但并不意味着这将成为默认设置。我最近在[0]中评论过 Ubuntu 在 25.10 版本中默认仅启用 NTS(通过域名)的决定。这引发了一个问题：如果初始时间超出证书有效时间范围，系统时间如何设置。我没有查看，但或许Chrony仍会使用本地网络中已发布的NTP服务器。
[0]: https://news.ycombinator.com/context?id=44318784
有时在 DNS 进行重大重构时，您希望保持证书有效。例如，为了确保仪表盘可用，或确保旧自动化不会因 DNS 问题而失败。
在其他情况下，DNS 根本不需要。您可能更倾向于简单性，以及不受 DNS 传播影响的独立性，这样您就可以在测试环境中立即暴露您的 Cockpit。
这里唯一限制我们的就是想象力。
所以使用“密钥即名称”方案。
完全没有必要将 IP 地址引入其中。
考虑使用 WireGuard：它在 IP 层工作，但通过加密密钥提供身份验证。在小型内部网络中，你可以无需依赖正式的 DNS。
(显然，这在不使用讨论中的 IP 证书的情况下也能正常工作。)
> 因此，采用“密钥即名称”的方案。
请详细说明。
> 完全没有必要将 IP 地址引入其中。
不确定你指的是哪种情况，但 IP 地址确实难以避免。DNS 则很容易规避——你只需不进行配置即可。
“将 IP 地址引入其中”实际上是唯一可行的选项。
https://yggdrasil-network.github.io/
这是一个网状路由网络，你的身份就是你的公钥，而你的IPv6地址是从你的公钥的哈希值中派生出来的。
运行完美
>> 因此，转到“密钥即名称”。
> 请详细说明。
直接通过其加密密钥识别服务。当你配置其他东西连接到它时，将IP地址视为提示，而不是与之通信的主要标识符。标准惯例。…
在你告诉我这不可行，因为你必须修改软件之前，先调查一下所有现有的代码，看看其中有多少支持IP地址证书。如果你在某个大型复杂系统中移动组件，几乎可以肯定的是，如果你盲目地在https:// URL中插入IP地址，许多组件都会出问题。
而且，如果你正在修复软件，那么将身份与一个你需要经常更改的东西(如IP地址)绑定在一起，这并不合理。尤其是如果这些地址是全球地址(这是Let's Encrypt或其他任何公共CA唯一会认证的地址类型)且位于IPv4地址空间(这是任何“企业”似乎唯一愿意使用的地址空间)。
BSD网络堆栈将IP地址视为有效的域名进行域名解析。因此，任何能够通过域名进行TLS连接的手机、平板电脑和计算机，都可以通过IP地址进行连接。试试看！自行签发一个IP证书，并在本地网络中测试。如果你将其放入信任存储库，它将正常验证。采用的唯一障碍是CA拒绝大规模签发IP证书。
不完全正确。DNS主机名和IP地址在X.509证书中的编码方式不同：前者是subjectAltName扩展中GeneralName选择类型的dNSName选项[1]，后者是iPAddress选项。(而且在你问之前，将字符串化的IP地址四元组标记为dNSName属于CA/浏览器论坛基线要求[2]中的错误签发，可能导致你的CA被移出证书存储库。模糊的编码是危险的。)因此，TLS库确实需要明确支持。但我确实不了解有多少应用程序在使用IP地址证书时遇到问题。
[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1….
[2] https://cabforum.org/working-groups/server/baseline-requirem…
嗯，我熟悉的BSD网络堆栈根本不包含TLS或X.509验证。问题不在于你从gethostbyname函数中得到什么，而在于当你将结果传递给X.509验证器时会得到什么。
> 去调查所有现有的代码，看看其中有多少支持 IP 地址证书。
我多年来一直在做这件事(约 60% 是旧的“企业/遗留”系统，约 40% 是现代系统)，从未见过不支持它的系统。因人而异，但如果我接触的所有系统都支持，我不会无端抱怨。
> 如果你盲目地在https:// URL中插入IP地址，那些部分会出问题。
我做过很多次，似乎遗留系统在这方面总是对我宽容。
> 像IP地址这样需要频繁更改的内容
这也是个人假设。如果你的架构经常更改IP地址，那没问题。我之前接触的架构并非如此。许多组件的IP地址在十年或二十年内从未更改过。甚至我之前使用的两个本地ISP都提供了“动态公共IP”并长期保持不变。对于某些公司而言，更改主防火墙/负载均衡器或VPN服务器的IP地址是不可想象的。
即使在我最近的公共云项目中，我做的第一件事就是确保公共IP地址不会动态变化(即使服务重新创建后也能保留)，这样我就不用处理企业客户端终端和代理随机刷新DNS缓存带来的后果。(别问我为什么，但即使是大公司仍在大规模使用代理。祝你好运，弄清楚这样的代理何时会使你的DNS记录失效。)
> 在IPv4地址空间中
IPv6已经到来。你的打印机和灯泡也需要证书。
对于“机会主义”的DoTLS而言，针对authdns服务器可能具有一定吸引力，这些服务器可能在DoTLS端口上监听，且证书中包含与authdns服务器公共IP地址匹配的SAN字段。(目前可以通过authdns服务器主机名实现此功能，但一个公共authdns IP可能对应多个不同名称，而这种方式能更清晰直接地将相关元素关联起来。)
在HTTPS请求中隐藏SNI也可能有用。鉴于当前ESNI/ECH的状态，您需要某种代理域名，但对于仅托管少数网站的小型服务器而言，每个域名都可能被识别(与通用Cloudflare证书或通用Azure证书不同)。
我猜这主要是针对业余爱好者和一次性使用场景，人们并不在意将主机名与项目关联。
一个用例是直接连接到 DoT(DNS-over-TLS)服务器，而非使用主机名。如果你通过 OpenSSL 建立到 IP 地址的 TLS 连接，它会验证 IP SAN，如果不存在则会失败。
虽然不常见，但确实存在自定义IP地址的用例。例如，https://1.1.1.1的证书既签名了IP地址，也签名了域名one.one.one.one
这可能对本地/开发环境工作有用。无需设置`my-dev-env.staging.service.com`等域名即可测试HTTPS。
但这些是公共证书。大多数个人电脑位于NAT之后，即缺乏公共IP地址。
是的，确实如此。
这有助于摆脱ICANN的域名系统。这使竞争对手能够支持HTTPS而无需使用自签名证书。
在家中自托管时使用静态IP地址
你可以像指向其他IP地址一样轻松地将域名指向你的家庭IP地址。
有效期仅为6天，所以我假设它不适用于长期使用场景？还是我理解有误？
它们仅适用于公开可访问的IP地址，因此与常规Let's Encrypt证书相同——旧证书过期后需重新获取新证书。
证书有效期与可用性无关。它只是保持撤销列表简短。
我猜在基础设施中，没有 DNS 条目的设备相当常见，我可以在工作中利用这一点。
你无法为任何不符合以下两个条件的地址获取证书：(a) 全球范围内的，(b) 实际上可从互联网访问的。
预期用例是禁止使用纯HTTP，以便在没有第三方许可的情况下无法与隔壁的计算机通信。
不错，又一个针对 TLS 的漏洞。之前的漏洞都涉及为不属于你的域名生成有效证书。这个漏洞则是为不属于你的 IP 地址生成证书。黑客们会在 Telegram 上欢呼雀跃 🙂
这是否有助于在我的本地路由器上实现加密的HTTPS(无自签名证书错误)？例如登录页面为192.168.0.1。
不，但也许可以：为本地地址签发证书既不可能也不可取。无法验证本地地址，因为它们本质上是本地地址，而非全球可路由的。
然而，如果路由器制造商愿意，他们可以让设备为其公共IPv4地址请求证书，前提是该地址未处于CG-NAT之后。对于IPv6而言，这相对容易实现，因为(除非你使用的是被诅咒的ISP)所有IPv6地址通常都是全球可路由的。
不，他们不会为私有IP地址签发证书，因为你无法对其进行独占控制(即同一IP地址在他人网络中可能指向不同设备)。
不，而且不应该这样做。你可以运行一个带有真实域名和真实证书的代理，然后使用 DNS 重写将该域名指向本地主机
例如，如果你想要一个 UI，可以使用 Nginx Manager，并使用 AdGuard 进行 DNS 解析。将路由器设置为使用 AdGuard 作为唯一 DNS。为你的域名添加一个重写规则，使其指向代理。注册域名并获取真实证书。问题解决
我所有的本地服务都使用HTTPS
不，恰恰相反。你无法为非全球IP获取有效证书，但你可以为域名获取证书并将其指向192.168.0.1。
你必须拥有该IP。
不，但你可以做一些相关的事情：
– 获取一个域名(foo.com)并为*.foo.com获取证书
– 运行一个DNS解析器，将a.b.c.d.foo.com(或a-b-c-d.foo.com)映射到对应的私有IP a.b.c.d
– 在该私有IP地址的设备上安装foo.com证书
然后你可以通过IP地址连接到本地网络中的设备，使用https://192-18-1-1.foo.com
由于您需要在上述第3步中安装证书，因此使用长期有效证书会更合适，当然，自动化工具在此处也能提供帮助
Cloudflare DNS(可能还有其他服务)允许您为子域名输入私有IP地址，因此您无需自行运行DNS服务器。该服务未启用AXFR功能，因此除非有人专门针对您的子域名进行字典攻击，否则不会存在隐私问题。
我曾考虑在某个项目中这样做。
后来我意识到，当我的互联网断开时，192-18-1-1.foo.com 无法解析。而当我的互联网断开时，正是我想要访问路由器管理页面的时候。
我决定简单地使用未加密的 HTTP 是一个更好的选择。
> 然后我意识到，当我的互联网断开时，192-18-1-1.foo.com 无法解析。
只需在本地 DNS 服务器(很可能是你的路由器)上添加一个本地 DNS 条目。
我可以开始运行自己的DNS服务器，并手动维护其中所有重要条目，当然可以。
或者我也可以直接使用HTTP，或自签名证书。如果攻击者通过我家墙壁内的20英尺以太网电缆截获流量，我可能面临的问题远不止保护路由器管理密码。
有趣的是，示例证书中没有主体字段。
这是因为证书是为IP地址申请的，而其他DNS条目是SAN的一部分吗？
我们(Let's Encrypt)正在取消主体通用名称，转而仅使用主体替代名称。
这一更改已应用于短效(6天)证书配置文件。经典配置文件(90天)尚未进行此更改。
您是否遇到过无法处理CN的客户端？这种情况是否属于那些无法处理的客户端也因其他原因(例如不支持TLS 1.2、不理解IPv6等)而无法解决的场景，因此您可以告诉用户这不是他们最大的问题？
是时候重新翻出CVE-2010-3170了吗？ 🙂
我猜很多“自行实现X.509验证”的逻辑都会存在这个漏洞，但要利用它需要一个行为异常的CA为你签发此类证书(即可能性较低)
这似乎针对的是公共IP地址，而非私有RFC1918 IPv4地址范围。
唯一可能的验证方式是HTTP和TLS-ALPN，而非DNS，因此“证明”你拥有该IP的依据是Let's Encrypt能与之建立连接？
是的，这与通常验证域名控制权的方式相同；DNS仅在少数情况下使用，因为它无法像其他方法那样一键完成。
拥有DNS并不会提供更多“证明”。申请者可以选择提供哪种形式的证明，因此增加更多选项只会让“证明”事情变得更容易。
我不确定它是否正在积极使用，也不清楚其技术实现细节是否已正式标准化，但一个显而易见的方法是：
1. 为域名创建一个 CAA(证书授权机构授权)DNS 记录
2. 在 CAA 记录中明确禁止除您选择的 CA 之外的任何机构签发证书。合格的CA会遵守这一指令(遵守该指令是根信任存储库的要求，当然存在漏洞，但总体合规性非常高，且与他们对特定验证方法的实现无关)
有趣。我好奇这种证书是否能与XMPP联邦兼容。
是否有仅使用 IP 地址作为主机的公共 XMPP 服务器？我从未听说过这种情况，但内部可能存在这种情况。
这是针对 IPv4 和 IPv6 吗？
两者均适用。
那么，有人能提供官方对这种荒谬做法的解释吗？
公告链接是https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/。我认为这并不复杂：有些服务由于各种原因没有域名，而是通过公共静态IP地址访问，它们需要TLS证书来保障安全，而其他证书颁发机构(CA)提供此服务，因此Let's Encrypt也应该提供。有没有什么特定理由说明它们不应该提供？
嗯。完全没有解释为什么有这种需求。仅凭这个公告，我只能假设原因就是“因为我们能做到”。
因此，不这样做的第一个原因是，你绝不应该在没有充分理由的情况下更改软件。而到目前为止，这里提到的所有用例都站不住脚。它们要么是现有系统已经很好地解决了的技能问题，要么是根本性的误解，实际上行不通。
更改命名的基本假设是一个特别糟糕的主意，因为这几乎总是会打开安全漏洞。我无法指出具体哪个软件在IP地址证书不可用方面做出了承重级别的安全假设(更可能是两个假设的组合：“用户会知道这一点”和“这种情况不会发生/我忘了这一点”)……但我会在它崩溃时发现这个问题。
此外，如果 IP 证书得到广泛使用(而 Let's Encrypt 绝对有足够的影响力推动这一点)，那么基本上每个验证器都必须包含 IP SAN 的代码路径。说“你不需要使用它”和说“你不需要使用 IP”一样荒谬。每个X.509库最终都会包含IP SAN的代码路径，而且它甚至无法被优化掉。每个库因此变得更大、更复杂，需要更多的维护和测试。这是一项巨大的外部化成本。最好修改RFC以废弃IP SAN；它们本就不该被标准化。
这还会鼓励一系列不良实践，导致网络变得脆弱且难以维护。你几乎不应该在DNS区域文件(或其他名称解析协议)之外看到IP地址。你可以辩称人们不应该做一些愚蠢的事情，比如硬编码IP地址，即使他们被提供了工具……但这对那些愚蠢决策下游的第三方来说毫无安慰。
…而且它甚至对所有IP地址都不起作用，因为IP地址不是全球名称。因此，在涉及X.509证书的每一行代码中，都不要忘记对本地管理的地址空间进行特殊处理。
针对IP地址的TLS证书已经存在。例如，你现在就可以在浏览器中访问https://1.1.1.1(该地址曾实际提供HTML内容，但现在已改为重定向)。如果某个 TLS 客户端无法支持此功能，这将被视为该客户端的缺陷，且此判断是合理的。既然技术已成定局，没有人会仅仅因为追求更简洁的实现而移除当前已正常工作的功能支持。因此，TLS 客户端早已承担了支持 IP 地址证书的可维护性成本，这并非新变化。
我不确定为什么私有IP地址需要与公共受信任CA签发的证书有所不同(签发公共CA证书的软件高度专业化，可以处理额外的几行代码，这对整个生态系统来说不是大问题)。私有CA可以且确实会为私有IP地址签发证书。
此外，没有这个功能，DoH或DoT如何工作？
> IP地址的TLS证书已经存在。
目前尚未广泛使用。只有当它被广泛使用时，才需要将其纳入一切。
目前，这只是一个花哨的技巧，而且是一个本不该起作用的技巧。
> 没有人会仅仅因为这样做会稍微干净一些，就移除对当前有效功能的支持。
虽然能用，但不应该用，而且实际上除了疯子之外没人会用。
> 如果在某个 TLS 客户端中无法正常工作，这将被视为该客户端的 bug，而且理应如此。
我曾尝试在内存不足以解析 X.509 的微控制器上使用 TLS。仅仅因为能用就添加这些内容并不会让情况更好。
… 我不会去查阅相关 RFC，但我非常怀疑 IP SAN 是否被列为“必须”。如果我错了，那 RFC 里仍然存在 bug。
> 此外，没有这个，DoH 或 DoT 该如何工作？
为可信解析器硬编码密钥。鉴于整个CA基础设施早已放弃对证书请求者的任何真正可靠验证，让DNS依赖X.509本就是个糟糕的主意。但如果你执意要这么做，尽管这很糟糕，你也可以通过本地DNS解析器进行初始化，然后使用域名连接到你的DoH/DoT服务器。
DoH本身当然是个糟糕的主意，但这又是另一个复杂的问题。
我认为他们完全可以为这些IP地址颁发子域名和证书，从而使整个系统安全得多。
我也能理解相反的观点：域名谁知道呢，有人可能窃取它或黑入注册商，注册商可能有恶意，DNS服务器可能不可信或有恶意，或被中间人攻击……连接到IP地址可以消除整个方案中的弱点类别。
当然，有人可能窃取google.com吧
https://github.com/cabforum/servercert/pull/579/commits
</s?
抱歉，但“要求验证DNSSEC(当存在时)用于CAA和DCV查询”与签发包含IP地址SAN的X.509证书有何关联？我未发现任何关联，且在快速浏览评论时也未注意到相关内容。
那些担心日益严格的DNS要求会导致系统故障的人，因为他们无法修复父域的DNSSEC配置错误。这似乎是一个有趣的时机巧合，所以我好奇是否有什么(不)合理的解释。(实现一个必须固有地存在你最终要解决的缺口的SAN，对你来说一点也不好笑吗？)
我个人从未觉得用正则表达式解决生产环境问题很舒服。这里提到的证书代码就说明了原因：
https://github.com/mozilla-firefox/firefox/blob/d5979c2a5c2e…
天啊。
我认为这并不涉及任何安全关键操作，它只是将IPv6地址格式化以便在证书查看器界面中显示。
该正则表达式仅将IPv6地址拆分为4位一组，用“:”连接，并将任何“:0000:”序列折叠为“::”。我未发现其中存在问题。
> 并将任何 “:0000:” 序列折叠为 “::”
这是个错误。任何类似 2001:0000:0000::1 的 IP 地址都会是错误的。它故意产生错误。编写此代码的人甚至没有花几秒钟思考 IPv6 地址的结构。
> 我认为这没什么问题。
除了它完全错误，并且需要编译正则表达式，而编译本身的工作量肯定比这更少。
它只对32位IPv6地址进行操作，因此不会被缩写。我的表述不够准确。它仅将任意数量的“:0000:”序列替换为“::”。
> 任何类似2001:0000:0000::1的IP地址都是错误的。
这既不是该代码的可能输入，也不是可能输出。
该示例无效，但类似于：3fff:0020::
的IPv6地址会在IP SAN中以3fff0020000000000000000000000000表示，该代码会将其展开：
“3fff0020000000000000000000000000” .toLowerCase() .match(/.{1,4}/g) .join(“:”) .replace(/b:?(?:0+:?){2,}/, “::”) '3fff::20:0000:0000:0000:0000:0000:0000'该地址包含过多部分且无法解析为IPv6地址。但如前所述，这只是展示代码。如果这并非实际错误，我不想浪费时间，但或许LetsEncrypt测试版中的某人可以实际生成证书，以验证此类格式化的IP地址在实际中是否存在问题…
这个确实看起来像是个错误。我收回之前的说法。
> 除了它完全错误且需要编译正则表达式外，所需的工作量肯定少于编译本身。
不是的。你描述的序列甚至不会被解析，因为冒号不是IPv6扩展的SAN的一部分。请在发表此类无稽之谈前先自我学习。
除非你看到明显的问题，否则我没有：我认为你搞错了因果关系。你“天啊”是因为你对正则表达式的不熟悉和缺乏实践。
> 你“天啊”是因为你对正则表达式的不熟悉和缺乏实践。
这简直是自以为是，甚至有些傲慢。
> 我认为你在这里搞错了因果关系。
我在哪里暗示了因果关系？这只是一个查看代码的机会。这是糟糕的代码。我不会通过这个。你在这里使用正则表达式的_理由_是什么？
> 我在哪里暗示了因果关系？
> > 这里引用的证书代码说明了原因
那么这里有什么暗示呢？
> 这是一段糟糕的代码。
无需进一步解释，我认为我们在态度上旗鼓相当(:
什么不好？为什么不使用正则表达式？他们又不是用它来解析用户控制的HTML。像这样的简单字符串转换正是正则表达式的理想用例，手动遍历字符很容易变得低效且混乱。而且在这个过程中可能会引入错误(Unicode长度错误很常见)。
你是否也避免在 shell 中使用没有 -F 标志的 grep 和 sed？
这简直愚蠢至极。三向握手和初始密钥交换就是你的证书。
如果浏览器在使用自签名证书时不显示巨大的警告标志，那倒也无妨。
通常，您可以将叶子自签名证书作为CA导入到操作系统信任存储中，问题即可解决(假设该证书包含IP SAN)。虽然稍显繁琐，但您可以签发有效期较长的证书。
这听起来像是浏览器设计中的缺陷。
或者可能是因为您实际上需要验证一个身份(而IP地址并非身份)。
这如何保护你免受恶意网络的攻击？
证书如何起作用？如果你已经需要进行 TLS 握手，这不会改变任何事情。
经过验证的证书可以让你知道你没有与中间的攻击者进行握手。
天啊，这听起来不太好。
我认为在此情况下，SAN指的是“主体替代名称”(Subject Alternative Name)，而非“存储区域网络”(Storage Area Network)。
唉……希望人们在使用可能含糊不清(或晦涩难懂)的缩写词之前，先用完整词汇表达。这有助于避免读者因不熟悉作者所关注的主题而产生困惑。
在 TLS 证书颁发机构的技术论坛帖子公告中，这个首字母缩写词只有一种解释，而且并不算晦涩，上下文已经足够清晰。
如果你不知道如何在 TLS 证书颁发机构的博客文章中解读“SAN”，我认为你不是这篇帖子的目标受众。
HN上很多人都不是某篇帖子的目标受众，却仍然感兴趣。
(我的观点适用于所有写作和演讲，而不仅仅是这篇帖子。)
如果这是一篇博客文章或公告，我们肯定会提供更多上下文，而不仅仅是一个旨在有限分发的论坛帖子。
你只是使用了HN而没有展开这个首字母缩写！ 🙂
好吧，但链接到维基百科有多难？
在任何文本中首次使用首字母缩写时，完整展开缩写是标准的学术写作规范。
更多人应该熟悉这个概念，因为它非常有用且能确保沟通清晰。