为什么有些网站如此频繁地更改 SSL 证书？

Question 1

但是 superuser.com 发生了什么事？他们提前 70 天更改了证书，只是为了给他们额外的 20 天？为什么这样做？

您可能正在查看两个不同的服务器（负载平衡），它们彼此独立地更新其证书。

（这里的关键点是服务器更新自己的证书。系统管理员不需要手动获取证书并进行轮换。因此，不同的服务器可能拥有不同的证书，并在不同的时间更新它们，这不是问题。）

也可能是管理员做过由于上周五 Let's Encrypt 验证链出现问题，因此故意发起续订（例如，尝试切换到两个可用链中的不同链，并且执行续订是实现此目的的更简单方法，而不是手动摆弄证书）。例如，我知道我确实在我自己的服务器上使用certbot renew --force-renew，以便 Certbot 设置 ISRG-as-root 链而不是 DST-cross-sign 链。

我的问题更多针对的是像 Google 和 YouTube 这样的网站，所有的 Google 网站确实都这样做，他们似乎疯了，每个月都会提前随机更改。

说到 Google 和 YouTube，现在你确实正在查看几台处理其自己的证书的不同服务器。

据我所知，早在 Let's Encrypt 实现证书自动化之前，Google 就一直在推动证书自动化。他们甚至有文章讨论如何利用自己的 CA (GTS) 实现自动、短期证书。（不幸的是，我再也找不到这些文章了。）

他们几乎每个月都会更换

是的。你没有具体说明为什么这是个问题。

我的意思是，你已经必须信任 CA 能够正确颁发证书，无论它是每周一次还是每年一次。你已经无法知道任何给定的更改是否合法。

每当您看到证书突然更改时，您无法区分管理员点击“强制续订”或从旧 Web 服务器迁移到新服务器与发生恶意事件，仅凭证书不同这一事实。您所做的只是“警报疲劳”。

加密领域是否发生了什么事情，导致 RSA 4096 一年内不再适用？

撤销，或缺乏撤销。

例如，如果证书被盗用（例如，您的网络服务器遭到黑客攻击），则很难可靠地撤销它。让浏览器定期下载每个 CA 的 CRL（撤销列表）在实践中效果并不好，尤其是在电池寿命有限或只读存储的设备上。（由于 CRL 必须继续列出已撤销的证书，直到其自然到期，因此它们可能会增长到数十兆字节！）

让浏览器通过 OCSP 与颁发者进行核对既是隐私问题，也是可靠性问题。（想象一下，每次有人访问使用 SomeCA 的任何网站时，SomeCA 都会收到通知。再想象一下，一旦 SomeCA 出现故障，所有这些网站都会因为无法执行撤销检查而无法访问。）Mozilla 尝试了集中聚合的“OneCRL”，但尽管这可以解决一些问题，但无法解决下一个问题。

另一个问题是，域名被撤销时，这些证书不会被撤销。假设某人获得了一个域名的 3 年证书，然后几周后将该域名卖给了你。那么，他们仍然拥有该域名的 3 年证书！

因此普遍的观点是，证书的有效期不应该那么长——很可能是几周，而不是几年。

Answer

但是 superuser.com 发生了什么事？他们提前 70 天更改了证书，只是为了给他们额外的 20 天？为什么这样做？

您可能正在查看两个不同的服务器（负载平衡），它们彼此独立地更新其证书。

（这里的关键点是服务器更新自己的证书。系统管理员不需要手动获取证书并进行轮换。因此，不同的服务器可能拥有不同的证书，并在不同的时间更新它们，这不是问题。）

也可能是管理员做过由于上周五 Let's Encrypt 验证链出现问题，因此故意发起续订（例如，尝试切换到两个可用链中的不同链，并且执行续订是实现此目的的更简单方法，而不是手动摆弄证书）。例如，我知道我确实在我自己的服务器上使用certbot renew --force-renew，以便 Certbot 设置 ISRG-as-root 链而不是 DST-cross-sign 链。

我的问题更多针对的是像 Google 和 YouTube 这样的网站，所有的 Google 网站确实都这样做，他们似乎疯了，每个月都会提前随机更改。

说到 Google 和 YouTube，现在你确实正在查看几台处理其自己的证书的不同服务器。

据我所知，早在 Let's Encrypt 实现证书自动化之前，Google 就一直在推动证书自动化。他们甚至有文章讨论如何利用自己的 CA (GTS) 实现自动、短期证书。（不幸的是，我再也找不到这些文章了。）

他们几乎每个月都会更换

是的。你没有具体说明为什么这是个问题。

我的意思是，你已经必须信任 CA 能够正确颁发证书，无论它是每周一次还是每年一次。你已经无法知道任何给定的更改是否合法。

每当您看到证书突然更改时，您无法区分管理员点击“强制续订”或从旧 Web 服务器迁移到新服务器与发生恶意事件，仅凭证书不同这一事实。您所做的只是“警报疲劳”。

加密领域是否发生了什么事情，导致 RSA 4096 一年内不再适用？

撤销，或缺乏撤销。

例如，如果证书被盗用（例如，您的网络服务器遭到黑客攻击），则很难可靠地撤销它。让浏览器定期下载每个 CA 的 CRL（撤销列表）在实践中效果并不好，尤其是在电池寿命有限或只读存储的设备上。（由于 CRL 必须继续列出已撤销的证书，直到其自然到期，因此它们可能会增长到数十兆字节！）

让浏览器通过 OCSP 与颁发者进行核对既是隐私问题，也是可靠性问题。（想象一下，每次有人访问使用 SomeCA 的任何网站时，SomeCA 都会收到通知。再想象一下，一旦 SomeCA 出现故障，所有这些网站都会因为无法执行撤销检查而无法访问。）Mozilla 尝试了集中聚合的“OneCRL”，但尽管这可以解决一些问题，但无法解决下一个问题。

另一个问题是，域名被撤销时，这些证书不会被撤销。假设某人获得了一个域名的 3 年证书，然后几周后将该域名卖给了你。那么，他们仍然拥有该域名的 3 年证书！

因此普遍的观点是，证书的有效期不应该那么长——很可能是几周，而不是几年。

Question 2

如今，证书更新和新版本的安装通常都是自动化的。此外，可以从 CA（如 Let's Encrypt）免费获取新证书。这意味着经常更换证书不会产生大量成本。但在证书过期之前尽早更新证书可以提供更高的可靠性，因为如果出现问题，人们有足够的时间来解决这些问题。

Answer

如今，证书更新和新版本的安装通常都是自动化的。此外，可以从 CA（如 Let's Encrypt）免费获取新证书。这意味着经常更换证书不会产生大量成本。但在证书过期之前尽早更新证书可以提供更高的可靠性，因为如果出现问题，人们有足够的时间来解决这些问题。

Question 3

之所以要让 HTTPS 证书过期并进行替换，是因为如果证书私钥以某种方式暴露，攻击者可以构建证书所标识网站的可信伪造网站。这些网站可用于窃取用户凭据，并诱骗用户采取不安全的操作。所花的时间越短，攻击者造成的损害就越小，并且会增加维护攻击基础设施所需的工作量。

Answer

之所以要让 HTTPS 证书过期并进行替换，是因为如果证书私钥以某种方式暴露，攻击者可以构建证书所标识网站的可信伪造网站。这些网站可用于窃取用户凭据，并诱骗用户采取不安全的操作。所花的时间越短，攻击者造成的损害就越小，并且会增加维护攻击基础设施所需的工作量。

Question 4

为许多非常有用/有趣的答案添加另一种观点：

每周都会有不同证书，这要多久？或者为什么不是每个请求都有？那么我们只需依靠他们的“可信”权威。

一旦您信任某个证书颁发机构，您就会信任其所有（未撤销的）证书。您为服务器 X 选择哪一个证书颁发机构并不重要，给定的服务器可以拥有数百个证书并以任何方式使用它们。您信任这些证书的 CA，您就会信任所有这些证书。

证书变更不应该成为大问题。另一端的 CA 变更可能是有可疑情况的更佳信号（如本地劫持）。

但是为什么服务器会有这么多证书呢？原因有很多，其中包括：

您所看到的单个网站可能位于 CDN 后面，并且根据 TLS 的终止方式，可能会落在多个框中：在这些框中，没有理由期望到处都有完全相同的证书，并且完全同时轮换；出于安全原因，每个框都有自己的证书和私钥可能会更好；因此，您实际上可能会根据浏览的位置获得不同的证书；简而言之，您所看到的证书更改可能只是网络/HTTP 级别的路由更改，您会到达具有同一网站名称的不同证书的不同框，它甚至在之前就存在了，但您没有看到它
这可能是一些边缘情况，但在某些情况下，证书甚至可以在首次访问时生成；有各种提案和最近的 RFC 可以正确地将事情委托给托管/CDN 公司，并允许其代表您为您的网站续订证书
一些托管公司会根据客户端如何启动 TLS 握手来更改 TLS 参数，包括所呈现的证书（为了尝试提供尽可能高的安全设置……除非检测到与其不兼容的旧客户端并希望仍然容纳它们，因此切换到较低的安全设置，关于证书和 TLS 参数）；您可能不知道/记得这一点，但在过去，由于出口规则，浏览器有不同的版本，并且根据您所在的国家/地区，您可以使用普通版本或受限制的版本，其中可用的加密算法较弱，这也会对证书产生影响（基于 RSA 的证书与基于 ECDSA 的证书）

您可以使用任何证书透明度日志浏览器查看内容。前往https://crt.sh/?q=serverfault.com例如，您现在会看到数十个有效证书以某种方式涵盖此名称。使用其他示例，您会发现同样的情况，表明在任何给定时间，任何特定的大型网站都有多个证书满足其需求。这完全没问题，而且随着自动化程度越来越高，证书的有效期越来越短，这种情况会越来越多。

您不必太担心证书何时更新以及其是否过期。首先，正如上面所解释的那样，您可能会在“一个”框中看到“一个”证书，而实际上给定主机名已经存在数千个证书。我记得过去有一种 Firefox 扩展方式，可能称为 Cert Patrol，它可以监视证书，但如果 CA 没有更改或特定站点更改过于频繁，则允许您设置规则以绕过更改。其次，因为理论上证书的有效期可以短得多（历史表明有效期一直在缩短），并且从技术上讲，如果用于 HTTPS 的证书在几周内而不是几个月甚至几天内过期，事情也会以相同的方式工作。证书在开始时用于声明站点的身份，但在初始握手完成后，在稍后的 TLS 交换中不再需要它。

举例来说，在其他领域，例如通过证书保护的 SSH 访问，您可以拥有有效期最短为 5 分钟的证书，并且它符合设计并运行良好。每次看到不同的证书不是问题。

至于

他们的发行人没有改变，所以显然还是他们。他们只是过于偏执还是什么？

您的分析遗漏了一个关键点。证书主要是被美化的公钥：一个公钥加上一些元数据，包括开始/结束日期以及 CA 对所有这些的签名。

当您续订证书时，实际上您并没有续订它（您无法延长/更改现有证书，它不像域名），而是生成一个新证书来替换现有证书。但现在的问题是：生成新证书时，您是否重复使用相同的公钥？每种情况都有利弊。例如，Let's Encrypt 默认使用新公钥，但如果您想在 DNS 中使用带有 TLSA 记录的 DANE，则意味着您也需要更改这些记录……或者为新证书重新使用相同的公钥。

如果您特别偏执，您可能会每次都更改公钥，否则您的攻击面会更大（更多加密材料由同一密钥签名/加密）。因此，如果您看到证书发生变化，您还需要查看底层公钥是否也在变化。

Answer