Let’s Encrypt：6天有效期证书与IP地址证书现已全面开放
IP地址证书必须采用短效设计——此决策源于IP地址比域名更具临时性，因此需要更频繁的验证机制
Let’s Encrypt现已全面开放短期证书与IP地址证书服务。此类证书有效期为160小时(略超六天)。用户只需在ACME客户端选择“shortlived”证书配置文件即可获取短期证书。
短期证书通过强制更频繁的验证机制，降低对不可靠撤销系统的依赖，从而提升安全性。当证书私钥泄露或遭破坏时，传统做法是在证书到期前通过撤销机制控制损害。但撤销系统本身存在不可靠性，导致依赖方在长达90天的证书有效期内持续暴露风险。采用短期证书可大幅缩短此类风险窗口期。
短期证书采用主动选择机制，目前暂无设为默认的计划。已实现完全自动化续期流程的订阅用户可轻松切换至短期证书，但我们理解并非所有用户都具备此条件且普遍接受如此短的有效期。我们期待未来所有用户转向自动化解决方案，并证明短期证书的有效性。
如先前公告所述，未来数年内我们的默认证书有效期将从90天逐步缩短至45天。
IP地址证书允许服务器运营商对IP地址而非域名进行TLS连接认证。Let’s Encrypt同时支持IPv4和IPv6协议。IP地址证书必须采用短效设计——此决策源于IP地址比域名更具临时性，因此需要更频繁的验证机制。您可通过我们首个IP证书发布公告进一步了解IP地址证书及其应用场景。
在此特别感谢开放技术基金、主权技术机构，以及我们的赞助商和捐赠者对本项目开发的支持。
本文由 TecHug 分享，英文原文及文中图片来自 6-day and IP Address Certificates are Generally Available。
共有{276}条精彩评论
正如本帖已提及，目前无法使用certbot获取IP地址证书。可通过lego[1]实现，但昨日我费了一番功夫才摸索出精确的命令行。以下是我成功使用的配置：
lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived
[1] https://go-acme.github.io/lego/
不知Caddy是否已支持此功能
(似乎仍在开发中 https://github.com/caddyserver/caddy/issues/7399)
功能正常，但正如其他评论所述，IP证书(特别是IPv6)可能存在特殊情况，希望v2.11版本能修复这些问题。
我的Caddy中IPv4证书运行良好，但IPv6方面仍有待完善。
Certbot对此的开发正在进行中，部分初始工作已合并，但仍有大量工作待完成。https://github.com/certbot/certbot/issues/10346
https://github.com/certbot/certbot/pull/10370 证明了只需少量改动即可实现概念验证，尽管该方案采用临时编码且已被弃用(但提交者至少秉持善意并进行了协作) :/ 当前主要考量似乎是变更管理与向后兼容性。
感谢分享乐高命令！
这让我能快速获取几个IP证书进行测试。我已更新简易TLS证书检测器(https://certcheck.sh)，现支持检测IP证书 (目前仅限IPv4)。
谢啦！！超赞
IP地址证书对希望运行自有DoH服务器的iOS用户尤为重要。
若配置文件包含带有效证书的DoH完全合格域名(FQDN)，但未正确配置(例如运行unbound的DoH服务器)，该配置在iOS中将无法生效。
究其原因，iOS系统要求FQDN和IP地址两者都必须具备有效证书。
这解释了为何dns4eu和nextdns等大型机构的配置文件能在iPhone上正常运行，而个人搭建的DoH服务器(及配置文件)却无法生效。
顺便提一句，OpenSSL在建立TLS连接时对证书SAN字段包含IP地址的要求相当严格。iOS工程师可能并未明确添加此要求，这或许只是使用加密库时的副作用。
我每天都在反向代理后使用自有域名的DoH服务，从未出现任何问题
为何选6天而非8天？
– 8是幸运数字且为2的幂次方
– 8天可实现每周固定日期刷新，便于检查API 429超时问题
– 6是“兽之数”中每个数字的值
– 我就是讨厌6！
> 8天能让我每周固定检查API是否出现429超时
答案就在这里。
6天意味着在足够长的周期内，负载会均匀分布于整周。
8天则会导致特定工作日承受过载压力。
> 6天意味着在足够长的周期内，负载最终会均匀分布于整个星期。
人们会在cron中设置*/5，结果会相同，因为这显而易见、简单又美观。
若他们在cron中设置*/5，单次错误响应就会导致网站崩溃，而三月初同样会引发崩溃。
他们会改用*模式，每天执行以防万一
每日运行更新脚本是合理的。Certbot默认每日执行两次。只需采用类似逻辑，在短期证书到期前半段等待续期。这样实际负载就能均匀分散。正常配置下本应默认具备此逻辑。
多数人应该会这么做。即使LE证书要求如此我也不会惊讶。
我会设置周一和周四更新，避免周末服务中断。
若使用短期证书，我建议选择支持ARI(ACME续期信息)的ACME客户端。这样CA会主动通知客户端何时需要续期。
ACME不会在证书有效期充足时自动续期，因此续期时间始终固定在6天左右，即使更频繁检查也不会改变。
目前ACME对90天有效期的证书设置了12天的cron任务周期。
您指的是哪个ACME客户端？
我以为大家通常都设置为每日运行？若无需续期则不会执行任何操作。
那么现在想要人类在场的人，每周要续约两次而不是一次？
绝对不会。他们根本不想让人类参与任何续约事宜。
别担心，因为这并非6天(144小时)，而是约6天：160小时
而160既是前11个素数的和，也是前三个素数立方和的总和！
拉马努金先生，是吧？
本指望Wolfram|Alpha能自动输出上述结论，但直接输入160 [1]后得到：
> 160边正多边形可用直尺圆规构造。
> 160可表示为两个平方数的和：160 = 4^2 + 12^2
> 160是偶数。
> 160可表示为160 = 2^7 + 32。
> 160 能整除 31^2 – 1。
> 160 在十五进制中为单一数字循环：aa_15。
[1] https://www.wolframalpha.com/input?i=160
每个K-Pax人都知道这个。
因为它让你能工作六天，第七天休息。就像上帝所做的那样。
² 到第七日，上帝已完成祂所做的工作；于是第七日，祂从一切工作中歇息了。³ 然而值班技术员——黎明之子路西法——在午夜被惊醒，只因上帝未更新天地的HTTPS证书。⁴ 路西法遂在盛怒中草拟了辞呈。
刚结束零售业的压力山大工作回家(哎谁骗谁呢，零售业天天都是压力山大)，这段文字让我笑出了声，正是我需要的解压。谢谢。
这是《圣经》的TLS版本吗？
我敢说这段内容被刻意隐去了
我误读成《圣经》的LTS版本了
吉尔福伊尔？
这让我开心一整天 😀
我觉得祂第六天后就没再工作了。转而去搞其他个人项目了
六天写提示词，一天放任特工们开启嗨翻模式
不是我的神。我的神本该去上班，结果喝得烂醉，最后穿着衣服抱着碗通心粉在浴缸里昏睡过去。
伊甸园不是有个致命漏洞吗？吃个苹果就能获取关于善恶的所有数据？
标准内存披露：苹果被吃掉后会被释放，但仍可被读取，导致内容泄露。幸好容量不大，没能全部窃取。不过天界正在维护中，等待用Rust重写。
实际是6又2/3！我也正试图推导160小时的依据却毫无头绪，若有知情者请务必告知。
200是个整数，正好对应8又1/3天，这样就能享受每周轮换的便利。
我选择了160小时。
CA/B论坛将“短期”证书定义为7天，这符合我们所需的简化吊销要求。该时限又基于OCSP响应的既往规范而设定。
我们通常会选择低于最大值的数值，以确保留有操作余地。具体原因可参考https://bugzilla.mozilla.org/show_bug.cgi?id=1715455案例。
这些设定基于一个粗略假设：处理任何突发事件(如服务中断)可能需要一两天时间。因此(假设证书或OCSP响应在有效期中途更新)，至少需要两天用于事件响应，再加上一天重新签名所有内容，故有效期至少需6天，最终要求向上取整为7天(如前所述，为保留操作余地)。
此外，我们通常不希望与天/周/月等周期对齐，否则可能引发“共振频率”类问题。
我们长期困扰于用户采用固定模式(如每月第一个周一午夜通过cronjob续签)导致的流量激增。我不得不花费大量时间说服用户将cronjob设置为随机执行时间。
对此我始终有些困惑。发放固定有效期证书实际上等于保证了流量波动。假设某次数据泄露后CDN大规模重签证书，引发巨量流量激增——那么[160 – $renewal_buffer]小时后必然出现完全相同的流量峰值。
模糊证书有效期能平滑流量峰值，避免硬编码值，最重要的是通过CT日志的统计分析，可增强信心——这些有效期窗口并非为加密攻击或实际攻击精心设计的。
这相当于一种https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number机制。
平滑流量的解决方案已存在：RFC 9733《ACME续期信息(ARI)扩展》。
https://datatracker.ietf.org/doc/rfc9773/
这只解决了问题的一半，且仅是建议而非客户无法忽视的强制要求。
它精确小于7，因此无法设置为每周轮换
两周一次轮换？
如今我们说泛周轮换
还是半周轮换？
六是最小的完美数。完美性在此至关重要。
为何不每日刷新？
这些观点很有价值
接下来希望他们专注于为.onion地址签发证书。现代网络中许多功能和协议都锁在HTTPS之后。.onion所有者持有对应密钥对，因此其所有权证明甚至比DNS更值得信赖。
《.onion特殊用途域名ACME扩展规范》
* https://datatracker.ietf.org/doc/html/rfc9799
* https://acmeforonions.org
* https://onionservices.torproject.org/research/appendixes/acm…
但既然Tor本身已对终端节点进行加密和身份验证，使用HTTPS是否多余？
例如HTTP/2和HTTP/3要求使用HTTPS。虽然从技术上讲HTTPS是冗余的，但鉴于.onion网站相较于常规网站普及度较低，应避免让浏览器为其添加特殊处理机制。
HTTP/2和HTTP/3对Tor隐藏服务流量有何益处？
由于每次请求可复用同一连接，页面加载速度显著提升。
没错，但浏览器会警告用户连接未启用HTTPS的网站——无论该网站是本地主机还是洋葱服务。
Tor浏览器已解决此问题，它将.onion视为安全上下文。
理论上不应在未明确支持Tor的浏览器中使用Tor。Tor浏览器、Brave等浏览器其实并不介意HTTP隐藏服务流量。
这会生成证书链，用于验证洋葱服务是否由声称的运营者管理。当然，根据具体情境，若证书本身可能导致信息泄露，那么为实现此目的而使用的证书反而可能风险过高。
DV证书(Let’s Encrypt提供的)不验证所有者身份。而.onion域名的EV证书可能真正有用，但通常需要付费获取。
同时适用于常规域名和洋葱域名的证书，能让你对共同所有权产生一定程度的信任。
需要IP证书的用户请注意：Certbot目前尚未支持此功能，相关PR仍在待处理中：https://github.com/certbot/certbot/pull/10495
不过acme.sh应该支持。
目前支持IP地址的ACME客户端包括：acme.sh、lego、traefik、acmez、caddy和cert-manager。Certbot的IP地址支持功能有望很快上线。
作为cert-manager维护者在此确认：是的，cert-manager应支持IP地址证书——若发现任何问题，欢迎随时反馈！
自v1.18版本起(当前支持的最早版本[1])，我们还支持ACME配置文件(短效证书必备)。
我们已提供基础文档[2]。配置文件按签发者独立设置，因此可轻松配置两个独立的 ACME 签发者：一个签发长期证书，另一个签发短期证书，从而实现向短期证书的渐进式迁移。
[1]: https://cert-manager.io/docs/releases/ [2]: https://cert-manager.io/docs/configuration/acme/#acme-certif…
若采用IP地址证书机制，传输模式IPsec是否可能重新获得应用价值？RFC 5660(注：本人为该规范作者)同样值得关注。
或许可能，但大概率不会。各类常驻式、SDN或大规模站点间VPN方案已部署足够广泛且时间足够长，现已成为预期基础设施。
即便让用户在IPsec隧道中使用证书也颇为棘手。这让我想起，帕洛阿尔托或Checkpoint的入门级设备至今仍存在证书链过长导致的认证故障——这始终令我费解，毕竟其控制平面十多年来配备的内存早已远超实际需求。
你的思路不够创新。我只关注ESP，而非IKE。不妨让TLS握手协商使用ESP，一旦选定，系统便会通过TLS协商的密钥(借助导出器)为该连接配置ESP。类似于ktls/kssl，但采用ESP机制。瞧——无需协调IKE凭证，什么都不用管——它就该直接生效。
真正的关键在于实现ESP硬件卸载。
我认同这个方案很理想，但预见到实施过程中会遇到更多社交层面的阻力。目前无论是大型机构还是业余爱好者，都已存在覆盖多数用例的解决方案，即便实现方式未必如此简洁。将节点间加密迁移至加速传输模式固然理想，但若用户已采用TLS，我认为多数人仍会坚持使用TLS，而非寄希望于双方都具备完整的握手→ESP路径支持。况且现有方案的故障排查经验更为丰富。
对应用层而言这仍是“TLS”协议，因此可行。但确实存在障碍，最关键的是缺乏有说服力的硬件支持。此外当今I/O速度已超越计算能力，加速加密反而可能适得其反 :joy:
IPsec还有用吗？
没有。我设想的是通过TLS握手机制实现ESP安全关联(SA)配对密钥与策略管理。原因在于：ESP在硅片上的实现复杂度远低于TCP+TLS组合。
若使用IPv6(无分片)，甚至使用IPv4(分片数据包→交由主机处理；PMTUD机制意味着绝大多数情况下无需分片)，ESP都是无状态的。无状态特性使硬件卸载易于实现。
IPSec是糟糕、臃肿且混乱的标准，连制定它的公司都花了20年才摆脱每年被披露CVE漏洞的窘境
但ESP(无论是否基于UDP)的优势在于：其硬件卸载方案远比TLS简单得多。
在此搬出陈年旧事散布恐慌毫无意义。
> IPSec是糟糕透顶、庞大臃肿且混乱不堪的标准，其制定公司花了20年才摆脱每年被曝CVE漏洞的窘境
这是事实，而非恐吓宣传。
微软过去两年间其IPSec堆栈就多次出现远程代码执行漏洞。
思科等大型厂商数十年来持续存在IPsec漏洞。
如今这些问题虽已被充分认知并记录，但该标准本质上确实糟糕。
我现已将证书更新周期设为两周以测试45天变更方案，结果现在竟收到有效期仅6天的证书？
这并非批评，我欣赏他们的做法，但更新机制该如何运作？若管道触发certbot时出错，我根本来不及修复。届时将面临两天更新周期与四天“调试窗口”的困境。
我确信有人需要这种方案，但绝非我。而且其理由也有些奇怪：
> IP地址证书必须是短期证书，这是基于IP地址比域名更易变的特性所做的决策，因此更频繁的验证至关重要。
在45天周期内，IP地址真的比域名更易变吗？租用VPS时获得的静态IP地址显然并非易变资源。
> 在45天周期内，IP地址比域名更易变吗？租用VPS时获得的静态IP就很稳定。
它们可以随心所欲地变动。例如在AWS上，弹性IP随时可释放。
假设我预留弹性IP后立即申请45天证书，随即释放该IP。通过反复操作，每次仅租用几分钟就释放，
最终将积累大量已过期的45天证书，对应的IP地址已被分配给其他用户。这意味着你可能持有他人IP的证书。
当然，这种漏洞虽不易被轻易利用，但仍构成潜在问题，违背了IP证书的初衷。
对于IP证书而言，短效期要求相当合理——IP地址常被租用且可能快速在用户间流转。例如在云服务商购买虚拟机后，释放该虚拟机或IP地址时，它可能立即分配给其他客户。此时你却持有该IP的有效证书。
这种情况下6天有效期实在太长！
云服务商可核查透明度列表，若发现IP存在有效证书，则将其隔离至证书失效。问题迎刃而解。
这等于白白损失收入，除非隔离期间继续向原租户收费。
在证书过期前持续收取IP费用对云服务商而言是坐收渔利。他们肯定乐意之至。
推动证书有效期越来越短的做法实在是个糟糕的主意，这表明参与这些计划的人根本不了解更广阔世界中的实际运作方式。
更广阔的世界指的是哪里？
这些变革源自CAB论坛，该论坛基本囊括了所有主流网页浏览器的发行方，以及所有在这些浏览器中提供受信任证书的机构。
确实存在超出该体系的证书应用场景，但这些场景本质上属于小众领域。
约99.99%的个人和组织既非CA机构也非浏览器厂商，因此在CAB论坛中毫无话语权。
恕我直言，这绝非“本质上属于小众领域”。
关键不在于投票权限集中，而在于决策者是否了解“更广阔世界”的运作方式。显然他们心知肚明——Chrome/Firefox的开发者和所有公共信任网站背后的CA运营商，都清楚自身产品的功能及应用场景。
他们只关注主流使用场景。那些边缘案例恐怕连他们的雷达都扫不到。
对电商领域固然完美，对其他领域却未必适用。
>这基本涵盖所有主流浏览器开发商，以及所有为这些浏览器提供受信任证书的机构。
所以实际需要续签证书的机构根本不在其中。
嘿！证书颁发机构的根证书有效期有多长？
10到25年？
为什么不能设成120分钟？它们可是负责整个互联网“安全”的机构啊？
有效期上限是15年。
另有人在评论中分享了Chrome团队的文档。
其中一段引文颇有意思：
“在Chrome根证书计划政策1.5版中，我们实施了变更，将Chrome根证书存储库中根CA证书的最大’有效期'(即包含周期)设定为15年。”
虽然我们仍倾向更灵活的策略，未来可能重新探讨此方案，但现阶段鼓励CA所有者探索更频繁的根证书轮换机制。
https://googlechrome.github.io/chromerootprogram/moving-forw…
很快就要满五年了。
> 因此实际上无人需要续签这些证书。
谷歌既维护Chrome浏览器又身处CAB体系，作为知名网站托管商(据我所知这是其主要收入来源)，其运营的网站确实使用HTTPS协议。
这几乎像是CA证书与叶证书面临着不同的威胁模型。
没错，根证书比叶证书敏感得多。
正因如此，根证书才存储在HSM中——它们构成严格定义的完整集合，若持有者违反任何管理规则，CAB便可吊销其资质。
开玩笑吧？你没见过服务器因证书续期问题彻底瘫痪吗？不少网站就是这么倒下的。它们明明只提供静态内容。缩短续期窗口根本是自找麻烦。
> 你开玩笑吧？你没见过服务器就因为证书续期问题彻底瘫痪的情况？
我没开玩笑，但你后面说的内容和我原话完全不搭边。
他们提供退款保证。而且还有其他SSL证书供应商可选。
无论好坏，证书有效期缩短至47天已是行业趋势，几年后所有供应商都将停止发放更长期限的证书。
不过域名持有者并非被迫使用6天有效期的证书，届时Let’s Encrypt也会像其他供应商一样默认采用47天周期。
难道你不觉得多年前人们也会说“当然能让安全证书有效期超过两个月”吗？
安全领域的创新者们未能开创真正的验证新方法，因此整个安全行业提升安全性的唯一手段就是缩短证书有效期。他们继续这么做完全合乎逻辑。
按交易签发ALPN证书。何必冒险？
> 不过没人强制要求域名使用6天证书
目前如此
也没人强制使用Let’s Encrypt。
这无关紧要。谷歌确保所有CA遵循相同规则。
现实世界中是如何操作的？
在你的回答中(且不考虑使用ACME的情况)：这是值得保留的良好行为，还是需要改进的拙劣做法？
缩短证书有效期是明智之举，因为这是应对私钥泄露的唯一有效手段。或许存在更优方案，但至今尚未被发现。
少数人统治，我们这些小人物无关紧要。
关键在于，没有任何东西能阻止任何人获取短期证书并“主动”轮换使用。这意味着——我们掌控着流程，除非你们照我们说的做，否则Chrome将不再支持你们的网站…
CA体系存在漏洞，短期证书无法弥补，所以趁我们重新摆弄甲板椅时，就让大家尽可能难受吧。
认真等待被点踩。
到头来，干脆让我们用自签名证书更合理。反正没人相信SSL能提供认证。
许多企业环境本就会加载根证书并实施中间人攻击
正因如此，大量应用程序都实现了证书绑定机制
此处“认证”指什么？Web PKI的本质是为网络资源提供一致性的加密身份，而非可信度。
(自签名证书的经典问题在于：TOFU机制无法扩展至数百万用户，尤其当用户不了解证书指纹或其变更含义时。)
那干脆彻底废除TLS算了。
传输加密依然必要。除集中式信任外，指纹检测等方法也能识别伪造证书。
尚未见过能支撑数十亿用户的此类系统。
这本质上也是安全表演。
不过容我戴上锡箔帽猜想：当前证书签名算法是否已被政府机构或黑客组织破解，导致他们能生成有效证书？
但若真如此，缩短证书有效期也无济于事。
我工作笔记本的浏览器信任了219个根证书。其中部分可能由雇主安装，但多数应来自微软——毕竟这是Windows 11上的Edge浏览器。列表里赫然列着“瑞典政府根证书颁发机构”、“泰国国家根证书颁发机构”、‘荷兰根证书颁发机构’，还有诸如“MULTICERT根证书颁发机构”、“ACCVRAUZ1”之类的条目。我认为没有任何理由信任这些证书。若政府需要为特定域名获取证书，他们必然能如愿——要么直接掌控受信任的根CA，要么向希望在其管辖区域开展业务的公司出示授权令，迫使该公司签发证书。
TLS证书的处理方式应更接近SSH主机密钥在已知主机文件中的机制。浏览器应在首次遇到证书时记录其信息，若证书在有效期内或临近到期时发生变更，则应向用户发出警告。
证书透明机制实质意味着：任何政府若在公共网络使用伪造证书，其根证书都将被撤销。
当然你仍可能成为此类计划的首个受害者…但总体而言，当前CA机构已不再真正值得信赖——真正的信任根基在于CT日志。
> 证书透明度机制意味着，若任何政府在公共网络中使用虚假证书，其根证书将被吊销。
本地证书采用短有效期的根本原因在于：技术界尚未解决大规模证书吊销的可行性。
若使用最新浏览器或许尚可应对，但所有嵌入式设备仅在软件更新时才更新根CA，这意味着一旦CA遭入侵，可能轻易控制数十万台设备。
> 设备证书采用短有效期的根本原因在于，尚未解决大规模撤销机制的实现问题。
而200天远非“大规模”。撤销根证书面临的困难清单与你所指问题截然不同。
> 任何嵌入式设备
确实存在缺陷，但比起此前毫无手段检测过多CA机构失控的情况，这已是巨大进步。
>> TLS证书的处理方式应更接近SSH主机密钥在known_hosts文件中的机制。浏览器首次遇到证书时应记录其特征，若在有效期内或临近到期时发生变更，则应发出警告。
这个建议非常棒，确实具有建设性！
我使用自己编写的工具http://www.jofla.net/php__/CertChecker/，通过JSON格式维护多台机器(含HTTPS和SSH)的列表，记录其最新指纹及检测日期。每次运行时，我都能立即察觉服务器是否发生变更，这相当于对异常情况的预警机制。当然它存在局限性——无法模拟头部信息等细节，但作为起步方案已足够实用。
如果所有浏览器都能采用某种分布式协议(比如DHT)，至少能就“该证书是否被我或足够多的对等节点近期验证过”达成共识，那就太棒了。
拥有海量CA机构，且允许证书链中任意环节为任意网站背书，这种机制简直疯狂。除非亲眼目睹滥用案例，否则人们总会默认其基础架构是可靠的。
> 被某些政府机构或黑客组织破坏
可能性不大。浏览器要接受该证书，必须将其记录在证书透明日志中供所有人查阅，而目前尚未发现此类证书被记录的案例。
短效证书的设计理念之一，是将证书有效期控制在CRL(证书撤销列表)的有效性范围内——毕竟CRL本身难以扩展，且是CA机构面临的重要运维挑战。
从安全角度看这有其合理性，前提是你认同“撤销操作必须及时生效”这一基本原则。
我不确定这是否关乎安全性。安全性方面，CRL和OCSP自始便存在。短效证书能取消CRL或至少缩减其规模，从而为CA节省开支(毕竟每个客户端下载整个Let’s Encrypt的CRL会产生相当大的流量)。
这与其说是IP地址的临时性问题，不如说是IP地址控制权问题。网站或服务运营商很少能控制IP地址，此举旨在限制CA的风险。
在45天窗口期内，IP地址比域名更易变动吗？
若我未为EC2实例分配弹性IP(EIP)就直接关闭实例，即使在关闭完成后几秒内重启，也几乎肯定会获得不同IP地址。
但要利用这种特性实施恶意攻击相当困难。你需要恰好分配到他人近期使用的IP地址，且该IP使用者必须同时满足：使用IP地址证书的TLS协议，或禁用了证书验证功能。
明白了，但若遇到这种情况，IP证书是否是正确解决方案？
若涉及你控制的客户端，这可能并非理想方案。
反之，若处理浏览器请求，它们更青睐WebPKI证书。况且实时将负载导向特定服务器时，何必在中间添加DNS或负载均衡器？
> 若发生意外(如触发Certbot的管道出错)，我将无暇修复。这意味着证书续期周期为两天，且存在四天的“调试窗口期”。
对于六天有效期的证书，我认为以下模式较为合理：
– 每两天续期一次，设置“4天调试窗口期”- 每天续期一次，设置“5天调试窗口期”
监控方案参考：https://letsencrypt.org/docs/monitoring-options/
这让我思考：我在https://heyoncall.com/blog/barebone-scripts-to-check-ssl-cer…发布的脚本是否应将过期阈值定义为小时单位而非整日？
您应该更频繁地运行证书续期管道：若让ACME客户端在单服务器上自动配置，90天有效期的证书可能每12小时才触发续期。ACME客户端不会在旧证书达到续期价值前发放新证书，相比仅在预期接收新证书时运行管道，您有更多机会发现管道运行异常。
若你在商业场景中操作，且4天的调试窗口期(或任何停机时间)造成的损失，超过从商业供应商购买一年期证书的成本，那么这或许就是你的答案…
几年后，所有浏览器中的证书有效期都将不超过45天。
比起推动缩短证书有效期，我更担忧的是当前证书撤销机制的缺陷——若证书供应商突然失效，您几乎没有时间切换至新供应商。
这是双向解决方案，缩短证书有效期的重要意义之一正是提升证书撤销机制的有效性。
部分ACME客户端能在主提供商失效时自动切换至备用提供商，只要预先配置好备用方案，就无需临时手动干预。
人们尝试过。在如此规模下解决证书吊销问题极其困难。
>我没时间修复这个
这反而应推动你实现流程自动化。
他明确指的是自动化机制失效的情况。
你可以用自动化来修复失效的自动化。
你认真的吗？认真的问
是的，随着有效期缩短，人们会增加自动化和健壮性来应对。提升健壮性的一种方式是自动诊断故障原因并尝试修复。
IP地址必须可从互联网访问，因此在不进行手动配置或激怒安全研究人员的情况下，仍无法为局域网设备支持TLS。
我最近为整个家庭网络迁移到通配符证书(*.home.example.com)。多数场景运行良好。但需使用支持API设置TXT记录的公共DNS服务器(乐高开箱即支持若干DNS提供商，详见https://go-acme.github.io/lego/dns/)
我使用的服务商相当小众(https://go-acme.github.io/lego/dns/zonomi/index.html)，但它支持此功能——我甚至认为他们能兼容大多数服务商
最近发现这个，或许能帮到这里的人。绝妙方案。https://sslip.io/
若需为非公共IP配置证书，应建立非公共证书颁发机构并自行签发证书。
这种场景下也可使用私有CA。
完全正确——你觉得LetsEncrypt会愿意为多少个192.168.0.1签发证书？
自2015年起，BR条款明确禁止签发此类证书。这发生在他们被迫停止使用SHA-1之前，也稍晚于禁止签发诸如*.com或*.ac.uk这类荒谬证书的禁令——这些域名显然不应向任何人开放，即便他们坚称自己“拥有”这些名称。
现无法编辑，但该评论应指明*.com或*.ac.uk——即后缀为完整顶级域名或完整“公共后缀”的通配符。规则明确规定此类后缀不应被单方独占，而应由无关方共享，因此此类通配符的存在本身就不合理。
IPv6？你甚至无需将实际终端暴露在开放互联网中。在边缘节点实施DNAT，将入站流量导向负责证书续期的虚拟机，再分发给实际使用这些地址的局域网设备。
>所以局域网设备要支持TLS，要么手动配置，要么惹恼安全研究人员，依然没有其他办法。
可以说配置Let’s Encrypt就是“手动设置”。可行的方案是在局域网内部署可互联网路由的顶级域名DNS分区配置，同时为内部设备运行CA。这样所有内部主机都能获得带HTTPS的hostname.sub.domain.tld域名。
坦白说：这工作量其实没大多少，而且总比记住IP地址容易。
> 运行CA
> 比记住IP地址更简单
我不知道，192.168.0这个部分已经存在很久了。其余的只是细节问题，比如我的笔记本用.12，电视机后面的那台用.13，树莓派用.14等等。
每次我试图“运行CA”时，就会开始吹毛求疵。
不，我的意思是：
1. 运行CA比为IP地址配置certbot更费事，但差别不大
这样就能实现：
2. 只需记住域名，比IP地址更简单。
若仅使用IPv4且规模较小，效益有限；但若拥有大型或桥接网络(如wonderLAN或promised LAN)，则优势显著。
私有网络设备也可采用DNS-01验证机制。
我的意思是：若设备不可路由，如何确保验证过程的唯一性？直接创建域名即可。
另外我不明白TLS在此场景的价值？既然你我(及所有人)都能合法获取10.0.0.1的证书，那么相较于自签名证书，TLS究竟能证明什么？
根本无法区分我连接的是my-organisation的10.0.0.1还是bad-org的10.0.0.1。
或许能在URL中添加标识符？
例如：https://10.0.0.1(af81afa8394fd7aa)/index.htm
该标识符由证书颁发机构在首次申请证书时生成，后续续期时可沿用相同标识符。
我明白你的意思——但对我来说这几乎等同于直接使用DNS，即使你设定的(A/AAAA)记录解析到不可路由地址：https://letsencrypt.org/docs/challenge-types/#dns-01-challen…——你只需创建DNS TXT记录，而非让验证程序尝试访问该地址对应的服务器。
这假设使用了NAT，而IPv6理论上应能实现全局唯一IP地址。(当然，这并非IPv6独有特性，但现实中如今几乎没人给局域网设备分配公共IPv4地址了)。
公共CA不会为10.0.0.1签发证书
完全正确——无人能证明其所有权(因该地址专用于私有网络而刻意保留，故无人能拥有)
对于IPv6，所有权验证可通过出站连接轻松实现。这对于仅面向内部服务的证书配置效果极佳。
所谓“局域网”指什么？IPv6十年前就该实现全球路由了/s
这很有意思，我猜IP地址证书的用例是让临时服务也能进行TLS通信——现在无需再依赖域名服务器记录分配，就能为可能启动数百上千个、仅存活一小时或一天的服务提供支持。
此技术可用于加密客户端初始化(ECH)，实现TLS/HTTPS通信时无需向监听设备暴露服务器名称(标准SNI名称以明文传输)。
使用时需具备连接服务器的有效证书，且该证书的主机名需以可读形式广播。对于Cloudflare、Azure和Google这类企业并非难题，因其可直接使用代理名称。
但小型站点通常仅托管一两个域名，几乎找不到非重复的主机名。
采用IP证书方案时，外层TLS连接可在可读SNI字段中使用IP地址，同时对实际连接的主机名进行加密传输。这意味着无需作为第三方代理转发他人内容，ECH机制即可发挥实际效用。
此方案不可行，因SNI及ECHConfig的server_name字段均禁止包含IP地址：https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.html#…
即便该功能有效，隐藏SNI对仅托管少量域名的IP地址而言隐私价值也微乎其微——众多数据库可通过IP地址查询对应域名，例如： https://bgp.tools/prefix/18.220.0.0/14#dns
无论如何，我认为自建网站采用ECHO协议并无实际价值。该方案适用于Cloudflare等服务商，因其IP地址背后承载着数百万无关联域名，连接至其IP地址几乎无法透露任何信息。但若您的IP仅用于少量关联服务，即便隐藏SNI字段，实际用途仍显而易见。
据我所知，根据https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.txt规范，不能将IP地址用作外层证书。
> 在验证面向客户端的服务器证书时，客户端必须将公共名称解释为基于DNS的引用标识[RFC6125]。将DNS名称和IP地址纳入相同语法的客户端(例如[RFC3986]第7.4节和[WHATWG-IPV4])必须拒绝会被解释为IPv4地址的名称。
7月发布的IP地址证书公告列举了若干潜在用例：https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr…
感谢分享！这篇内容很有参考价值。
不依赖注册商听起来不错。更具匿名性。
> 不依赖注册商听起来不错。
实际上核心优势在于摆脱对DNS(直接DNS和根DNS)的依赖。
IP本质是简单的基本单元，即“是否可路由？”。
流行的HTTP验证方法无论使用DNS还是IP证书都存在相同缺陷？即：若能篡改路由劫持流量，同样能劫持验证请求。对吗？
确实存在此类案例(https://notes.valdikss.org.ru/jabber.ru-mitm/)，但这已涉及更深层的
-
路由信息安全防护：有人主张采用RPKI，也有人认为这尚不充分，正尝试SCION等方案(https://docs.scion.org/en/latest/)
-
委托代理问题：jabber.ru遭劫持事件(据推测)源于德国执法机构依据《德国电信法》(TKG)赋予的权力，迫使Hetzner实施了劫持
> 有人提倡采用RPKI
RPKI的问题之一在于其全面部署耗时较长。虽不及IPv6那般缓慢，但仍低于预期速度。
若能实现100%覆盖，RPKI将发挥显著成效。
IP地址同样由注册管理机构分配(例如北美地区的ARIN)。
> IP地址同样由注册管理机构分配(例如北美地区的ARIN)。
严格来说，ARIN等机构属于注册管理机构。
注册商则是您的ISP、云服务商等实体。
您可通过赞助注册商协助获取PI(提供商独立)地址分配，这是一种无需成为注册商即可绕过中间环节的折中方案。
您也可以自行成为注册商——至少RIPE允许这样做。但费用会大幅增加，除非您实际向客户提供ISP服务(这种情况下必须注册商身份，否则不得使用PI分配)，否则这样做的意义并不明确。
> 且其必要性尚不明确
现代环境下最重要的理由是能直接更新RPKI条目。
但这仅对需要直接访问权限的操作场景有价值。
若您的配置属于“设置后无需干预”类型，则应接受通过赞助商提交工单更新RPKI的延迟成本。
可以说两者都不算特别安全，但既然必须拥有IP地址，只信任其中一方似乎更合理。
确实，对于非面向用户的场景，不依赖域名服务器似乎相当实用。
> 我猜IP地址证书的用例是让临时服务能进行TLS通信
还有个叫DNS over TLS和DNS over HTTPS的小玩意儿，你可能听说过？;)
不太明白这之间的关联？
当前配置TLS/HTTPS DNS时，必须同时设置用于保护服务的安全证书的IP地址和主机名。获取IP地址证书能简化配置流程
> 我不太明白这有什么关联？
呃？难道我还要明说吗？我指的就是除了那些被猜测的“临时服务”之外，还有更多能利用IP证书的场景啊？
也许你想用TLS，但为项目申请正规子域名却要和一群办事拖沓的人周旋？
确实如此，从未考虑过这类组织架构。但我不认为应该把这当作临时补丁。若想让域名与服务关联，组织层面就需要建立配套系统来简化流程。
理想状态下当然如此。但在某些环境里，你提议的做法无异于为煮一杯茶而煮沸整个海洋
VBA等工具之所以成功，正是因为它们让员工能突破组织层面的阻碍推进工作
此外——未能预见这类需求，或许正暴露了你的视野盲区。当外界指责硅谷活在高科技象牙塔里，对普通民众的现实视而不见时，说的就是这种事。
兄弟，我可不是硅谷人哈哈。我只是不为大型机构工作罢了。
强制使用短期证书简直糟透了。
现在你所有想联网的资产都将被美国实体定期掌控。这简直比定期报平安还频繁。若想自建本地证书颁发机构作为子CA，除非经历噩梦般的持续更新分发流程，否则根本无法管理。
从安全角度看，这意味着所有设备都将产生近乎持续的外部流量：读写服务器用于覆盖证书，密钥为此四处散布…
或许我漏了什么，但IP地址证书在安全性方面难道不是噩梦吗？
比如使用移动网络或大学网络这类公共网络时，截取多个无关实体共享IP的证书岂不是轻而易举？不是吗？
我不明白既然DNS A记录更新如此简单廉价，为何还要IP证书？这是否意味着需要同时部署两种方案，如同配置SPF/DKMS/DMARC那样？
对此非常期待。IP证书能解决自建/独立托管软件的启动难题——这类软件虽提供域名配置面板，但用户必须先获取证书才能安全访问面板。
具体来说，我可能就能关闭TakingNames[0]的引导域名功能。
[0]: https://takingnames.io/blog/instant-subdomains
是否有人真正给出过关于为何移除TLS客户端认证的合理解释？
这是Chrome根证书计划的要求。这篇文档可能是解释其动机的最佳资源：https://googlechrome.github.io/chromerootprogram/moving-forw…
我理解Chrome拒绝该功能的原因(这不符合Chrome的利益)，但这无法解释Let’s Encrypt为何必须移除它。真正原因似乎是“作为Chrome的CA，必须完全遵从Chrome的要求——而Chrome的要求就是…只做Chrome想做的事”。换言之，CA机构已被Chrome彻底掌控，沦为Chrome的权威机构。
难道只有我觉得这太疯狂了吗？整个网络安全现在都取决于谷歌的喜好了？
所有主流根证书存储程序(Chrome、苹果、微软、Mozilla)都拥有这种权力。它们设定CA必须遵守的要求才能被纳入根证书存储库，而对大多数CA而言，若未能被所有主流存储库收录，其证书将失去价值。
我认为根证书管理程序不会轻率做出这类决定，也未见其存在任何私心。它们需要在两者间寻求平衡：既不能给网站运营商和CA机构增加过多复杂性(必须保持可靠性)，又需保障终端用户安全。
许多CA和网站运营商都希望现状永不改变：不禁止不安全的签名/哈希算法、证书有效期超过五年、手动续期、不采用证书透明(CT)和多路径验证(MPIC)等。因此必须由其他力量推动改进。
根证书计划推动的变革并非不合理，所以我并不担心它们对CA的掌控力。
这并不意味着短期内变革不会带来阵痛。例如，证书有效期缩短至45天将导致部分服务中断，但根证书计划/浏览器厂商显然不会从中获益。他们坚持推进变革，是因为坚信这将使WebPKI在长期发展中更具韧性。
此外还有CA/浏览器论坛负责规则修订的讨论与投票。我不清楚根证书程序如何区分哪些内容应纳入自身根策略，哪些应争取纳入基准要求。或许此次Chrome认为太多CA会出于自身利益投反对票，但这只是推测。
“客户端证书”要求之所以未纳入CABF规则，正是因为该规则将排除所有遵守规则的机构——其适用范围远超Chrome内置CA范围。
部分CA将继续运行支持客户端证书的PKI系统，供Chrome外部环境使用。
总体而言，“基准要求”的初衷正是建立共享基准，要求所有机构共同遵守。当前所有主流根证书计划均设有各自独特的专属要求。
感谢参与讨论！我记得您在LE社区论坛也提过这点。
原来如此，这解释通了。那么这类证书适用于非网站场景，或是无需支持Chrome(且需要客户端认证)的网站？
我难以理解这种场景，因为从未接触过需要同时使用此机制和公共信任证书的应用。但既然有人为此投票推动纳入基础要求，想必这类场景确实存在。
若您或其他朋友了解相关用例，希望能分享细节以便深入理解。
原因之一在于：带有id-kp-clientAuth EKU和dNSName SAN的客户端证书并不能真正验证客户端的FQDN。要实现验证，必须在应用层进行某种回程路由性检查——即服务器通过解析客户端FQDN来确认其身份，确保与另一端连接的客户端一致。我不确定该如何看待这个抱怨，但确实值得注意。
因为谷歌不希望任何人将PKI用于简单网站之外的场景
因为使用公钥基础设施进行客户端证书认证简直糟糕透顶
mTLS可能是私钥基础设施唯一合理的应用场景
它与“使用谷歌登录”单点登录功能存在竞争关系
IP地址证书有何用处？
* DoT/DoH协议
* 执行ECH时作为外层SNI名称
* 无需依赖域名注册商即可托管安全HTTP/邮件等服务
为省去他人查阅Kagi的麻烦：DoT/DoH = 基于TLS的DNS[1]/HTTPS[2]
例如：
[1] https://developers.cloudflare.com/1.1.1.1/encryption/dns-ove…
[2] https://developers.cloudflare.com/1.1.1.1/encryption/dns-ove…
IP地址在ECH使用的SNI中无效，即使启用TLS也是如此。不过理论上我认同，若未来规范变更，这确实是个不错的方案。
我认为这更像是替代方案而非可行的未来方向。
ECH要求外部(未加密)SNI作为目标地址时需具备一定可信度。对于ECH GREASE方案，外层SNI真实有效，而看似加密的内层ECH数据实为随机噪声。
对于非GREASE ECH方案，我们需尽可能模拟GREASE特征——但关键区别在于：内层并非噪声，而是包含真实SNI等信息的加密有效载荷。
哦不错！我之前没考虑过DoT/DoH方案。ECH的角度很有意思。谢谢。
如果能使用DHCP分配的IP，是否意味着本地开发时可以不再使用自签名证书？
不行，他们只会向能证明IP所有权的用户发放证书，这意味着该IP必须具备公共路由能力。
终于有理由在本地开发中采用IPv6了
没错，请务必将开发服务器的地理位置公布在证书透明度日志中供所有人查看。
很多公开路由的IP地址都是通过DHCP分配的…
这本质是控制权问题而非所有权吧？我无法证明分配给我的IP所有权，但能证明控制权。
没错
抱歉，我之前表述不够精准。我在大学里，我们的IP地址应该是公开可路由的。
用谷歌搜索“我的IP是什么”，然后和DHCP分配的地址对比。如果不同，说明你的DHCP地址不可公开路由。
浏览器将“localhost”视为安全上下文，无需HTTPS
本地/网络开发或许可行，但你可能需要在路由器上进行复杂的发夹式网络配置。
若涉及HTTP/2相关操作，本地使用HTTPS会更便捷。
何不创建“localhost.mydomain.com”的DNS记录？初始解析为公网IP获取证书后，将证书复制到本地，再将DNS指向127.0.0.1？
除了纯粹麻烦之外。
这种场景下也可采用DNS-01验证方式。
我的理解正确吗：是否有人能提供具体示例？即同时包含IP地址和HTTPS协议、且可从全球互联网访问的URL？例如https://<ipv4-address>/？
通过IP访问的DNS服务器网站？https://1.1.1.1/虽会重定向，但展示了有效证书。
好奇问下：是否有不重定向的例子？即浏览器地址栏始终显示https://<ip>？
对于普通企业(如电商或SaaS初创公司)，IP地址证书有哪些实用场景？
互联网属于终端用户 https://datatracker.ietf.org/doc/html/rfc8890
>成功的规范将为所有相关方带来益处，因为标准制定并非零和博弈。但有时会出现两方(或多方)需求冲突的情况。
>当其中一方是互联网“终端用户”——例如使用网页浏览器、邮件客户端或其他联网代理的个人时——互联网架构委员会主张IETF应优先保障其利益而非其他方。
法人实体仅属次级用户。
能否详细说明您的回答背景？我无法将其与原帖或我的任何表述关联起来。
我试图说明人类对此有实际需求，这本身就足够了。即便盈利性用途并不多。
我作为人类，关心的是如何将此技术应用于个人项目。请别再将我非人化了。
这条评论原先标注仅处于测试阶段。(忽略，我误跟了原文链接导致混淆)
这篇旧文内容似乎已过时。
IP证书可能不会用于重要场景，但BGP劫持带来的风险难道不更严重吗？
我认为风险并无增加。若能劫持我的服务IP，攻击者本就能控制指向这些IP的域名或IP本身。(若能劫持我的DNS服务器IP，往往能实施更严重的攻击…即便启用DNSSEC，仍可持续返回指向劫持IP的解析记录)
这听起来像是件好事，就像Let’s Encrypt推出的许多功能一样。
但如此短的更新周期会带来哪些风险？
证书链顶端是否存在能在眨眼间拒绝签发后续证书的机构？
若存在，是否意味着所有相关证书将在6天内集体失效，如同大规模拒绝服务攻击？
届时所有人是否将被迫回归HTTP协议？
或许熟悉证书链机制的专家能为我解惑。
6天有效期的证书通常会在第3天续期。若Let’s Encrypt服务中断或拒绝签发，则需更换证书供应商。浏览器默认信任众多“证书链顶层”供应商。
采用30天有效期证书并提前10-15天续期，能提供充足缓冲空间
个人认为3天周期过于短促，除非通过自动化系统从两个供应商同步获取证书。
感谢指正，我之前忽略了多个“根证书供应商”的存在。因此必须所有供应商同时瘫痪才会导致系统彻底失效。
Let’s Encrypt使用了多少家“顶级证书供应商”？这是否构成单点故障风险？
我推测其他“顶级供应商”会收取证书费用，且可能采用人工流程导致效率低于Let’s Encrypt？
LE拥有两个主要生产数据中心：https://letsencrypt.status.io/
但ACME协议的核心价值之一正是消除对单一供应商的依赖，避免供应商锁定。理想情况下，ACME客户端应支持多个ACME证书颁发机构。
例如Caddy默认同时支持LE和ZeroSSL，用户还可额外配置Google Trust Services等其他CA。
本文档探讨了需考虑的多种故障模式： https://github.com/https-dev/docs/blob/master/acme-ops.md#if…
“这是否构成单点故障？”
视情况而定。若ACME客户端配置为仅使用Let’s Encrypt，则答案为肯定。但若客户端可回退至谷歌CA、ZeroSSL等替代方案，则不存在单点故障。
有道理。我猜这些机构都受美国总统控制？
目前多数免费CA机构在美国设有重要据点，并雇佣大量美国员工。
不过ZeroSSL/HID Global似乎是跨国企业，其母公司瑞典亚萨合莱集团(Assa Abloy)具有多元化背景。
若美国局势真的恶化，这些机构采取了哪些应对措施？这确实是个值得探讨的问题。
本质上微软、谷歌和苹果均由居住在美国的美国公民运营，火狐的情况也大同小异。
美国拥有强大的制度保障，防止总统或政府随意干预这些企业。若这些制度失效，它们完全可能发布更新，移除除美国政府批准之外的所有“根证书链顶端”受信任证书颁发机构。
届时当前互联网体系将彻底崩溃，操作系统本身也将失去可信赖性。
修复SSL问题反而是容易的——自由世界会自行发布根证书，用户只需从可信来源手动安装即可。但这与真正的危机相比根本不算什么。
诚然Ubuntu、Suse等系统不在美国运营，但搭载非美国操作系统的手机数量近乎为零。你只能从零开始开发安卓分叉版本，而该版本很可能仍存在美国国家安全局批准的后门。非Linux设备也需彻底清除。
> 说得通。我猜这些机构都受美国总统摆布？
绝非如此。
若总统强迫美国CA机构执行违背其意愿的恶意指令，他们会起诉政府。迄今为止，本届政府面临的诉讼败诉率高达80%。
你对美国机构(法院等)抱有过高信任。世界其他地区正逐渐意识到，这些机构已不再像过去那样强大独立。
更不用说更明显的问题了。微软/谷歌等公司可以起诉阻止美国政府命令他们做他们应该做的事。首席执行官真的愿意为此冒险吗？如果他们的孩子遭遇交通事故，那将是一场巨大的悲剧。
他们无法控制美国总统。
我确信美国随时可以关闭.org顶级域名。
Let’s Encrypt并不掌控美国总统。
但有人会说，掌权的“唐纳德”实际上控制着Let’s Encrypt
是啊，这想法有点牵强，但自从Cloudflare CEO基本威胁要切断意大利的网络后，我就好奇如果美国真的入侵格陵兰岛会怎样。
单纯从Windows迁移到Linux是不够的。如果证书过期后无法更新，要么得手动逐台更换根证书，要么得有其他应急方案。
需知全球存在大量CA机构，其中不少总部设在美国境外。这些CA机构目前虽未提供免费ACME服务，但没有任何因素能阻止它们未来这样做。
我认为WebPKI体系展现出极强的韧性，即便面对严峻的地缘政治紧张局势亦是如此。
Windows(及苹果、谷歌、Mozilla)信任数十个根证书。我笔记本电脑的/etc/ssl/certs目录里存有148个pem文件，其中59个来自美国，意味着89个来自其他国家。中国有10个，德国9个，英国7个，其余来自印度、日本、韩国等国。
更严重的问题在于美国政府强迫微软/苹果/谷歌推送系统更新，移除所有未经美国政府批准的CA证书。
Canonical/Suse或许能抵御这种公开施压，但一旦走到那一步，你早已远离国际互联网的边界，届时一切都无关紧要了。
> 你或许会说掌管美国的“教父”控制着Let’s Encrypt
他既不掌控Let’s Encrypt，也不掌控任何美国CA机构。
鲜为人知的是，特朗普政府在企业、城市及州政府提起的诉讼中败诉率高达80%。
美国企业面临国家支持的网络攻击风险更大。
这无关紧要。只要验证通过，这些CA机构很乐意给你签发.se/.dk/.in/任何后缀的证书。
我希望如此，但这种情境下.se或.de域名还能正常运作吗？顶级域名根管理是否真正实现垂直分权？还是说(据推测位于美国的)顶级域名母机构仍是各国域名的最终裁决者？
至少制定高层次应急预案是必要的，毕竟最坏情况下我连谷歌都用不了。
不太明白具体担忧点。目前地球上几乎所有国家仍在DNS中存在，比如委内瑞拉、伊朗、索马里等等。
无数网站上也能看到大量反特朗普的文章和评论，既有.com域名也有其他顶级域名。特朗普再疯狂，也没封杀这些声音。
“顶级域名根管理是否真实现了垂直分割？”
据我所知，确实如此。
但若全球DNS系统崩溃，要么另寻替代根服务器集群，要么绕开常规互联网通信。此类事件必将重创全球经济。
这确实是个关键问题，之前完全忽略了。
全球DNS服务器分布于世界各地。多数由美国运营，但瑞典、日本和荷兰各运营三台。
多数用户使用自有ISP或美国公司(Cloudflare、Google、OpenDNS)的任播地址。Quad9属于欧洲运营商。
然而根DNS服务器的任何分裂都意味着互联全球网络的终结。任何ISP都能在其网络内发布任播地址，因此美国若被全球隔离本身并非问题，但西方世界互联网的崩溃将引发巨大经济冲击。
不过若未来一二十年发生这种情况，我也不会感到意外。
Let’s Encrypt 是我心中的英雄
有人知道 Caddy 计划何时支持这项功能吗？
我们已支持该功能约一年！
太棒了，感谢各位！
https://caddy.community/t/doubt-about-the-new-lets-encrypt-c…
说实话，在动态IP环境下我不太喜欢IP地址证书
关于基于IP地址的6天有效令牌机制，这让我再次质疑：为何要在完全错误的TOFU认证上浪费如此多时间？
若需建立可验证身份，我认为可通过DNSSEC追溯至域名注册商获取名称信息，并(我不太确定具体机制)追溯至AS获取IP地址。
域名与注册商呈一对一映射，但多个AS可能使用相同IP地址。
若缺乏对BGP的实时洞察就签发IP证书，将是重大失误。(或者说无论采用何种链路都无关紧要… 但通过抽样地点访问网站绝非更优解。)
>在缺乏对BGP的实时洞察时签发IP证书将构成重大错误
为何？常规证书不也通过IP地址签发吗？
为什么我们要浪费大量时间在完全错误的TOFU认证上？如果需要建立可验证的身份，我认为应该通过DNSSEC追溯到注册商。
他们废除了曾经可接受的验证机制。如果要求真正的信任链会怎样？他们废弃HTTP协议，域名却仍能在DNS/DNSSEC上运行。
仅用HTTP验证机制来构建IP是倒退的做法。
这要求虽高，但我仍期待他们终有一天能推出代码签名证书——即便收费也值得。若应用商店能直接接受此类证书，而非强制要求开发者验证，那将极大便利开发者。
-
无论好坏，代码签名证书都需附带一定程度的组织验证。没人会信任域名验证型代码签名证书，尤其当其完全由系统自动签发时。
-
应用商店审核应用旨在验证功能合规性，而非走形式。代码签名证书对此毫无保障作用。
他们完全可以采用身份验证替代域名验证，无论是内部处理还是外包。
我讨论的重点并非应用商店审核，而是无需向应用商店验证身份，直接使用跨平台通用签名证书。此外，开发签名版Windows应用的成本将大幅降低——当前需花费数百美元。
Azure提供“Artifact Signing”服务，每月10美元即可签名Windows可执行文件(不适用于无需签名的Windows商店应用)。
这个价格相当合理，毕竟该功能已集成到所有主流Windows代码签名工具中，它们负责身份验证，私钥则由Azure全程托管。代码签名证书必须存储在HSM硬件安全模块中，因此你很可能需要支付云CA服务费用。
太棒了，非常感谢！！我为此成本困扰很久了！！为什么这种方案不更广为人知？我调研过很多，即使选择最便宜的供应商，三年成本也至少要500美元。让我看看我的具体用例是否适用。
欠你一个人情 @briHass 🙂
当二进制签名成为常态后，这种方案确实很有价值。若仅作为域名绑定机制，恐怕连反对声都不会有。
但试图降低该系统实用门槛的行为，本质上是在通用计算领域战役中做出让步。补贴其成本等同于主动放弃那条非道德层面的辩护立场。
我不明白争论点何在。能发布他人可验证并信任的内容，在我看来是巨大进步。甚至不明白为何要局限于代码——本质只是验证签名者身份。当我们信任所建基础时，更可靠的系统和更多进步自然随之而来。我不认为这是对通用计算的战争。我感觉存在一种陈旧思维，将不安全性视为某种权利——做不安全之事应是你的权利，但让大量人群被迫使用不安全产品，这恰恰是针对通用计算的战争。
若不考量技术所助长的权力结构，便无法对其进行规范性评估。
以安全启动为例：假设其正确实施，可防御整类攻击——恶意女仆攻击：当第三方在你离场时物理入侵设备植入恶意软件，系统将发出警报或阻止启动篡改后的镜像。这是技术层面的陈述。但问题在于：究竟由谁的密钥来签署这些镜像？答案取决于供应链中的主导力量：桌面设备由微软掌控，移动设备则由厂商把持。
微软案例中，公众舆论最终迫使其开放该系统，允许高级用户自主委托代理人，摆脱制造商的强制控制。但安卓系统呢？在自然市场力量占据上风的领域：多数手机仍禁止禁用安全启动功能，更少设备允许用户注册自有密钥。其结果是：多数安卓手机在出厂数年后便停止安全更新，厂商自有软件漏洞百出(例如在用户无法访问的分区中填充永不清除的日志，即便恢复出厂设置也无法消除)，且存在已知的CVE漏洞，却仍被谷歌认定为可用于银行等高保障应用的安全设备。这种虚伪并非偶然：该系统的真正目的并非保障用户安全，而是维护其垄断地位——通过特权化的谷歌Play服务实现，其数据采集能力远超任何SDK所能企及。
我自己经常依赖认证机制——我的手机运行Graphene操作系统，笔记本电脑通过自签名内核实现安全启动——但我清楚这些技术本身容易被反竞争企业与压迫性政权滥用。
试想若政府身份认证的APP签名成为应用商店的标准，开源工具将不复存在：科学计算器、笔记应用、 预算规划工具等开源实用程序将不复存在，因其无法承担实质上属于志愿工作的认证费用。取而代之的将是软件血汗工厂批量生产的广告泛滥山寨品，它们与各类恶意软件并列展示，或通过恶意广告引导用户下载——这些恶意软件依然如故地猖獗，仅凭街头随机路人的护照信息签名，且下架时间被尽可能拖延，因为谷歌正从反复的发布商验证和AdSense广告位中获取稳定收入。更遑论那些规避审查的工具及其他政治上不便的软件。
这想法很酷。但既然是非营利组织，就需要找到可扩展的实现方式。
将身份验证外包给可信合作伙伴并无不妥。或者通过收取1美元验证支付卡控制权，再结合纸质邮件验证码进行地址验证。
发表回复