加载失败
本帖围绕 CA/Browser Forum 与浏览器厂商推动将公有 TLS 证书最大有效期降至 45 天的决定展开讨论。推动方逻辑是撤销机制（如 OCSP）在 Web 级别效果有限，缩短证书寿命能减少被滥用的窗口并降低撤销/CRL/CT 的系统负担；应对措施则以 ACME 自动化为核心，并推荐使用 ARI 来调度续签。反对声音集中在遗留设备、B2B 合作与 IoT 等无法快速实现自动化的现实运维问题上，评论同时提出诸多工程缓解措施（如 DNS-PERSIST-01 草案、CNAME 委托、acme-dns、分布式/集中化的 ACME 帐号策略和私有 CA）。社区也在讨论速率限制与 CT 日志成本的实际影响，并指出续期类请求在很多情形下有速率豁免而 LE 正在改进相关配额与自动化支持。
支持者认为将公有证书最长有效期降到45天可以强制推动 ACME 自动化，从而缩短密钥被滥用的暴露窗口并简化 WebPKI 生态。评论多次提到 Let's Encrypt 显著改善了 WebPKI，且 GlobalSign、Sectigo、Digicert、Google Trust Services 等 CA 也支持 ACME，已有部署的自动更新在实践中稳定运行、几乎没有 TLS 故障的实例被举例说明。LE 还有 6 天的短期 profile 可用于压测或立即获得快速轮换的安全好处，行业与浏览器的基线要求正推动把上限逐步下调，客户端按证书寿命的约2/3触发续签被认为是合理的操作方式。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
反对者与担忧者强调企业与遗留环境、B2B 集成、IoT 设备等在现实中难以快速实现或信任自动化：有评论列举 certbot 与包依赖、PKCS#12/PEM 转换脆弱、操作系统/包锁定导致无法升级客户端的具体故障场景，会让自动化在关键时刻失效。短期寿命缩短了从发现续签失败到证书过期之间的“救援窗口”（比如按2/3续签策略可能只剩约28–30天），增加了在假期冻结窗口或审批流程缓慢时出问题的概率，并可能触及速率限制或需要与会计/销售谈合同的额外成本。多人举例 B2B 合作方仍需手动安装证书、IoT 网络差导致无法自动续期等具体运营痛点，说明转换并非仅是技术改动而是组织与流程问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论细节讨论了可减轻短期证书带来麻烦的协议与工程手段：草案 DNS-PERSIST-01（评论中提到预计 2026 可用）允许用于 DNS-01 验证的 TXT 记录在续期间保持不变，从而避免每次写 DNS。社区还提出用 CNAME/_acme-challenge 委托到受控区、使用 acme-dns、或向 DNS 提供商申请仅限 TXT 的 API token 来减少对生产 DNS 的影响；ZeroSSL、Google 等提供 ACME 服务作为备选。关于速率与调度，评论指出“看起来像续期”的证书通常免于某些速率限制，且 LE 推荐使用 ARI（ACME Renewal Information）来帮助客户端准确调度续签时间。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
关于应用层的证书钉扎，评论普遍反对钉扎公有叶证书，因为这会把应用绑定到第三方 CA 的中间链选择上而变得脆弱。建议的应对包括钉扎公钥（SPKI）并重用私钥以减少客户端更新频率，但评论也指出这会违背短期证书降低私钥暴露窗口的初衷；另有建议运行私有 CA 并钉扎该 CA、或者提前生成并分发未来的 CSR/公钥以便预置钉扎条目并保留备用键。评论还提醒钉扎中间 CA 有风险（CA 可能更换中间证书），并主张同时监控 CT 日志、保留备选公钥/CA 以便在被撤销或误发时快速恢复。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
许多评论把这次变更放在更大的系统性背景下：撤销机制（OCSP）被认为在 Web 级别不可依赖，因此业界采用缩短证书寿命来代替频繁撤销。短期证书会增加写入 Certificate Transparency（CT）日志的条目数，评论讨论了 CT 运营成本与像 CRLite 这样的压缩/过滤技术对缓解日志膨胀的作用。关于速率限制，评论引用了 LE 的发行上限（例如每 7 天每注册域/IPv4/IPv6 /64 的证书数限制）并指出续期类请求在很多情形下有豁免，LE 也在努力改进速率限制与自动化的配合。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
关于多节点/分布式网站的实际运维，评论列举了几种常见做法：一是由单节点持有 ACME 帐号并生成/分发证书（简单但会复制私钥）；二是集中代替签发 CSR 的节点执行 ACME 流程以避免私钥传播；三是每个节点各自注册 ACME 帐号并独立续期（最独立但可能遇到注册或速率限制）。选择哪种方式与使用哪种挑战类型密切相关：DNS-01 更适合把 DNS API 密钥集中管理或使用 CNAME 委托，HTTP-01/TLS-ALPN-01 则要求前端/负载均衡层有控制权。对于网络条件差或无法访问公有 CA 的 IoT 设备，多数评论建议采用私有 CA 以便控制有效期和发行流程。
ACME: ACME（Automatic Certificate Management Environment）是一套自动化获取与续期公开 TLS 证书的协议，客户端（如 certbot、acme.sh、acmetool）通过 ACME 与 CA 完成挑战验证并自动颁发证书。
DNS-PERSIST-01: DNS-PERSIST-01 是一项 ACME 扩展草案，允许使用在多次续期间保持不变的 DNS TXT 条目来证明域名控制，从而避免每次续期都修改 DNS；草案在讨论中提到预计 2026 可用。
ACME Challenge Types（HTTP-01 / DNS-01 / TLS-ALPN-01）: HTTP-01、DNS-01、TLS-ALPN-01 是 ACME 常见的验证方式：HTTP-01 在 /.well-known/acme-challenge/ 提供 token；DNS-01 在域的 TXT 记录写入 token（适合 wildcard 与多节点）；TLS-ALPN-01 在 TLS 握手层响应特定 ALPN 挑战。各方式对自动化、部署边界与 DNS 权限需求影响不同。
ARI（ACME Renewal Information）: ARI 是一种通过 ACME 向客户端传达何时需要续签的元信息，用于帮助客户端正确调度续签任务以避免到期。
Certificate Transparency（CT logs）: Certificate Transparency 是一套公开、可审计的证书日志系统，所有公有证书都会被记录到 CT 日志以便检测误发；短期证书增加了写入量，会影响日志运营成本与索引负担。
PEM / PKCS#12: PEM（文本编码）与 PKCS#12（.p12/.pfx 二进制容器）是常见的证书与私钥封装格式：PEM 常见于 Unix/nginx，PKCS#12 常用于 Windows/Java，需要 openssl 等工具在两者间转换。
CA/Browser Forum Baseline Requirements: CA/Browser Forum 的 Baseline Requirements 是约束公开 TLS 证书技术与生命周期的行业规范，浏览器与 CA 基于该规范协作调整最大证书寿命（本次 45 天上限即源于该工作组的要求）。
OCSP: OCSP（Online Certificate Status Protocol）用于在线查询证书撤销状态，但在大规模部署中存在可用性、性能与隐私问题，因此业界部分观点认为其在 Web 级别不可靠，从而倾向于通过缩短证书寿命来减少撤销依赖。