ssl - 为什么选择 398 天作为 TLS 到期日？

Question

苹果最近宣布计划将 TLS 证书的有效期降低到 398 天。这一变化随后被Google和Firefox反映

我了解减少 TLS 证书到期的所有正当理由。CA 当局历来不擅长撤销受损证书，多亏了Let's Encrypt 之类的工具，您现在可以每月免费轮换您的证书，并自动使用 cronjob，频繁更改 TLS 证书意味着攻击者试图解密记录的 HTTPS 流量将如果他成功只有有限的信息窗口，并且他发现的密钥在该有限窗口之外将无用（增加计算资源以破坏 HTTPS）等

我不明白为什么 398 是商定的持续时间。似乎随意。为什么不是365？为什么不是400？398是基于什么吗？

标签： sslbrowser

Answer 1

366+31+1 = 398 天

它等于一个闰年+一个月+“处理混乱日期的小空间”。

2017 年，Ballot 185最初提出了 12 个月的新限制，然后将其扩大到 13 个月，即 398 天。

digicert.com 上的 jeremy.rowley：

我喜欢较短有效期的概念，但我建议有效期为 13 个月而不是 12 个月。这样，订阅者可以每年续订一个月的缓冲期。

sslmate.com 的安德鲁：

为避免到期日期每年漂移，续订证书的 notAfter 日期必须正好在当前证书的 notAfter 日期之后一年。由于有 12 个月的限制，CA 只能通过在当前证书到期时发布更新的证书来做到这一点，这显然是不可行的，因为它没有时间进行切换。

相比之下，13 个月的限制将允许 CA 在当前证书到期前最多 1 个月颁发续订证书，有效期为 12 到 13 个月，以使到期日期同步。这要友好得多。

amzn.com 上的 pzb：

当人们正在起草选票时，您能否考虑以天为单位指定间隔并使用间隔的最大情况（假设闰年、长月、闰秒、四舍五入等）？例如，如果要指定 13 个月，请考虑使用 366 + 31 + 1 = 398 天。

google.com 上的 sleevi：

- 根据https://cabforum.org/pipermail/public/2017-February/009449.html中的建议，将 12 个月更改为 398 天

关于 Ballot 185 是否应该限制为 398 天和 400 天，存在一些争议。185 号投票失败，而193 号投票通过了 825 天的限制。2019 年，投票 SC22重新提出了 398 天的限制。

google.com 上的 sleevi：

- 选择 397 天代表对“十三个月”期限的最大合法解释；它是从 366 天（考虑闰年）加上 31 天的月份计算得出的，这是证书使用的日历中最长的一个月。

apple.com 上的 cspann：

Apple 支持这一提议，并将通过在实施说明中的一些额外说明或对部分日期模糊问题的其他一些解决方案予以支持。

google.com 上的 sleevi：

我一直在考虑如何明确这一点，我很好奇以下内容是否会解决这个问题：
- 将最长有效期定义为 398 天，而不是 397
- 将有效期的要求更改为 CA 应该不颁发有效期大于 34300800 秒（即 397 天 86,400 秒）的证书，并且不得颁发有效期大于 34387200 秒（即 398 天 86,400 秒）的证书。
- 这试图以秒数明确定义有效期
- 但为了考虑闰秒、时区变化和“合理”错误，将 MUST NOT 设置为 398 天。任何使用 397 天正确实施其系统的 CA 都很难违反 MUST NOT，但这为处理日期的混乱提供了一点空间。

https://github.com/cabforum/documents/pull/138/commits/b74a038cc492e1ba4f087e7db94494e99f609070

根据 Apple 的反馈更新 BR

* 通过以秒为单位进行定义来避免对天数的歧义 * 不得将天数
增加到 398 天，而不应将天数增加到 397，以希望引导 CA 正确实施

Ballot SC22 failed ，但它被Apple采纳为新要求：

在 2020 年 9 月 1 日 00:00 GMT/UTC 或之后颁发的 TLS 服务器证书的有效期不得超过 398 天。

• 398 天是用一天等于 86,400 秒来衡量的。任何超过此时间的时间都表示额外的有效日期。
• 我们建议颁发的证书最长有效期为 397 天。

398 天的要求和 397 天的建议后来被纳入选票 SC31 ，最终通过（经过大量的斗争）。

2020 年 9 月 1 日或之后颁发的订户证书的有效期不应超过 397 天，且有效期不得超过 398 天。