Let’s Encrypt 证书即将变更
2027年，我们将把默认证书有效期降至64天，2028年进一步缩短至45天。完整时间表及详情请参阅我们关于缩短证书有效期至45天的公告
Let’s Encrypt 将对签发的证书进行多项更新，包括引入新根证书、停用 TLS 客户端认证以及缩短证书有效期。为实现渐进式变更，我们将通过 ACME 配置文件 使用户能够自主控制部分变更的生效时间。大多数用户无需采取任何行动。
Let’s Encrypt已生成两个新根证书颁发机构(CA)及六个新中间CA，统称为“Y代”证书体系。这些证书已通过现有“X代”根证书X1和X2进行交叉签名，因此在当前根证书受信任的环境中仍可正常使用。
除非用户主动选择其他配置文件，否则多数用户获取的证书均来自默认的经典配置文件。该配置文件将于2026年5月13日切换至新一代Y级证书体系。由于即将实施的根证书计划要求，这些新中间证书不包含“TLS客户端认证”扩展密钥用途。我们此前已宣布计划自2026年2月起终止TLS客户端认证，该时间节点将与切换至Generation Y证书体系同步。遇到问题或需延长过渡期的用户，可继续使用我们的tlsclient配置文件至2026年5月，该配置文件也将保留在现有Generation X根证书中。
若您申请的是tlsserver或shortlived配置文件证书，本周起将开始收到源自Y代证书体系的证书。此次切换同时标志着Let’s Encrypt短期证书的正式开放申请，包括对证书中IP地址的支持。
我们同时公布了遵循CA/浏览器论坛基准要求变更的时间表，该要求将迫使我们缩短证书有效期。明年您可通过tlsserver配置文件为早期采用者和测试环境选择45天有效期证书。2027年，我们将把默认证书有效期降至64天，2028年进一步缩短至45天。完整时间表及详情请参阅我们关于缩短证书有效期至45天的公告。
多数用户无需采取行动，但建议查阅各变更公告的关联博文以获取详细信息。如有疑问，欢迎随时在本论坛提出。
本文文字及图片出自 Upcoming Changes to Let’s Encrypt Certificates
此非LE的决定：47天上限是由CA/浏览器论坛投票通过的。
https://www.digicert.com/blog/tls-certificate-lifetimes-will…
https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch…
https://groups.google.com/a/groups.cabforum.org/g/servercert… – 所有成员的公开投票结果均为赞成或弃权。
我认为这项政策变更可能导致互联网崩溃，因为许多使用旧式证书的存档/遗留网站可能无力承担从年度续期转向实质上每月续期的前期技术投入或持续人力成本，最终只能被迫关闭。
此外，正如其他评论所述，这将使LE成为唯一可行的现代化方案，从而形成比以往更严重的单点故障风险。
但Let’s Encrypt对此决策不负责任，且未参与投票。
这将使ACME成为唯一可行方案。我认为存在第二个免费的ACME认证机构，其他认证机构若想保持竞争力，很可能会采用ACME。
理想情况下，这将比每年手动轮换耗费更少的人力成本。我认为那些无法应对的站点，在下次年度轮换时本就可能出现故障。
若证书由托管商管理，则由托管商处理。若非如此，说明有人本就在支付续费并负责服务器端的证书替换，这反而更可能确保问题得到解决。
CA/浏览器论坛竟采纳此方案着实令人意外。
既然浏览器不再显示EV证书详情，如今无人愿意为此付费。购买证书的唯一动机在于手动轮换证书——而Let’s Encrypt证书90天有效期的设计本就令人困扰。
若CA/浏览器论坛强制所有人运行ACME客户端(或外包给AWS/Cloudflare等托管服务商)，这岂不是消除了向CA付费的最后实质理由？
CA/BF历来决策糟糕，例如2020年通过的《公共信任代码签名证书签发与管理基准要求》。
微软曾投票支持该方案，如今他们几乎垄断了个人用户负担得起的云端签名服务。该论坛亟需软件开发者和终端用户的投票代表，否则成员们只会继续以我们的利益为代价自我 enrichment。
CA/B论坛与代码签名证书有何关联？
怎么可能无关？:)
他们制定了代码签名证书的基础标准。2020年新增的硬件模块强制要求导致价格暴涨，致使众多小型开发者放弃代码签名。
我的情况是：需要维护旧电视的门户系统，但这些设备不接受LE根证书——因为厂商几年前更改了证书。遗憾的是供应商无法通过固件更新新证书，我们只能认栽。
没错，当年LE根证书变更导致我们约25%的生产流量中断。大家都以为我们能控制客户的证书链。但客户看到连接失败时不会想“系统故障该升级”，只会觉得“这供应商不行了，换个靠谱的吧”。这事之后我就把面向公众的证书从LE换成了其他免费的ACME提供商。
所有CA的根证书轮换周期将大幅缩短，预计每五年更新一次。
若设备五年内就报废，这简直是计划性淘汰。
仅限于不允许用户自行更新CA证书包的设备。请联系厂商代表，要求推行“维修权”立法。
想了解更多——你有消息来源吗？
我认为CA机构本可通过轮换中间证书实现，强制轮换根证书既无实质收益又弊端重重。
Chrome根证书策略(其他根策略亦然)正转向五年轮换根证书、每年轮换签发CA的模式。跨签名机制在多数情况下能完美支持根证书轮换，除非使用IIS——那可就变成棘手难题了。
这简直是为微不足道的安全性提升而自找麻烦。
轮换根证书的优势在于：
1. 若发生严重问题，这些措施可能需要紧急实施
2. 若信任根证书频繁轮换，则需建立机制确保信任捆绑包可及时更新
我认为当前异常频繁的轮换才是设备故障的真正根源，我们必须及时止损。
> 若根证书频繁轮换，则需建立机制确保信任捆绑包可更新
五年期限不足以推动变革。电视制造商大可推诿称设备已过保修期，最终只会导致更多设备变砖。
五年只是过渡而非终点
这更像是绕行灼热炭火的迂回，根本无法接近目标。
> 1. 若发生严重问题，这些措施可能需要紧急实施
但这不正是中间证书的意义所在吗？
要知道，所有CA的在线系统仅持有中间证书(且通常存储在HSM中)，而CA根证书每年仅用于更新中间证书约20秒？其余时间都像诺克斯堡金库般严密保管？
关键在于，即便是最安全的设施也需要进出通道。
这些通道本身就是弱点。更重要的是，根证书轮换可能源于极其愚蠢的漏洞——比如数年后才发现某个特定密钥生成错误。
客户的质疑完全正确。“安全”界对向后兼容性的肆意践踏令人发指。
那么厂商若无法更新基础安全信任存储库，又如何部署其他安全更新？
若厂商真无力更新，产品设计时至少构成疏忽，最坏情况则是蓄意淘汰策略。
1. 通过HTTPS推送自动更新功能
2. 智能冰箱等产品可能被用户离线使用五年以上
3. 新房主将其联网
4. 安全更新失败——因更新服务器的SSL证书未获可信根证书签名
真正的解决方案是让客户端能修改你的垃圾。
汽车召回我们常做。只需发送邮件说明如何将更新写入U盘，本质上是同样的操作。
虽然对消费者不便且烦人，但替代方案更糟。硬编码证书从根本上就是个糟糕的主意。
没错，参与Web TLS需要具备定期更新服务器和客户端代码的能力。
万物皆变，软件永无终点。假装相反才是荒谬的。
> CA/浏览器论坛竟采纳此方案，着实令人惊讶。
证书机构和浏览器厂商可能存在分歧。
你这么认为？:)
没错。Mozilla大概希望这个靠租金谋生的无用中间商行业消失。
他们不会采用Acme，因为客户一旦采用，转向新(免费)供应商的成本几乎为零。
我预计他们会推出新的“更安全”的专有方案，通过供应商锁定策略维持现状，直至付费证书产业消亡。
免费服务商存在局限性，而新增的时效限制将加剧这一问题——需要续期的证书数量将激增。
大型企业仍会继续使用付费供应商，以确保业务连续性——毕竟免费供应商可能随时崩溃。况且Let’s Encrypt的服务等级协议(SLA)究竟如何，我也无从知晓。
事情远比“免费就用它”这么简单。
我任职过的几乎所有现代“大公司”，都在合理范围内使用Let’s Encrypt；有些企业使用得更彻底些。我认为你并非完全错误，但态度略显轻率。
希望大家都能采用ACME。目前我仍需向客户发送CSR，再接收证书回传。每年一次还算能接受。
现有两家，GTS技术上也算免费，只是操作复杂。
实际情况更复杂。苹果(连同谷歌和Mozilla)实质上挟持了CA机构。他们单方面缩短证书有效期，无论CAB是否批准都已成定局。
此次投票更关乎CAB能否保持存在价值。“要么接受现实，要么浏览器彻底拒绝认证”。
我最近就此写过长文：https://www.certkit.io/blog/47-day-certificate-ultimatum
感谢分享这段历史，我此前并不知情。值得玩味的是，既然此事终将由苹果强制推行，那么传统CA机构反而会更倾向于加速强制迁移时间表——这样他们就能为现有客户转向提供咨询服务。
我依然认为“那些曾产生巨大文化影响力的博客/出版物，在被收购/靠年度证书更新维持生命后，如今将被迫下线而非迁移至支持ACME自动化的系统——只因咨询费高于广告收入”将成为不幸的牺牲品。但这大概就是进步吧。
我认为这本质是“浏览器与CA机构的博弈”。赛门铁克信任危机后权力天平急剧倾斜，若详述其影响，极少有Reddit用户会支持恢复旧有格局。
如今人们抱怨证书自动续期很烦人(我确信确实如此)。而在此之前，抱怨的焦点是某些美国公司随意购买并部署自己的根证书，为任意陌生域名签发证书，只为让IT团队免于更新桌面配置。
现在情况好多了。
这篇文章很有意思，谢谢！有两个问题：
– 域名易主时，过期证书究竟有何问题？无论是否续签证书，用户的安全状况似乎都不会改变？
– CertKit是否与Anchor Relay类似？(https://anchor.dev/relay)
> 域名易主时过期证书会引发什么问题？
原所有者持有的证书有效期最长达398天。若其为具备中间人攻击能力的恶意方，可凭有效证书完全冒充域名所有者。例如Stripe初创时，曾从第三方购得域名，该域名持有者当时持有的stripe.com支付证书有效期近一年。(https://www.certkit.io/blog/bygonessl-and-the-certificate-th…)
> CertKit是否与Anchor Relay类似？
此前未曾听闻Anchor Relay，感谢提供链接！
CertKit功能相似但覆盖更广。Anchor声称其位于ACME客户端与CA之间，能简化验证步骤，这非常实用。但您仍需运行ACME客户端并在本地部署自动化逻辑。
CertKit本身就是ACME客户端。您只需将验证记录的CNAME指向我们，我们便会全权处理与CA的通信，并集中存储/续期/撤销您的证书。您的系统可通过API拉取(或接收推送)所需证书，我们则监控HTTPS端点确保正确证书运行。这是经过全面审计的集中式证书管理方案。
问题在于原所有者在一段时间内仍持有有效证书。
但这方向完全错误。我们应当遏制频繁的域名所有权变更，而非助长此风。新所有者窥见原所有者流量数据的问题，其严重性丝毫不亚于前者。
此说有误——部分CA并未“被挟持”，它们认同并支持这些变更。详见SC-081的签署方名单。
有趣的是这与WHATWG/W3C的现状如出一辙：理论上存在标准制定机构，实际却形同虚设；浏览器厂商宣布即将推出的功能，而“标准机构”只能逆来顺受。
区别在于：面对浏览器单方面制定网络标准的现状，至少存在些许公众不满；而证书颁发机构无人声援，只因人人皆憎恶它们。这揭示了重要教训：即便经营着成功的非法勾当，也需做好声誉管理——当人们对你恨之入骨时，纵使有人“非法”侵犯你，他们也绝不会挺身相助。
优步是道德破产的企业，靠违法行为建立市场地位，但众人视而不见，只因他们更憎恶出租车行业。
CA行业就是新出租车行业。
感谢分享，这篇文章很有见地。
你用的是哪款AI写作工具？水平相当不错。
> 此外，正如其他评论所言，这将使执法部门成为现代化进程中唯一可行的选择，从而使其成为比以往更关键的单点故障。
Let’s Encrypt并非唯一的免费ACME提供商，您可从其、ZeroSSL、SSL.com、Google和Actalis中任选其一，或为冗余配置多个。若使用Caddy，这甚至已是默认行为——它会优先尝试ZeroSSL，若因任何原因失败则自动回退至Let’s Encrypt。
> 若使用 Caddy，这甚至就是默认行为——它会优先尝试 ZeroSSL，若因任何原因失败则自动回退到 Let’s Encrypt。
不，这是错误的。实际情况恰恰相反。
“若 Caddy 无法从 Let’s Encrypt 获取证书，它才会尝试使用 ZeroSSL”。来源：https://caddyserver.com/docs/automatic-https#issuer-fallback
这合乎逻辑，因为访问ZeroSSL的ACME流程必须通过手动注册创建的账户。除非近期政策突变，LE仍是唯一无需注册的免费ACME服务。来源：https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/#acme-ca…
是我记错了顺序。您说得对，ZeroSSL确实需要凭证才能获取免费证书，但Caddy支持特殊情况自动生成凭证——只要在配置中指定邮箱地址，对用户而言就几乎是透明的。
https://caddy.community/t/using-zerossls-acme-endpoint/9406
更正：默认行为是仅使用Let’s Encrypt，但若提供邮箱地址，则会优先使用Let’s Encrypt，失败时回退至ZeroSSL。
LE的速率限制规则相当复杂，因此我改用ZeroSSL。这完全满足我的需求。
这就是我切换的原因。之前遇到路径挂载错误导致速率限制超标的问题。
哦，在LE平台上，速率限制调整请求的合同条款页面(如果真是这个？)无法加载：https://isrg.formstack.com/forms/rate_limit_adjustment_reque…
嗯，正确链接应为https://letsencrypt.org/docs/integration-guide/——但似乎链接失效了，我来修复。
这些免费CA机构如何维持运营？
Let’s Encrypt是由捐赠和企业赞助支持的非营利组织。
ZeroSSL、SSL.com和Actalis在基础免费证书之外提供付费服务。
谷歌嘛，就是谷歌。
啊，原来如此。谢谢！
> 谷歌嘛，就是谷歌。
所以你的“免费”SSL证书实则由监控资本主义提供，而代价是你(以及网站用户)的隐私？
道德层面取决于个人判断，但从纯技术角度看，即便谷歌有意为之，通过签发SSL证书侵犯用户隐私的操作空间也相当有限。据我理解，ACME协议从不让CA看到私钥，仅提供公钥——而公钥本身就是公开的。
使用谷歌公共CA更现实的担忧在于，他们可能最终厌倦了这项服务而关闭它，毕竟他们常这么干。准备备用CA才是明智之举。
> 道德层面取决于你自身判断，但从纯技术角度而言，即便谷歌有意为之，通过签发SSL证书侵犯用户隐私的操作空间也极为有限。
我不确定这在技术上是否准确。作为CA，他们确实有能力协助实施中间人攻击，也能签发欺诈性证书。
> 据我理解，ACME协议从不让CA看到私钥，仅提供公钥——而公钥本身就是公开的。
这更多涉及HTTPS端到端加密机制，而非证书签发协议本身。
这绝对与ACME相关。过去曾有CA会为你生成包含私钥的服务证书。这种做法显然极其危险，但ACME协议仅允许用证书签名请求(CSR)交换证书，彻底杜绝了这种可能性。
啊，明白了
> 还用你的隐私(可能还有网站用户的隐私)买单？
SSL证书运作机制并非如此——谷歌通过签发证书获取的信息，本就不会通过其他途径获得。
证书轮换/续期是我IT生涯中最头疼的事。永远都是事后补救。永远是痛点，永远要和财务部门争论成本问题。简直糟透了。虽然ACME的存在令人欣慰，但整个流程简直一团糟。
整个IT团队都打算对此不闻不问，直接转交给服务商或云IaaS处理。
老兄，我完全同意。整个系统糟透了。去年我们开始构建内部集中化解决方案，以便更清晰地掌握续订和到期情况：
目前正在为其他团队进行测试版部署。https://www.certkit.io/
挺酷的，但对我们来说，这类问题更适合在边缘节点通过自动化工具解决，比如Caddy服务器——它既能自动处理证书续期，又能充当所有域名的入口代理。
我希望Apache能原生支持这个功能。
我希望nginx能原生支持这个功能。
我希望tomcat能原生支持这个功能。
我希望express能原生支持这个功能。
每个HTTP服务器都把TLS当作事后补丁——先给我公钥私钥，我再帮你搞定。虽然现在这些服务器都有ACME模块，但这套流程本质仍是Web 1.0时代的部署逻辑。
金融科技和社交账号需要SSL没问题，但博客真需要证书吗？反正通过DNS请求就能知道我读什么博客。谁会去对艺术史学者的个人网站实施中间人攻击？这种地方根本不需要安全表演。
所有这些必备的、复杂的、不断变化的组件，意味着我们不得不依赖大型科技公司，无法再独立完成事情而不增加工作量。这还让中央政府更容易通过控制证书签发权限来封禁访问。当局不喜的对象可借证书撤销手段予以清除。未来签发权限或许将限定于持有国家身份证件的群体。
由于主流技术已与其他传播方式彻底割裂，一旦不符合规范，你瞬间就丧失了传播思想的能力。这就是《1984》式的控制手段。
> 我怀疑有人会对艺术史学者的个人网站实施中间人攻击。
但这正是ISP的所作所为！注入(更多)广告。替换为自家广告。植入各种JavaScript代码。比如加载更压缩的JPEG版本，用户必须额外点击按钮才能查看完整图片。从SMTP连接中移除STARTTLS字符串。早期沃达丰的UMTS/G3网络尤其恶劣。
我还记得某些“艺术”项目：只要修改公共/学校电脑的DNS设置，就能篡改《明镜周刊》等网站的新闻报道。
这是只读网站运营者常挂嘴边的托辞。
问题不在于“你这边”，而在于“你与客户端之间”的环节。
在传输过程中注入额外内容、恶意JavaScript或广告等变得轻而易举。这并非针对你网站的“定向攻击”，而是对所有不安全网站的普遍操作。
TLS的意义不在于限制信息传播能力。其核心在于保障读者能读到你真实撰写的内容。
TLS免费且易于实施。拒绝采用的唯一理由是懒惰。你或许认为TLS违背原则——但我视其为“漠视读者安全”的态度：“任人向我的页面注入恶意JavaScript(或更恶劣的攻击)，他们的安全与我无关”。
(政府若想审查你，大可通过DNS实现。)
如何防止实体信件在投递过程中遭人擅自拆阅？我们基本无需担忧，因为拆阅信件已被列为严重犯罪。我们本可对恶意ISP采取同等措施，但浏览器厂商却选择将计划性淘汰作为网络标准。
立法禁令具有地域性，且执法形同虚设。但拆封本身并非核心问题。
类比而言，真正的威胁是信件被拆封后植入炭疽菌。这种情况(通常)不会发生，因为实体邮件难以大规模操作(况且炭疽菌无法挖比特币)。
鉴于当前针对勒索软件、黑客攻击、钓鱼诈骗、身份盗窃、网络骗局等行为的法律效力薄弱，我认为仅靠“禁止此类行为”的法律条文无法解决问题。
而且ISP绝非唯一肇事方。每个公共Wi-Fi都同样是极具吸引力的攻击节点。
若博客未启用TLS，任何中间人皆可轻易向所有读者注入恶意软件。
这依然可行，只需植入第三方JavaScript或利用未打补丁的后端应用
作为中间设备，在缺乏证书密钥的情况下，如何向TLS网页注入任何内容？
供应链问题——若页面引入第三方脚本链接、广告、追踪代码，甚至仅更新依赖项至恶意版本(如npm包攻击)，一旦服务或依赖项遭入侵，TLS也无能为力
我同意。幸运的是，博客还有另一种选择——确保网站通过HTTP/80端口访问。这额外的好处在于，你的网站能在不支持SSL证书的旧设备上继续运行，甚至能被那些根本无法尝试解码SSL的复古硬件访问。
虽然我拥有现代笔记本电脑，但仍会偶尔启动旧款Pismo PowerMac G3，以确保我的网站在HTTP协议下正常运行，兼容老旧硬件，并在旧版浏览器中呈现可接受的效果。
遗憾的是，这意味着您的页面将存在多个URL地址，其中部分地址无法在所有设备上访问——而您无法控制用户分享的具体URL。
若你与互联网之间采用HTTP通信，那么SSL绝对必不可少。这就像问“天气炎热时，我真需要穿短裤还是长裤？”答案永远是肯定的。
强制要求SSL的背景是美国主要ISP开始向所有HTTP页面注入恶意软件。若仅是理论担忧我或许认同，但现实中这种情况确实发生过，这足以推翻任何理论辩论。还有PRISM计划。
> 还有PRISM项目。
PRISM完全能破解HTTPS加密通信。若所有可监控网站都采用HTTPS，NSA反而会更满意——这完全符合“不使用”原则。
> PRISM完全能破解HTTPS加密通信
来源：
https://en.wikipedia.org/wiki/PRISM
他们直接从公司端获取已传输的数据。这并非窃听，更像是自动化的传票执行机制。
他们也实施窃听，具体项目名称无关紧要。
哦，实际渗透程度远超想象。
这只是公众知晓的部分。实际规模远超想象。
国防部领域多数优秀项目都冠以《星球大战》式名称：BESPIN、JEDI等。PRISM只是机制之一，是庞大体系的组成部分。
注意时间线。短期内不会有变化。
>明年，早期采用者可通过tlsserver配置文件选择45天有效期的证书进行测试。2027年我们将把默认证书有效期降至64天，2028年进一步缩短至45天。
你对“近期”的定义和我不同。
好消息是，证书颁发机构(CA)此举等于签署了自己的死亡判决书。若转向ACME几乎成为强制要求，付费证书还有何价值？你的选择只有三条：使用LE证书、转用非CA签发的加密方案，或彻底放弃加密。
你只考虑了证书购买成本，却忽略了技术支持、SLA协议、配套产品、管理平台、私有PKI等开销。若你仅使用公共TLS，那确实可能成为问题。
付费证书由$$CA签发，有效期1年。LE证书仅能使用3-4个月就需重新签发。若无法通过自动化ACME配置处理续期，能延迟一年续期就值得花20或70美元购买通配符证书。
若付费证书有效期缩短，那确实毫无理由白白烧钱。
付费CA机构很快将只签发45天有效期的证书，因为浏览器只接受这种时效。
近年来新网页功能默认仅支持HTTPS。因此若网站使用任何近期API，放弃加密绝非选项。
安全上下文仅适用于涉及隐私或安全敏感性的功能。虽然某些知名功能在列，但完全可以构建不依赖这些功能的现代化网站。
保障通信安全是防范中间人攻击的必要措施。
> 但Let’s Encrypt对此举不负责任，且未参与投票表决。
“未参与投票”与“不负责任”的表述颇具深意…
他们本可揭穿其虚张声势。我若处此境必将如此。CA/浏览器论坛此举实属失误，唯有相关参与方默许配合，其行径方能得逞。
浏览器厂商有动力增加复杂性，优秀工程师理应抵制此举。
> 我认为这项政策变更足以破坏互联网
遗憾的是，决策者根本不在乎实际用户会受到怎样的影响。浏览器厂商屡屡强行推行某些在纯理论层面看似合理、却让身处现实世界复杂困境中的普通用户痛苦不堪的方案。
此处“浏览器厂商”通常特指谷歌，尽管该提案实际来自苹果的克林特·威尔逊。
谷歌发号施令，其他厂商唯命是从。
Nginx 和 Apache 都是免费的，且均可通过 ACME 机器人轻松实现自动化部署。两者都可用于在传统网站或应用程序前端设置反向代理。
这并非将所有事务集中到 Let’s Encrypt，而是强制所有人使用 ACME。许多证书颁发机构已支持 ACME(尚未支持的机构也可能因这一变化而很快跟进)。
这与客户端认证EKU灾难如出一辙，实为谷歌所为。
>我认为这项政策变更可能破坏互联网生态——大量使用旧式证书的存档/遗留网站可能无力承担从年度续期转向实质月度续期的前期技术投入或持续维护成本，最终只能被迫关闭。
这纯属危言耸听。遗留网站本就需要技术升级，而证书续期全自动化能减轻人工维护负担。
浏览器是否仅强制要求公共信任CA证书遵守47天有效期限制？
是的。
我从一开始就指出：将互联网所有权力集中于单一组织是危险之举，却屡遭反对者打压。让单一机构决定你能否在互联网上拥有网站，这客观上怎么可能是好事？
至少你敢提问，我支持你。但被反对是因为你的前提有误。
支持ACME协议的机构众多。LE是最知名的，但还有其他组织，且更多组织正在加入。
现有CA机构不会因此消失。它们可以自由实施ACME(或专有协议)，完全有权继续收取证书费用。
此变革的实质影响在于流程将发生改变(尚未改变的流程)，这将同时提升用户体验和安全性。
但需明确：此流程中不存在“单一组织”主导。这点请放心。
你被点赞可能是因为这并非将互联网权力集中于单一组织，而非人们对此持反对意见。
无论你是否认同，CA/浏览器论坛对网络拥有巨大影响力——因为他们掌控着浏览器。切勿误解：正是浏览器厂商代表最积极推动加强安全措施和缩短证书有效期。
我感觉这更多关乎控制权而非安全问题。
我实在受够了这种毫无必要的政策升级。这在每个行业都是顽疾——当解决方案不可行或不切实际时，可调节的旋钮总会被拧紧。企业合规也是同样的问题：我至今仍在轮换密码，启用双重认证，某些环境甚至需要三四重验证，而除了“不做更多会引发法律责任”的恐惧外，没人能真正解释这种做法的合理性。
>我仍在轮换密码
虽有些跑题，但我觉得这很荒谬。如今几乎所有生态系统都要求用户特意去开启强制轮换功能。
各网络安全标准明确反对强制轮换已近十年。而我们早在两年前的研究就已证明强制轮换的荒谬性。
PCI标准至今仍建议90天更换密码。所幸他们已放宽要求，允许采用零信任方案替代。虽然两者并非等效控制措施，但8.3.9条款明确将其列为“或”选项。
我认为这仅在密码作为唯一验证因素时才强制要求，对吧？若采用其他验证因素、零信任或风险基准认证，即可豁免轮换。我已很久没关注PCI相关规定了。
总之，我所有同事都痛恨PCI。
但这意味着减少工作量，而减少工作量本身就是坏事。我们必须采取行动！想想孩子们啊！
那项研究发布时，我曾尝试让公司停止强制轮换密码。我的请求被直接否决，对方连解释都不屑一顾。不知是担责恐惧还是网络保险商强制要求，但管他呢，我们照样要轮换密码直到太阳熄灭。
这早已被确立为长期目标。核心理念是：应通过自动化消除证书签发环节，最终缩短证书有效期至无需撤销的程度——毕竟这比修复漏洞百出的撤销机制要简单得多。
问题在于自动化失败时，你只能手动操作。而缩短更新周期意味着更多出错机会。我曾在HN因承认这一点遭到猛烈抨击，但自动化的L.E.证书续期从未真正可靠过——总会出问题。所幸我只托管几个业余爱好和俱乐部域名以及个人邮箱，并未依赖域名创收。现在，我只能通过网站故障或邮箱提示证书失效来判断是否已满90天，然后不得不通过SSH登录VPS手动处理。这条消息似乎预示着未来我得更频繁地照看Certbot了。
我去年配置后从未干预过它。它始终稳定运行。
真的吗？我从未遇到过故障。我直接运行了Let’s Encrypt提供的脚本，它自动完成所有配置，并持续自动续期——直到我因财务原因关闭网站。好奇问下，你上次使用Let’s Encrypt是什么时候？是用官方脚本还是第三方工具？
我多年前就配置好了，可能那时他们还没提供脚本。我的方案极其简单：每月运行的crontab：
以及脚本内容：
…其他服务也按此模式配置
仅此而已。理论上应万无一失，但每隔几次续期就会发现某个进程未加载新证书，手动重跑脚本即可修复。耸肩表情。
不清楚“letsencrypt-renew”的版本历史和具体功能。但现代ACME客户端是每日运行的。实际续期流程会在证书剩余30天时启动，因此即使失败也能至少重试29次。
我的OpenBSD(HTTP-01)acme-client五年未曾修改：acme-client -v website && rcctl reload httpd
我的(DNS-01)LEGO客户端偶尔会出现DNS问题。但如前所述，它会每日重试直至成功。
> 我不清楚“letsencrypt-renew”的版本历史及其具体功能。
它位于“脚本内容”下方五行处：
抱歉啊完美先生，我冒昧指的是“certbot”。
我并非在嘲笑你。你明明说不清楚“它做什么”，根本看不出你指的是这个。我确信你清楚certbot的功能，所以以为你误解了帖子内容。
确实，我也是。每隔几个月就会有热心网友提醒我证书过期，手动运行通常就能解决。LE软件质量实在堪忧，这些年我遇到过多次问题，其中几次甚至导致整个系统被LE的Python环境代码覆盖。
既然问题反复出现，添加监控机制不是更合理吗？例如我的SSL每日续期检查机制，每次运行后都会通过openssl s_client验证受影响服务实际使用的证书有效性。
我确实配置成功了，运行也还算稳定，但过程实在麻烦。另外不知为何他们通过HTTP连接我的服务器，所以我必须打开80端口才能完成更新。
这是因为你将HTTP-01验证挑战设为域名验证方式。
https://letsencrypt.org/docs/challenge-types/
难道没有等效的HTTPS验证方式吗？
我们本可以直接修复OCSP钉接问题。更理想的做法是彻底废弃CA认证体系，直接采用DANE方案。
对行业尚未解决的问题强行推行任意缓解措施，并非良策。这只是企业界偏好的权宜之计。
但这种方案对任何内部证书都难以实施——随机内部团队根本无法修改企业DNS。TLS本就是内部软件的噩梦，浏览器还在不断加剧这种痛苦。
更不用说WEBPKI机制已彻底扼杀了将消费级软件作为离线个人Web服务器部署的可能性——毕竟用户不会专门购买DNS域名来消除浏览器对本地软件访问的安全警告。因此你只能让用户忽略浏览器安全警告，或者将服务器绑定到某种在线订阅服务——由你管理并为客户的私有IP生成伪造证书，只为让浏览器闭嘴。
私有CA和CERT仍将被允许拥有更长的有效期。
这帮不上什么忙，毕竟你还是得在所有设备上折腾安装私有CA证书。企业环境里或许不成问题，但对个人网络而言简直烦死人(尤其想让朋友加入时)。
它还忽视了现实世界——CA/浏览器论坛都承认他们根本不懂证书在现实中的实际用法。他们纯粹是在破坏现状，让世界变得更糟。
这些机制针对的是组织/用户群体——相较于个人度假博客，他们对证书误发和吊销延迟的后果更为严重。但我认为在此情境下，他们的行为并非自私或非理性。证书有效期短且吊销列表精简确实能为用户带来实质性安全效益，而公共PKI体系的强度往往取决于最薄弱的CA。
OCSP(配合证书钉接机制)曾试图以更小代价实现这些效益，但最终失败的原因与本次变更引发的痛苦如出一辙：服务器运维者永远不愿为任何理由进行任何配置。
你提到了关键点…更优解是创建特殊类别的证书，类似EV证书，采用极短有效期，专门服务于银行等需要此级别的企业。当然，多数银行连SPF、DKIM和DMARC都持续数年配置错误，他们肯定会找到搞砸的方法。
> OCSP失败的原因与本次变更的痛苦本质相同：服务器运维人员永远不愿为任何理由进行任何配置。
OCSP即将终止支持，因为它让用户追踪变得过于容易。
摘自Lets Encrypt[1]：
我们终止OCSP支持的主要原因在于其对互联网隐私构成重大风险。当用户通过浏览器或其他软件访问网站时，若该软件通过OCSP检查证书吊销状态，运营OCSP响应器的证书颁发机构(CA)将立即获知该IP地址访问了哪些网站。即便CA刻意不保留此类信息(如Let’s Encrypt的做法)，仍可能因意外保留数据，或被法律强制要求收集信息。证书吊销列表(CRL)则不存在此问题。
[1]: https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-…
> 他们纯粹在搞破坏，让世界变得更糟。
其实是那些想搞中间人攻击的人挑起的，此后大家就陷入了永无止境的军备竞赛。如果人类能协调保持高信任平衡状态，而非滑向低信任状态，就能省下大量安全开销。
难道你不知道所有使用TLS的公共路由设备都在运行网络服务吗？
那你也可以给任意配置的服务器分配API密钥，赋予其修改任意DNS记录的权限…这能出什么问题呢？
#security
这正是HTTP-01验证机制存在的意义——它完美适用于单服务器公共部署。若业务规模大到需要负载均衡器，DNS更新协调(或集中处理HTTP-01验证)根本算不上你的首要顾虑。
为了让企业能偷懒管理内部网服务，就拿公共PKI技术进步当人质——这对依赖公共TLS的大多数人而言，是极其糟糕的权衡。
那我的IRC服务器呢？它们根本没有HTTP守护进程(因此该端口被封锁)，却要通过任何播地理围栏DNS进行负载均衡？
互联网上的存在远不止Web服务器。
或许你会说“使用DNS-01验证”；但这过于简化——这意味着允许任意节点控制我整个域名(而许多注册商甚至不允许API访问记录，更别提仅限单条记录的API密钥了；连云服务商都不提供这种功能)。
我甚至认为邮件服务器在Let’s Encrypt模式下难以良好运行，除非采用无冗余的单服务器架构。
不过现在应该没人这么做了，我完全理解原因。
我曾运营过不依赖HTTP而采用公共PKI的网络服务(最近一次是WebTransport)。但这些服务终究只是公共PKI体系中的访客，该体系主要承受着攻击者试图窃取公共HTTP传输金融信息的威胁。没人要求IRC采用公共PKI验证服务器，同样我不明白为何要让如今实质免费的CA服务，为那些搭便车的边缘案例自我设限。
> 那么我的IRC服务器呢？它们既不运行HTTP守护进程(因此该端口被封锁)，又通过任何播地理围栏DNS实现负载均衡？
您为域名获取的证书可用于任何接受该证书的客户端——HTTP部分仅对ACME提供商有效。因此您可以将80端口指向ACME守护进程，仅通过该端口提供验证挑战。但这未必是理想方案，具体取决于您的路由配置，因为所有发往该端口的请求都将收到相同的验证响应。
> 或许有人建议“使用DNS-01”；但这过于简化——这等于让任意节点控制我的整个域名(且多数注册商甚至不允许API访问记录，更遑论仅限单条记录的API密钥；连云服务商都不支持这种机制)。
使用证书的服务器不必是执行ACME流程的服务器，当存在多个节点时，这种分离往往更合理。即便是精通ACME的高级用户，也很少为每台服务器单独配置证书。
顺便提一句，存在无需API密钥即可使用DNS-01验证的方法，且该方法不会控制整个域名。
https://hsm.tunnel53.net/article/dns-for-acme-challenges/
在每个远程安装程序中配置DNS API密钥确实存在问题。
但解决方案其实很简单。在我们的架构中，我搭建了一台小型服务器，仅配置了几个REST接口。
每位客户都拥有独立登录权限访问该REST服务器，他们只需执行“获取新证书”请求。
DNS-01验证由REST服务器处理，生成的证书再提供给客户端安装程序。
因此实际安装过程中，客户设备永远不会接触到我们的DNS API密钥。
如果它不运行网络服务，也不具备公共路由能力——为何需要它在全球数十亿用户的浏览器和设备上运行？
难道我们否认浏览器是通用应用分发平台的事实？它既支撑企业内部工具，也滋养个人爱好项目。
还是说 TLS 与 HTTPS 毫无关联？明明 HTTPS 就是基于 TLS 的 HTTP；而 TLS 保护的范围远不止于此——从 API、邮件到 VPN、物联网及非浏览器终端皆在其列？这两种说法都站不住脚，任君选择。
或者选择第三种方案：无视CA/B论坛不断升级的认证机制如何迫使运维人员分叉浏览器、篡改根证书存储库，或用可被利用的权宜之计分裂生态系统(他们不会这么做：他们只会对所有内部用户重回“此证书无效，是否继续？”的提示界面)。
对于公共浏览器之外的系统而言，45天证书轮换周期堪称“稳固安全”的绝佳典范。
还记得当年所有SMTP提交服务器盲目接受任何证书的日子吗？因为域名验证会导致邮件服务中断……嗯
灵感迸发。
> 或者选择第三条路：无视CA/B论坛不断加码的压力，让运维人员被迫分叉浏览器、篡改根证书存储库，或用可被利用的权宜之计分裂生态系统(他们不会这么做：他们只会对所有内部用户重启“此证书无效，是否继续？”的提示)。
它根本不做这些。只要在现有开源工具基础上多花点功夫配置ACME，基本上任何你掌控服务器的场景都能解决这个问题。若使用厂商提供的服务可能陷入困境，但若由我决定，我主张不应为支持那些不愿更新产品(且拒绝提供程序化配置服务器证书的API——该方案同样可解决此问题)的厂商商业模式，而将公共PKI永久僵化。
> 对于脱离公共浏览器生态的系统而言，45天证书轮换周期堪称“安全典范”。
确实如此，且绝非反讽。若证书轮换仅是年终例行操作，而掌握该技能的员工已离职，当系统遭入侵时，贵组织能多快完成证书更新？很可能某个被遗忘的服务仍在使用已泄露的证书，直至其失效。
> 还记得当年所有SMTP提交服务器都盲目接受任何证书吗？因为域名验证会导致邮件无法发送……
虽然这成了经典梗，但未验证的TLS协议在服务器间SMTP通信中其实比完全不验证强得多(当然验证更优)。在两个不同数据中心间通信时(不像咖啡馆环境)，监听TCP连接远比实施中间人攻击容易得多。实际中多数邮件往来发生在大型服务商之间，因此它们能协商建立信任机制，保护绝大多数邮件免受中间人攻击。
> 虽然大家都喜欢拿这个开玩笑，但未经验证的TLS协议在服务器间SMTP通信中实际上比完全不加密强得多(尽管验证机制效果更佳)。在两个不同数据中心之间通信时(不像咖啡馆环境)，监听TCP连接远比实施中间人攻击容易得多。实际中多数邮件往来发生在大型服务商之间，因此它们能够协商建立信任机制，同时保护绝大多数邮件免受中间人攻击。
不，这根本毫无作用——毕竟你随时可以伪造任意TLS证书实施中间人攻击。
你以为自己在防范什么？端口镜像的被动监听？
网络探针通常比这复杂得多。
如何与谷歌建立信任？他们如何信任我？毕竟我们没用官方设计的系统，显然不可能实现——否则他们至少会开放这个选项。
> 不，这根本毫无意义，毕竟你随时能伪造任意TLS证书实施中间人攻击。
> 你以为自己在防范什么？通过端口镜像进行的被动监听？
没错，正是如此。对于数据中心间的流量，小角色犯罪分子实现监听要比中间人攻击容易得多。只需在同一二层交换机域内部署设备，伪造MAC表即可(这类环境中MAC欺骗/端口安全常被忽略或配置错误)。完全无需破坏路由。
> 如何与谷歌建立信任？他们如何与我建立信任？我的意思是，我们并未使用专为此设计的系统，显然这不可能实现——否则他们至少会启用此选项。
与谷歌建立信任其实极其简单：其所有SMTP服务器长期持有有效的公共PKI证书。即便没有，他们也能提供内部CA根证书供验证。这种机制虽不适用于大规模组织，但几乎所有合法邮件流量都发生在谷歌、微软、雅虎及十大营销/交易邮件服务商之间。
正因如此，没人急于解决SMTP中间人攻击问题。况且由于SMTP投递层不进行应用级认证，你真正需要防范的只是窃听/阻断投递行为。若要发送伪造邮件，服务器提供的证书无关紧要——你根本无需窃取密码。
因为该服务需支持非受管设备访问，无论是在互联网还是隔离的无线网络环境中。
这种需求常见于应急管理的移动指挥中心、机载娱乐系统及其他同类系统。
我个人在家用局域网部署了媒体服务器，供亲友来访时使用。该服务器使用公开信任证书，由我每年手动续期——毕竟不会要求访客安装我的PKI根CA。这台设备完全无需互联网访问权限，更不应被允许修改我的公共DNS区域。
没错，但在那些场景中——自动化和短期证书完全可行。
除非根本不需要，因为这类系统极少(甚至从不)接触互联网。
它或许永远不会“接触”互联网，但证书完全可以自动化获取。这些设备无需具备互联网访问权限，也无需修改DNS的权限——但若想让全球任意机器默认信任它，那么确实需要付出努力获取证书(这相当于在某个时间点证明你控制着该FQDN)。
问题又回到了：如何创建仅允许修改单条记录的API令牌，适用于任何主流云服务商？
或者…任何域名注册商(Namecheap、Gandi、Godaddy)？
答案似乎是：“兄弟，既然你追求安全性，那么实现方式就是：要么让所有需要TLS的设备获得修改任意DNS记录的权限，要么将其置于公共互联网中；这才是安全之道”。
(注：此前常见的回答是：“那别用LE，直接从主流供应商购买证书”，但现在这种方案已行不通)。
如下方所指出的，确实存在解决方案——将所有域名通过CNAME指向单一目标域名，并在该域名处进行修改。此外还有一种新型DCV验证方法，仅需单个静态记录。预计未来数周至数月内将获得广泛CA支持。这或许能解决问题？
针对这个(完全合理)的担忧，我看到的一种解决方案是使用CNAME委托，将_acme-challenge.$domain指向另一个拥有独立NS记录和专用API凭证的域名(或子域名)。
这是个愚蠢的政策。为了解决证书这个根本不存在的问题，我们反而在证明自己能够访问DNS注册商的服务门户。
这其实并非愚蠢问题，而是BygoneSSL问题：https://www.certkit.io/blog/bygonessl-and-the-certificate-th…
使用Let’s Encrypt反而成本更高。
最讽刺的是，没人阻止那些“开明”的CA/浏览器论坛为自家设备签发短期证书，却偏偏不允许我们自主决定如何保障用户通信通道的安全。我们根本不被允许像“成年人”那样行事。对浏览器锁定的无知同样令人发指。照他们说的，我们大可从零开始打造全新浏览器来规避问题——一个对证书有效期设有限制的合理浏览器。
我担心这反映出两个误解。
首先，缩短证书有效期本意是便于在误签发时撤销。但仅延长证书有效期并不能解决问题，因为攻击者仍可申请长期证书。
其次，创建新浏览器无法解决根本问题。网站证书必须被所有主流浏览器接受，只要市场份额较大的浏览器(如Chrome)坚持要求短效证书并拒绝长效证书，网站就必须获取短效证书——即便其他浏览器支持长效证书。
我始终认为，BGP领域本应采用类似RPKI的机制来解决第一点。即与其宣称“某些场景需要处理${CASE}，因此这成为所有人的基础安全要求”，不如建立“通用基础设施来精确定义互联网资源的使用方式”。在BGP场景中，这演变为“AS 42可发布1.0.0.0/22路由，最大长度为/23”这类规则。如今即使遭遇劫持/欺骗/BGP对等密码泄露等情况，由于RPKI配置的存在，也可能不会引发严重后果。
网络证书领域同样适用，例如“domain.xyz可申请有效期不超过10天的非通配符证书”。我认为证书体系崩溃的症结在于：它们将所有鸡蛋都放在客户端吊销列表里，当该机制失效时，责任却转嫁给管理员集体处理，而签发机构却袖手旁观。
关于第二点，我认为这种阻力正是其设计初衷。技术上可行，但实际效果有限。
> “domain.xyz可申请有效期不超过10天的非通配符证书”？
此处可能涉及两项提案：
(1) 类似CAA机制，向CA机构规定行为规范。(2) 在客户端强制执行的约束条件集。
CAA确实有帮助，但若担忧证书误签问题，就必须关注CA机构本身的安全性(顺带一提，这同样适用于网站实际使用的CA签发的证书)。浏览器端约束机制的问题在于：这些约束需通过可信渠道传递给浏览器，而此处的信任根基正是CA机构。RPKI的情况则不同，因为它属于更集中的信任基础设施。
> 关于第二点，我认为阻力正是他们要达到的效果。技术上可行，但实际意义有限。
我不太明白。假设你成功推出新浏览器并占据30%市场份额(确实需要巨大突破)，这依然无关紧要——因为行业标准由最严格的主流浏览器制定。
RPKI类方案更接近方案#1，但省去了信任遭入侵CA的环节。即当CA遭入侵时，只需撤销并重生成CA根密钥进行分发，而非依赖对每个可疑密钥的单独撤销检查，或被动等待45天(或其他时限)让恶意密钥过期失效。
> 我没明白。假设你成功推出新浏览器并占据30%市场份额(确实需要巨大突破)，这依然无关紧要——因为行业标准由最严格的主流浏览器制定。
我认为我们思路一致，只是对原文的解读存在差异。这类似于讽刺手法——表面是“没错，你可以照他们说的做”，实则暗指“但实际上你根本做不到_那件事_”。你只读出了前者，我则读出了后者。当然GP可能另有深意：)。
话虽如此，我并不完全认同这真的仅与最严格的主流浏览器有关。例如，如果Firefox将证书有效期设为7天，我敢打赌用户会转用其他浏览器，而非所有网站都开始每7天轮换证书。若部分浏览器执行而部分不执行，结果将取决于具体浏览器的用户基数及其市场份额等因素。这正是浏览器厂商集体参与的众多原因之一——确保政策变更时不会因孤立决策陷入被动。
顺便感谢Let’s Encrypt。尽管续期压力令人困扰，我仍认为这对网络生态是净收益。
部分用户未来可选择每7天自动获取新证书[1]。
[1]: https://letsencrypt.org/docs/profiles/#shortlived
但我认为缩短证书有效期并不能解决恶意CA滥发证书的问题，这种权衡并不值得。Moxie对CA问题的最佳总结可参见[https://moxie.org/2011/04/11/ssl-and-the-future-of-authentic…] ](https://moxie.org/2011/04/11/ssl-and-the-future-of-authenticity.html)
至于创建浏览器方案纯属玩笑，不过确实有人建议让不适应新规则的人这么做。
若政策过于烦人，我会在某个临时笔记本(比如始终在浏览器中打开的秘密gist，或内置生成器的双因素认证定制网页)半公开地记录密码。这样既能将验证因素降回单一，又能绕过“禁止重复使用300000个旧密码”的荒谬限制。每次都管用。
证书寿命过短使Let’s Encrypt成为互联网的关键故障点，这令人担忧。故障可能源于技术问题或政治因素。
还有其他基于ACME的免费证书提供商，必要时切换应该相当轻松。(若已配置CAA记录等，可能需要手动干预。)
可配置多个CAA记录，因此应能设置备用证书颁发机构。对重要站点采取此措施是明智之举。
说一个吧，比如NSA运营的Cloudflare。
ACME https://guide.actalis.com/ssl/activation/acme
Google https://pki.goog/
SSL.com https://www.ssl.com/blogs/sslcom-supports-acme-protocol-ssl-…
ZeroSSL https://zerossl.com/documentation/acme/
我认为Cloudflare其实并未运营ACME证书颁发机构。他们只是与LetsEncrypt合作？编辑：看来他们根本不运营任何CA，只是将业务委托给多家第三方机构https://developers.cloudflare.com/ssl/reference/certificate-…
这些只是支持ACME协议的提供商，并非免费证书供应商。
谷歌和ZeroSSL都通过ACME提供免费证书。上述链接中有更多细节。
无关紧要。这是CA/浏览器论坛的推动。谷歌、Mozilla和所有CA聚在一起说：“嘿，要不我们直接缩短证书有效期？毕竟除了过期机制外，我们实在想不出其他有效的吊销方案。”他们以前就搞过这种破事，但当时还算有人清醒。这次可没这么幸运。
缩短证书有效期会强烈推动用户转向ACME服务，从而远离商业CA机构，因此指责CA机构破坏该流程的说法实属荒谬。
Mozilla确实拥有切实可行的证书吊销机制。
https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co…
>Let’s Encrypt 成为单点故障
这已存在许久，与证书有效期无关。
所有人都依赖它，而不同于CF等互联网瓶颈点…Let’s Encrypt是家非营利组织
你说的像这是坏事似的。你捐款了吗？我捐了！
>你捐款了吗？
是的
这不是Let’s Encrypt的政策。这是全球性政策：https://www.digicert.com/blog/tls-certificate-lifetimes-will…
能否解释证书有效期缩短如何反而使LE成为更严重的单点故障？勉强能理解增加CA多样性的论点，但难以理解缩短有效期如何加剧CA集中化。
证书有效期缩短意味着更多续期事件，这意味着在站点因无法及时续期而断网之前，必须确保LE(或其他证书颁发机构)随时可用的情况将更加频繁。
虽然尚未完全形成，但证书有效期不断缩短以规避撤销列表相关问题的逻辑演进，预示着我们终将走向这样一个境地：主要的ACME认证机构将加入高度中心化的企业行列，成为“互联网”的依赖对象，与AWS、Cloudflare等巨头并列。当证书有效期以年或月计时，即使CA遭遇突发状况，只要用户未拖至最后一刻才续期，影响尚可承受。但当有效期趋向于天甚至更短时，CA机构就必须具备机构级别的高度可用性保障。
与其说LE成为新的单点故障，不如说ACME证书颁发机构这一概念本身，已然跻身维持网站在线所需的关键可用性要素之列。
> 预示着我们终将迎来这样一个局面：主流ACME证书颁发机构将加入高度中心化企业的行列，成为“互联网”的依赖对象
我认为这艘船十年前就启航了！
> 关键不在于LE本身成为单点故障，而在于ACME认证机构这一概念整体跻身维持网站在线所需的关键可用性要素之列。
好，这正是我想澄清的。我并不否认CA是关键基础设施，且任何基础设施一旦关键化都存在潜在风险。我只是认为这种风险是合理的，尤其在政策调整后，LE本身作为单点故障的风险并未增加或减少。
若在证书到期前7天续期，最坏情况也只需停机一周，总体影响小得多。
天啊，你甚至可以设置在证书还有一个月有效期时就自动续期。
我更担心掌舵的蠢货们会推行每周或三天续期这种蠢事，“因为在某些理论场景下能提升安全性”
因为当他们最终实现7天续期的痴心妄想时，所有人每周都将依赖他们。LE若停机48小时，足以让互联网大面积瘫痪。
证书历来属于“发射即遗忘”模式，但频繁重发将使LE服务重要性堪比DNS和网络托管。
顺便说一句，我们极其清楚超短有效期和频繁续期带来的运维风险。正因如此，我们明确将
短效配置文件限定为仅适用于具备高运营成熟度和轮值机制的组织。我们同样配备寻呼机待命，若LE停运48小时，我们将竭力避免导致互联网大面积瘫痪。根本解决方案是彻底废除CA机构。
完全赞同。虽然不确定具体方案，但这绝非正解。
更多是疏忽而非故障。
证书有效期越长，因管理员忘记续期或不知如何安装新证书导致的故障就越频繁。这曾是家常便饭，往往造成数小时甚至数天的停机。
如今这种情况罕见得我甚至记不清上次遇到过期证书是什么时候了。而且我敢肯定这并非因为可观测性提升了…
增加触点数量会大幅提升服务不可用及影响服务的概率。
没错，但这与单点故障无关。无论HTTPS是否集中管理于LE，这种政策都会导致单点故障。
当然。这是某个对任何人都无需负责的组织制定的愚蠢政策，它代表着怀有私心的利益集团。
我倒不认为其动机如此卑劣：证书颁发机构基金会(CABF)通过浏览器的激励机制(本质上是用户激励，经由谷歌、微软、苹果和Mozilla对价值判断的媒介)来约束证书颁发机构。这种中介机制或许不够理想，但并非责任归属的黑洞。
我不认为其本质腐败，但浏览器厂商无法代表服务器运营商或终端用户等多元利益群体。
这种激进观点屡见不鲜，但逻辑站不住脚。难道大家担心LE会突然停用45天？ACME本就是开放标准且存在其他实现方案，实在看不出其中存在政治性的单点故障风险。
值得庆贺的好事就该好好庆祝，何必对所有事物都皱眉呢？
是的，ACME 机器人的默认设置不是会在证书剩余有效期约 30% 时尝试续期吗？这意味着证书颁发机构必须停机数天/数周才会影响生产环境。
哦对了，你肯定会知道这次停机，因为新闻会报道，而且你已经设置了监控系统，会在证书即将过期时提醒你 (你肯定设置了对吧？对吧？)。即便如此，你仍可轻松切换至支持ACME的其他CA。
不
还有其他支持ACME的CA
包括付费CA，如果你真想付费的话：Sectigo
Sectigo同样将被迫签发短期证书。这是CA/浏览器论坛的强制性决议，所有成员CA都必须遵守。
他们确实会这么做，但Sectigo强制加速续期并不会让Let’s Encrypt成为集中式故障点。集中式故障点才是上述担忧的核心。
但Sectigo根本不在乎，他们和Let’s Encrypt本质相同(只是需要付费)
你可以通过ACME续签Sectigo证书，技术层面只需增加cron任务的执行频率即可
同意。我们需要第二个来源，最好位于欧盟境内。双方可共享操作代码/协议等。即和平时期可开展协作。
欧盟早在2008年就启动伽利略全球导航卫星系统(“GPS”)建设，作为美国可能敌对时的备用方案。而今2025年，美国总统竟公然谈论吞并格陵兰岛。真是明智之举。当年这计划看似巨额浪费，成本实在高得离谱。
随后众多欧洲国家向洛克希德·马丁订购F35战机，简直是自摆乌龙。丹麦/格陵兰亦在其中。
不过我扯远了…
Actalis是欧洲企业，确切说是意大利公司，由Aruba控股(虽然后者优劣尚有争议)。
ZeroSSL原属奥地利公司，但据我最新了解，他们已被美国企业收购。
> 我们需要第二个来源，最好位于欧盟境内。
完全同意。感觉美国现政府推行证书相关威权政策的举措只是时间问题。
我甚至开始期待那一天的到来。CA/B机构如此失控且毫无问责机制，而改革意愿又如此微弱，唯有因其无能引发互联网全面崩溃，才能终结这个体制。
要形成实质性问题，LE必须持续瘫痪整整一个月。即便如此，用户仍有充足时间转向其他方案。
核心问题在于：
既然证书签发本质上变成了“你是否控制该域名的DNS”，我认为若最初就按此设计，整个流程本可以简单得多。
虽然我热爱Let’s Encrypt，但借助第三方验证能否生成Cloudflare API密钥实在荒谬(即便.well-known本质上也是“你能否在指定DNS条目上运行Web服务器”的验证)。
编辑：今日学到新知识https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na…
他们竟要放弃客户端证书认证简直疯狂。阅读链接文章后得知，这是因为谷歌要求采用独立的PKI体系，并强制在根证书计划中推行变更。
虽然使用率不高，但这本是个精妙的解决方案。谷歌强推变更只会让大型项目更新证书时增加更多开销。
证书体系具有不同功能。表面看似对称架构实则不然。总体而言，我认为实施这种分离是合理的。
补充说明：我对此事的看法有所转变。
谷歌根本不懂现实世界如何运作。真令人震惊。
他们心知肚明，这不过是挖护城河的策略。
这是临时方案吗？为客户端证书单独部署根证书集有那么困难吗？还是说你指的是整个基础设施都需要复制？
我认为客户端证书是个好主意，不过通常使用与域名证书不同的证书会更实用。(尽管如此我仍认为CA/浏览器论坛机制欠佳，但仍想阐明观点。)
这是有益的改进。我曾见过至少一家公司误配置mTLS，导致其接受任何受信任CA签发的客户端证书，而非仅限内部企业CA签发的证书。
我(部分)认同这是个有益的改动，但理由不同。出于安全考虑，证书应仅包含必需的权限(尽管或许应允许用户在有特殊需求时使用包含全部权限的证书——如我之前所言，通常无需如此，因为用户更可能选择使用不同证书)，可惜当前机制并不支持这种灵活性。
是否该清除所有曾被错误配置的项目？
我不介意？
但此情况下的优势确实远超常规情形。
那我们干脆废除计算机算了，不过不确定这样能否改善现状。
我明白这是好事，但在缺乏优质/可靠NTP时间更新的系统上我曾吃尽苦头。
此外，在生命周期曲线的某个节点，收益会开始递减。私钥被盗的场景本就罕见，即便发生，黑客也难以维持超过几周的访问权限。
依我浅见，若CA/B等自封领导者执意如此推进，是时候重新审视PKI的运作模式了。或许我们不应再将LetsEncrypt视为传统CA，而应将其(及类似服务)定位为实时信任促进者？若验证核心仅需确认服务器控制权，那么采用近实时协议完成验证、签发证书并立即部署至Web服务器或许才是理想方案？当然这需要诸多配套变革，但具备可行性。
不久前，极短的DNS生存时间(TTL)同样遭遇过类似质疑。或许证书有效期应与DNS生存时间绑定——服务器以更高频次进行续期(例如：若TTL为1小时，服务器每15分钟续期一次)。
关键在于，现有系统可能并非测试低有效期策略的最佳环境，但可通过创新方案实现该目标。
> 我知道这是好事，
强烈反对。
增加系统复杂度鲜少提升其健壮性，主要只会增加成本。
为何需要精准计时才能实现？
并非要求精准，但例如若距上次更新超过一天，我就会在多个站点(包括几乎所有使用Cloudflare的站点)遇到错误(假设你指的是我最初提到的问题)。
其中一个问题场景是：从历史快照恢复的机器立即开始运行时，若NTP日期自上次快照后未更新就会出问题(尽管快照在每日运行后都会更新)。多数网站不会崩溃(尤其在24小时窗口内，但更长时间总会出问题)，但如今频繁更新证书的网站数量已使此问题持续存在。
即便使用十年期证书，若访问时机不当仍会出错。不同的是，这种情况已不再是十年一遇，有时甚至几天就会发生。
或许若能将TLS客户端向操作系统请求时间更新标准化，同时让NTP客户端守护进程支持该机制，问题会缓解许多？
若24小时内时间漂移已严重到影响证书信任，说明系统存在严重问题。
我的情况更像是“系统仍认为是昨天，直到ntp守护进程在恢复后1-5分钟更新时间”。在证书寿命如此短暂之前，落后一天其实影响不大。
我从未遇到过这种情况；你是在没有板载实时时钟的系统上运行，还是通过ntpdate进行周期性更新之类的操作？
最接近这种情况的可能是树莓派，但即使如此，只要有网络连接，NTP也会迅速同步时间。而在断网期间，我根本不会触发任何TLS证书验证。
根据我的测试，Windows系统响应最快，但恢复后仍会出现约一分钟左右的延迟，期间部分网站会出现TLS错误。
说实话，我更希望浏览器能直接使用NTP而非系统时间。如果CA/B机构打算朝这个方向推进，或许这会是个不错的改进方案？
系统从休眠状态恢复后时间偏差整整一天，这根本就是系统级缺陷，不该指望浏览器通过自身时间源来修复。
Let’s Encrypt可以将证书的“notBefore”字段设置为过去一小时来补偿时钟误差。一小时的补偿余量完全足够。
我可能没能清楚说明自己经常遇到的具体问题：如果系统离线一天，时间就会偏移一天。除非你假设电池供电的硬件时钟始终可用，且时间/ntp守护进程能及时检测并快速更新时钟。
我的使用场景并非特例，若涉及嵌入式设备，限制条件想必更为严苛。将notBefore设置为一天而非一小时甚至一周，真的会有那么大的差异吗？或许在缩短notAfter时，应相应延长notBefore。
> 除非你假设电池供电的硬件时钟始终可用，且时间/ntp守护进程能及时检测并更新时钟。
并非“且”，而是“或”。硬件时钟是默认存在的，但若缺失时钟，操作系统有责任在引发故障前修复时钟。
一小时的缓冲期已相当宽裕。延长至一天或一周会变得荒谬，且几乎无人受益。
当今绝大多数消费级笔记本/台式机等设备都配备实时时钟(RTC)，因此确实存在电池为RTC芯片供电，使其在关机/休眠后仍能保持时间基本准确。
你完全正确，但这个极少数群体究竟有多小？
真正让我不快的是，这种思维模式在谷歌这类公司中屡见不鲜——他们总以“仅0.1%用户受影响”为由推行变更，但0.1%乘以十亿用户就是百万级规模。
我并非反对你的观点，或许受影响的只有我一人，这种情况下确实无足轻重。但Let’s Encrypt如今已是关键服务提供商，不该像商业机构那样计算影响——后者因无收益影响便可无视用户。
若我要求TLS客户端时钟精度纳入规范，且此类变更需版本升级，这算不算过分？或许有些极端，但当数十亿系统使用的组件变更时，我们如何确保稳定性与可靠性？CA/B机构是否应为所有人(包括少数群体)决策？浏览器厂商会关心某些物联网设备停止工作吗？
我们可通过RTC和NTP保障稳定性。此处的少数群体是指在NTP未就绪时尝试执行TLS操作的无RTC系统。解决方案是将NTP提前至依赖树更早位置，或直接等待一分钟。
我不愿看到CA机构因1%用户作出的软硬件权衡，而延迟为99%用户实现的安全收益。
既然你比我更了解情况，我在此让步。我认为安全收益不值得为极少数人牺牲哪怕微小的便利。
我们追求的是无处不在的TLS隐私保护。结果却变成每个网站都需要半集中化权威机构的持续认证才能访问。所有站点都处于“默认失效”状态。
这在许多方面比纯HTTP时代更糟糕，而我们现在甚至无法回头。
> 结果是每个网站都需要获得某个半集中化机构的持续许可才能保持访问状态。
能否举例说明哪些网站曾被免费ACME证书提供商封锁？
若您指的是证书过期网站在跳过重重障碍并忽略警告后仍可访问——没错，您说得对。
或许这只会让大家养成像点击GDPR弹窗那样忽略SSL警告的习惯——无论好坏。
请勿错过DNS-PERSIST-01挑战介绍及相关变更：https://letsencrypt.org/2025/12/02/from-90-to-45#making-auto…
虽未最终定案，但发展动向值得关注。
所以他们要通过增加步骤来重构DANE？
将有效期缩短至45天的意义何在？
为何不设为60秒？这显然更安全。毕竟所有流程都已自动化，何必让证书在45天这么长的时间内暴露风险？
或者每次请求都签发新证书？这样应该能消除大部分风险。
虽然我认为你发问更多是出于沮丧而非真正好奇，但有两点值得说明：
其一：相关论证大多可查阅。此前已有大量讨论。若你真有兴趣，建议从CA/B邮件组入手。部分讨论也收录在MDSP(Mozilla开发安全政策组)存档中。
二：需谨记几乎所有安全相关讨论的核心矛盾在于安全与易用性的平衡。显然，60秒的有效期完全不可用。目标是让安全与易用的重叠区域尽可能扩大。
严肃问题：或许不是60秒，但为何要45天而非约1天甚至几小时？45天周期几乎必须自动化处理。
我们内部CA运行72小时TTL，因为五六年前觉得“何乐不为”，如今大家都固执得停不下来。你难以想象有多少软件在证书处理上存在缺陷。
从老旧系统如libpq(仅在建立连接时加载证书，据我所知这样就能运行)到某些JS或Java库(启动时将证书读入主内存后就再也不处理)，问题层出不穷。还有些软件将“SIGHUP时重新加载证书”的功能请求，折腾成“哦，让监听线程在收到SIGHUP时透明地转接监听套接字”——后者难度太大，结果两项都不了了之。
45天过渡期对老旧系统将是巨大折磨。即便用现代框架，两周内完成也极其痛苦。就连Spring框架直到一两年前才正确处理这个问题，我们不得不长期保留内部临时解决方案。
坦率地说：因为基础设施尚未准备好支持1天有效期的证书。如果证书仅有效一天，而续期在周六失败，那么你的网站将无法使用，直到周一上班后采取补救措施。虽然可通过支持多CA回退的ACME客户端等方案缓解风险，但当前绝大多数网站尚未做好应对准备。
CA/BF联盟采用47天证书的初衷，既是强力推动自动化，也为自动化失败时预留人工干预的缓冲期。
7天有效期的证书很快就会出现[1]。
[1]: https://letsencrypt.org/docs/profiles/#shortlived
他们并非如评论所言的虐待狂。
不过为了满足受虐狂的需求，他们很快会推出6天有效证书作为选项。
没错，“短效型”(6天)证书配置文件将于本周晚些时候向公众开放。但现阶段我们明确建议仅成熟组织采用该配置——需具备稳定基础设施和轮值机制，因假期长周末期间证书续期失败的风险对多数站点而言过于高昂。
异步吊销检查才是更优方案；遗憾业界放弃了这项技术。
该文多处引用另一篇文章，阐述了撤销检查无法兼顾隐私(本质上等于向他人透露浏览记录)与可靠性(若CA的撤销检查器故障怎么办？)的原因。
本可继续使用OSCP钉接机制
OSCP会导致用户访问的每个网站都被追踪；详见https://news.ycombinator.com/item?id=46290033
但OP提到的OSCP钉接机制本应解决这个问题。
本质上OCSP钉接(更准确说是强制钉接)与短效证书具有同构性。
你知道最初计划是缩短到17天吗？！而且我认为这个方案仍在计划中。
坦白说，问题不在时限——证书本可每日生成，自动化手段也多得很。症结在于证书信任日志提供商们会彻底崩溃！
当前证书总量已达240亿，可追溯至2017年左右的爆发期。全球约有45亿个独立域名，若按域名数量计算证书需求，当前实际需23亿个域名证书。
现在计算23亿乘以8次续期…这意味着CT日志每年仅需新增约184亿个证书。考虑到LE证书的普及程度，实际增长量可能达到每年100亿(包括仍使用1年或多年期证书的用户，以及海量生成的LE证书)。
请注意，我提到自2017年以来的总证书量目前仅为240亿…是的，CT日志中的证书数量每两年就会接近翻倍。
这还假设LE不会缩短至17天有效期——若真如此，我敢说每年增长量将达到当前的两倍。
作为CT日志服务商，祝你好运…顺便提一句，单个证书存储约4.5KB，这意味着每年需45TB存储空间，若有效期缩短至17天则需100TB以上。这还没算数据库、CT日志流量等成本…
系统已经崩溃了吉姆… 试想每日签发证书的情景… CT日志存储量将达每年1700TB？
谷歌等巨头必将推出新系统，因为即便对它们而言，现有成本也即将失控。
您是否听闻过默克尔树证书[1,2]的利好消息？该技术将透明度密码学直接融入证书签发流程，带来多重优势，其中之一便是大幅缩减透明度日志体量。
1: https://www.youtube.com/watch?v=uSP9uT_wBDw 详解其工作原理及优势的优质教程。
2: https://davidben.github.io/merkle-tree-certs/draft-davidben-… 当前工作草案
没错…可节省约40%资源，我见过其中一个实现方案。这里偶尔发帖的某位成员已拥有可运行版本。
作为CT日志操作员，我全力支持短期证书。自动化与短生命周期能解决WebPKI的诸多痛点。
存储需求完全可解决，这不成问题。
长期过期证书的永久CT日志真有重要用武之地吗？
研究者、黑客等群体需要海量信息…它能展示域名历史，发现隐藏子域名、仍在活跃的域名、已撤销的域名等等…
别忘了不久前我们还存在有效期长得离谱的证书。
核心问题在于当前撤销证书并不容易，因此你几乎被迫保留证书历史记录，尤其当证书在CT日志中被撤销时。
理论上，若强制所有人每47天更换证书，确实能实现永久撤销。但这需要用户端高度自动化。目前仍有大量软件依赖手动添加的单年或多年期证书。这也是为何47天周期的过渡期长达四年。
即便如此，CT日志提供商仍将面临验证请求量激增的巨大压力。
> 这里蕴藏着海量可供研究、黑客利用的信息…它记录着域名的历史轨迹，可发现隐藏的子域名、仍在运行的域名、已被撤销的域名等等…
这类信息存储空间需求极低，无需在每次续期时重复记录。
> 核心问题在于当前撤销证书操作过于繁琐，迫使证书必须在CT日志中保留完整历史记录。
该机制基于活跃证书数量设计，与证书实际有效期几乎毫无关联。
> 仍有大量软件依赖手动添加的单年或多年期证书。
希望未来这类情况会逐渐减少。
> 但这仍无法改变验证请求激增对CT日志提供商造成的冲击。
我不太清楚具体机制，但确实需要有人为此买单。
17天这个数字从何而来？
CA/浏览器论坛曾讨论证书过期机制，当时考虑过17天的方案。45天是折中方案，但17天方案始终未被排除，仍作为未来备选方案保留。
坦白说不记得讨论过17天方案，但可能记错了。47天之所以是“折中方案”，在于它采用数年渐进式缩减，而非一次性从397天骤降至90/47天甚至更短。
怀念当年能随意搭建Apache服务器，任其无人打理运行十几年甚至二十年的日子。
如今即便是最微小的项目，也总伴随着突如其来的系统管理任务——比如毫无预告的强制HTTPS证书更换。
这种状况令人沮丧，我认为它正加速着互联网非商业领域的消亡。
刚查了下，我有个网页服务器运行了845天，上次登录还是去年5月2日。根据shell历史记录，我确信自2020年左右配置完Let’s Encrypt后就再没碰过它。
我同意，不过静态网页最简单的托管方式似乎还是用S3存储桶配合CloudFront之类的方案。
请在90天内接受新版条款，否则账户将被注销…
双因素认证现已强制实施。
请通过第三方身份验证服务完成身份验证，以确认您未被列入制裁名单。否则账户将被冻结。
诸如此类。每项第三方服务都需要投入些许精力和脑力。
关于生命周期缩短已有不少讨论，但mTLS变更却鲜少提及。是否有人遇到相关问题？我们也将受此影响——目前采用mTLS作为客户验证webhook的多种方式之一，但尚未确定应对方案。
服务器向客户端提供的证书与服务器期望从客户端获取的证书无需共享同一CA。
此情况仅影响以下场景：若您的服务器配置为使用Let’s Encrypt根证书(或系统中所有受信任CA)验证mTLS客户端。当您将certbot或其他CA签发的主机HTTPS证书作为mTLS客户端证书使用时，可能需要进行此类验证。
您仍可自行生成mTLS密钥对，并用于通过Let’s Encrypt验证主机的连接进行身份验证——这正是多数用户的实际操作方式。
> 服务器向客户端提供的证书与服务器期望从客户端获取的证书无需共享CA。
确实如此，但所有CA似乎都停止签发包含客户端EKU的证书了。至少Let’s Encrypt和DigiCert如此，因为根据谷歌要求它们不能同时签发此类证书和常规证书，而且我猜市场需求不足以支撑专门为此设立的CA。
> 若使用Certbot或其他CA签发的主机HTTPS证书作为mTLS客户端证书，这种做法可行
当然，这有什么问题吗？
> 你仍可自行生成mTLS密钥对，用于验证通过Let’s Encrypt验证主机名的连接——这正是多数人的做法。
这能让客户端验证主机身份，但服务器无法识别连接来源。生成mTLS密钥对意味着需要绑定证书、协调轮换等操作。当前服务器只需维护最新的CA存储库(这很常见且简单)，并检查主体名称即可，从而让客户端能轻松轮换证书。
我认为服务器使用相同证书颁发机构(CA)对客户端认证可能并无实际意义——除非你仅关注域名验证(但这本不该成为核心需求；况且许多客户端甚至没有域名)。
但若确实需要使用CA签发的证书，可忽略证书中的部分字段。
> 可忽略证书的部分字段
多数软件并不支持忽略约束条件。虽然能实现，但很可能需要修改TLS库的验证逻辑，甚至更糟的是必须编写自定义验证代码。
我曾用C语言编写过解析X.509证书的程序(部分完成)，但缺失的是加密功能(用于验证签名，并需提取公钥供独立TLS实现使用)。(我原本还计划实现生成X.509证书的功能，这同样需要加密模块来生成密钥对和签名。若能找到合适的加密库，此类功能应单独封装。TLS也应采用独立库实现(OpenSSL逻辑混乱，我希望自定义证书处理逻辑，但OpenSSL的实现方式令人难以实现)。)
> 当然可以，这有什么问题吗？
原则上没问题。你可以用它验证域名所有权，或把Let’s Encrypt当作集群的特殊认证服务。不过据我所知，这种做法并不常见。
> 目前服务器只需维护最新的CA存储库(这很常见且简单)，检查主体名称即可，这样客户端就能轻松轮换证书。
我理解这种方法的便捷性，但它会让认证机制完全暴露在恶意证书的风险下——比如子域名的旧DNS记录、误让他人读取发往hostmaster@domain.tld的邮件，或者如果你想往阴谋论方向想的话，还可能被恶意CA利用。
至于证书绑定：反正你都需要选择密钥库，直接指向任意CA文件即可。
关于自动轮换：可自行部署ACME服务器创建CA(Caddy配置仅需十行代码)，再让其他服务器将certbot/acme.sh等工具账户指向该服务器。这能提供更强控制权，并自主决定证书有效期。
虽然不如依赖CA验证那么简单，但远比过去的手动密钥配置方式高效得多。
我们为MTLS使用本地生成、不同有效期的证书。依赖公共CA构建信任链总让我感到不安，尤其当证书被吊销时。
请问——如果使用公开信任的TLS服务器证书进行客户端身份验证…你到底在验证什么？仅仅是验证某人持有可追溯到通用信任存储库中信任锚点的证书？(也就是说你的验证方式只是确认对方有互联网连接，或许还有读取能力)
要是有人觉得用DANE分发自家根证书是个好主意，那可就太有意思了…
>若您本周向我们的TLS服务器或短效配置文件申请证书，将开始收到源自Generation Y体系的证书。此次切换同时标志着Let’s Encrypt短效证书的正式开放(含证书IP地址支持)。
这是否意味着IP证书将在本周某时全面开放？
现所有服务器均可参与加密客户端问候(ECH)以增强用户隐私：当客户端通过ECH建立TLS连接时，若服务器IP地址出现在ClientHelloOuter字段，目标SNI域名位于加密的ClientHelloInner字段内，窃听者将无法读取用户实际连接的域名。
该方案需实现以下多个发展阶段才能真正提升用户隐私：
据我所知，其他提供免费层级的CA(zerossl、ssl.com、actalis、google trust、cloudflare)均要求用户注册账户(这意味着你受制于他们)，且多数将免费证书数量限制在极低水平，完全不提供免费通配符证书。
LE确实无可替代。
> 这意味着你受制于他们
即使没有注册账户，Let’s Encrypt也可能轻易拒绝为特定域名签发证书。我认为两者并无本质区别。
AWS证书管理器通过DNS验证为你处理所有流程。
诚然，你将被锁定在他们的生态系统中，无法导出公钥等，因此这远非完美解决方案。但从“我需要运行个人网站且不想操心证书”的角度来看，该产品确实令我印象深刻。当然，你是在为证书付费，只是并非直接支付。
不过我完全赞同你的观点。
最终费用是多少？我对个人域名的成本很感兴趣。
我几乎要考虑回归HTTP了。实施如此颠覆性的变更时，理应给“客户”保留沿用旧方式的选项。我手头事务已堆积如山，实在不需要Let’s Encrypt这类服务再添麻烦。
好奇问下…之前见过CA根证书用X1/X2命名法。有人知道这个命名规则的起源或依据吗？
现在出现了“Y”代，但当初设计“X”代的人似乎没预见到会超过三代，否则就会用A1/A2了。
问得好！据我所知，我们的首个根证书(ISRG Root X1)采用该命名方案，纯粹因为它被IdenTrust根证书(DST Root CA X3)交叉签名，而该证书恰好使用相同方案。至于他们从何处借鉴此方案，我就不得而知了。
用Y表示“下一代”根证书的方案，是我去年筹备YE/YR仪式时构思的，因此绝非初代根证书命名时的考量。
对于担忧自动化难度的朋友们，这是我团队过去一年持续推进的工作：
https://www.certkit.io/certificate-management
您只需将acme挑战的DNS解析指向我们，我们便为您管理所有证书。我们提供API和代理程序将证书推送到所需位置，并实时监控Web服务器是否运行正确证书。实现端到端可审计性。
经历几次Let’s Encrypt证书失败(几乎肯定是我自动续期设置的问题)后，我转而使用Cloudflare的15年免费证书，从此再也不用操心续期问题，非常满意。
这确实明智，但好日子到头了。现有15年证书在有效期内仍被接受，但到期后你将不得不重新申请证书，届时就和我们其他人一样陷入45天周转的困境了。
Cloudflare的15年证书是其私下签发的，仅用于验证你的源站身份。来自网络的连接证书则由Cloudflare统一管理。
如果最终客户端开始拒绝过长的证书，我一点也不惊讶。试想有人购买了域名，但前任所有者仍持有有效期长达15年的证书。
至少在新方案下，若域名闲置45天，你就能确定只有自己持有该域名的有效证书。
若我需要客户端证书，听起来LetsEncrypt将不再提供此类证书
> 由于根证书计划即将实施的新要求，这些新中间证书不再包含“TLS客户端认证”扩展密钥用途。我们此前已宣布计划自2026年2月起终止TLS客户端认证功能，该时间点将与切换至Y代证书体系同步。
因此我们通过固定IP/PTR/DNS验证机制，基于此进行服务器间连接认证以对接第三方服务。
若未设置客户端认证位，该证书将无法用于外发连接。
替代方案是什么？
不明白为何要淘汰TLS客户端证书，理解将其移出默认配置文件(它们确实不该出现在那里，最初为何存在也不清楚)，但完全不提供获取途径就有些荒谬了
疑问：当管理大型基础设施时，是否存在优秀的集中式ACME证书管理工具？在高可用性、多地域环境中，直接在每个实例或位置运行ACME客户端显然不合理。
对此方案难以定论。当前每台IT设备都需处理证书已令人头疼。除非创建并管理自有CA机构(这本身就是额外负担)，否则这种方案有何意义？只会增加更多蹩脚脚本和麻烦，收益微乎其微。
下一步要强制邮件签名用SMIME或PGP吗？
我曾深耕PKI领域，如今已鲜少关注。
两个快速问题：
1 – 是否有TLS库能在证书临近过期时触发警告？
2 – 是否存在(或曾尝试过)TLS扩展方案，让客户端验证下期计划证书，并在验证失败时向双方发送信号？
据我所知，问题2的答案是否定的。
2000年代初我曾作为承包商与威瑞信合作，亲眼见过当时签发全球大量证书的系统和基础设施。十五年后我在谷歌任职时，公司因SMTP证书的中间证书过期导致Gmail大规模瘫痪。上周我们公司也因证书问题遭遇重大故障。当然，其间类似案例不胜枚举。
PKI构建的信任链对保障代码、数据和流量安全确实功不可没，但它至今仍存在如此脆弱的故障模式，着实令人费解。
从安全角度看，整个体系本就荒谬至极。
好吧，假设证书泄露了。泄露1.5个月和90天相比，危险性真的会大幅降低吗？不，从泄露第一天起你就完蛋了，这比“浏览器异步检查站点证书是否被吊销”的方案糟糕得多。
何时才能实现多厂商联合签发的证书？
我理解正确吗？我将能为IP地址获取证书？
没错！本周晚些时候将向公众开放(只要你使用的ACME客户端能配置为请求特定配置文件)。
相关说明：
证书有效期缩短至45天
https://news.ycombinator.com/item?id=46117126
Let’s Encrypt，你们连营利性企业都算不上；根本无需顾忌任何人的反应。直接声明“为遵守CA/浏览器论坛规则，我们将缩短证书有效期”即可。何必在标题里玩这种懦弱的“用’变更’替换’降低’”文字游戏。
公告涉及多项变更，并非仅限于证书有效期调整。
这完全说不通。互联网上大量开源/非营利项目同样影响深远。当然应该提前告知依赖你们服务的用户。
GP批评的是标题用词，而非公告本身。
另外，发言人站在灌木丛前。
不知为何，我见过所有类似场景的企业宣传照里，人物都站在灌木丛前。这似乎是加州特色？
(我住的地方，灌木丛一年只有半年长叶子)
“别在办公室里拍你的照片，因为大家都讨厌办公室内部。我们改在办公室外边拍，靠近办公室但别把办公室拍进去。噢，那边那棵树挺好，但该死，树枝下的光线不太理想。嘿，那边的树篱在光照测试中效果很好，而且和你穿的衣服很搭，所以，嗯，就选那里吧。”
其实是在我光线很差的小公寓外拍的
播音员马修·麦克弗林是本站常驻评论员(也是位正直可靠的信息安全领域深度从业者)。