摘要

  • Let’s Encrypt 在 2015 年 11 月 9 日宣布 90 天上限，建议每 60 天续期；它把这个期限同时用于缩短泄露密钥或误签证书的有效窗口，并推动自动化。
  • 三天后的公开测试公告称，有限测试阶段已经签发超过 11,000 张证书；公告同时承认，不同平台上的客户端体验仍需打磨。

分析

证书的到期日期平时藏在一份签名文件里，到了网站上却会变成醒目的运营问题。notAfter 是证书自身携带的字段。RFC 5280 把有效期定义为从 notBefore 到 notAfter 的时间区间，首尾日期都包括在内。日期过去以后，旧证书不能靠改日历继续使用，服务必须部署新的证书。

2015 年 11 月 9 日，Internet Security Research Group 执行主任 Josh Aas 解释了 Let’s Encrypt 为什么把最长有效期设为 90 天。他给这条规则安排了两份工作。私钥被盗，或证书误签后，证书保持有效的时间会更短；而续期来得更频繁，也会把自动化从“方便的工具”推成轻松维护 HTTPS 的必要条件。

第 60 天续期的建议让这项设计有了具体刻度。Let’s Encrypt 没有让用户等到最后一天。按 90 天上限计算，管理员大约还剩一个月可以发现失败并手动处理。Aas 当时指出，服务还很新，很多订户也刚开始接触自动化；这段时间就是为必要时的人工续期留出的余地。期限够短，能推动软件接手；又没有短到立即关上人工补救的门。

时间线说明了这项选择所处的阶段。11 月 12 日，Aas 说有限测试从 9 月 12 日开始，到当时已签发超过 11,000 张证书。公开测试计划于 12 月 3 日启动。同一份公告把自动化称为策略的基石，却也承认客户端体验仍要在各种平台上变得顺畅、可靠。签发已有了测试规模，跨平台的续期体验还在建设中。

Let’s Encrypt 的理由说得很直白：不能指望管理员手工处理整个互联网的证书续期。一旦签发与续期自动完成，缩短有效期就不必额外增加站点管理者的日常工作。因此，安全收益和运维模型是同一个决定的两面：证书的时钟走得更快，续期客户端必须把新证书按时送到服务里。

人工处理仍然留有位置，但它是故障后的备用路径。日常运行依赖客户端软件、计划任务、平台兼容性，以及新证书是否真正部署。第 60 天是一条日历提醒；自动化才可能让这条提醒在大规模站点上变成重复、可靠的流程。

测试公告里的数字统计截至 11 月 12 日已经签发多少证书，不统计续期成功或失败的数量。按日期记录的续期成功率可以判断人工缓冲期是否够用；这两份公告没有给出这项记录。

来源