LWN：Let's Encrypt为何要作废证书？

关注了就能看到更多这么棒的文章哦～

The Let's Encrypt certificate revocation scare

By Jake Edge
March 10, 2020

原文来自：https://lwn.net/Articles/814389/

有一个名为Let's Encrypt的项目，希望让每一个网站都能用上加密的HTTPS协议。它提供了免费的TLS证书，大多数web浏览器都承认它颁发的证书。在2014年建立这个项目之前，很少有web浏览器认可的免费证书。到今年2月底，Let's Encrypt已经颁发了超过10亿份证书。不过最近在此项目的Certificate Authority Authorization (CAA)处理代码里面发现了一个bug，有可能会导致2.6%的已颁发证书（大概3百万份）被立即撤销。可以想见，这导致不少人提心吊胆。幸好最后看来这种最坏情况并没有完全发生。

Let's Encrypt允许网站运营者在注册之后利用Let's Encrypt的服务来签发TLS证书，这样浏览器就可以验证这个证书是可信的。Let's Encrypt就是作为Certificate Authority (CA)的角色，它本身的秘钥也都是由网页浏览器的root certificate store（根证书库）里带有的CA(IdenTrust)签名认证过的。这就意味着浏览器可以从它信任的根证书一直追溯到网站的证书，形成可以信任的signature chain证书链，从而确认了证书中的秘钥是有效的。

如果某个网站希望能从Let's Encrypt这里申请到证书，那么管理员需要能证明他确实控制着这个域名。这个证明通常需要把Let's Encrypt给出的一个特征值加到此域名的DNS信息里，或者通过在此域名的网页服务中的某个指定URL获取到。管理员通过这种方式就能证明这个域名是在他控制之下了。

如果管理员希望限制颁发给自己域名的证书种类，可以直接在DNS配置里面增加一些CAA记录。这样就可以让特定的服务提供商（例如Let's Encrypt）避免给这个domain（或者其中的一部分）来颁发证书。举例来说，只要"exmaple.com"这个顶级域名的管理员通过配置CAA记录来禁止Let's Encrypt对此域名的证书颁发，那么“subdomain.example.com”这个网站的管理员哪怕按Let's Encrypt的要求在自己管理的服务器上添加了正确的网页，也无法从Let's Encrypt等CA服务商获取证书。有些网站可能还希望限制可以使用的CA种类，因为有些CA提供了除了签名之外的服务，使用这些CA可能会违背公司的操作规范。

因此，当Let's Encrypt需要检查某个网站是否合法时，需要也看一下CAA记录，但是这里的处理代码就有一个bug。在用户证明他能控制此域名之后，Let's Encrypt给了用户30天的时间可以随时申请证书。但是CAA信息应该在颁发证书之后的8小时内检查确认，所以后续有需要的时候要recheck（重新检查）一下。而Internet Security Research Group（就是Let's Encrypt的幕后实体）的Josh Aas发现，Boulder CA服务器在recheck代码里面有些问题：

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

（大意：申请证书的时候提供了N个域名的话，CAA recheck的时候Boulder CA服务只会挑一个域名来检查N次。所以在此后30天内，包含这个域名的证书申请都会全部通过，未能检查其他域名的CAA有效与否）

在此bug被fix之前，Let's Encrypt收到的包含多个domain的证书申请时可能没有完整检查这些domain的CAA记录，就颁发了证书。这些受影响的证书就不合规范。

3月3日的时候，Let's Encrypt的工作人员在论坛中发了一则消息，这些受影响的证书如果没有在3月5日之前renew（重新更新续约）的话，就会被废除。这就意味着浏览器会拒绝接受这300万网站的证书。不过3月4日的时候，Aas说已经有170万证书完成了renew，所以意味着这些网站的证书被废除并不会导致问题。在其余这些证书中，只有445个网站的CAA记录明确拒绝Lets' Encrypt颁发证书，这些就被强制废除了。剩下的这些就不会被废除了，至少不会现在取消。

Let's Encrypt的证书颁发后只有90天有效期，所以必须在到期前renew。最坏情况下，这意味着有130万网站会继续使用3个月不合法的证书。CA/Browser Forum (CA/B)是负责设立CA行为规范的组织，它认为，如果在颁发证书之前的8小时内没有检查过CAA记录的话，这些证书应该算作无效。所以哪怕这些网站当前其实CAA记录中并未拒绝Let's Encrypt证书，按规矩来说的话，这些证书仍然是无效的。当时这个3月5日的截止日期，就是根据CA/B要求所给出的时间。

Aas在Mozilla提交了一个bug report，希望能避免作废所有这些受影响的证书。Wayne Thayer引导Aas查看Mozilla guideline on revocation，里面明确说了公司不可以有批准例外情况，不过也承认有时候“revoking misissued certificates within the prescribed deadline may cause significant”（按照截止日期作废这些误发的证书有可能导致重大损失）。他认为，如果CA决定不作废这些证书的话，需要提供更多信息给Mozilla。

Jacob Hoffman-Andrews回复了一些额外信息，解释为何Let's Encrypt认为直接回收所有这些证书会是有害的。他说，在用户浏览到受影响的网站时如果碰到问题，很可能寻找方法来绕过这个证书的作废检查。他们真的绕过之后，今后很可能忘掉再次打开这个检查，这样很可能会错过其他的证书作废事件。这样也会导致“warning blindness”问题，就是用户如果看到太多warning的话，就不会再在意任何一个warning。不过他也提出了另一个影响更大的问题：

By reviewing previous incident reports and analyzing our current situation, a common root cause of failure to timely revoke is that Subscribers are not able to replace certificates on the BR- [baseline requirements] mandated timelines (24 hours and 5 days, depending on the issue).

Most Subscribers are not able to field round-the-clock incident response, so improving the speed of manual replacement processes cannot be the answer. Increasing public acceptance of revoked certificate errors also cannot be the answer, because that would undermine public faith in the web PKI. Reducing the incidence and scope of CA errors is an important part of the solution, and we have laid out some plans to that effect at https://bugzilla.mozilla.org/show_bug.cgi?id=1619047. However, responsible systems design requires layered responses, and it is possible that we, or another CA, will have a similar-sized incident in the future despite our best practices and best efforts.

（大意：研究了历史上类似的问题，共同的麻烦都在于许多网站管理员无法在强制截止时间点前替换证书，我们不能要求管理员总是及时响应，也不能让普通用户习惯于见到证书作废的情况从而导致web PKI的信誉损失。当然应该CA尽量避免出现这种问题，不过没有哪家CA能保证今后不会出现类似的大范围事故）

他指出，Let's Encrypt准备开发一个开源协议，用来通知用户CA这边需要作废证书，并让证书自动renew。现在无论多小的网站都有TLS证书了，用来跟用户进行加密通讯，因此对它们来说，当然需要维护好它们的证书，哪怕没有安排专人负责这个工作。Let's Encrypt还建立了一个网站供使用Let's Encrypt证书的网站管理员们检查他的域名是否需要更新证书了。

对于浏览器能接受哪些根证书，浏览器开发商拥有最终决定权。当然他们肯定需要先了解清楚移除一个证书要带来多大的影响。如果某些主要浏览器开发商认为Let's Encrypt采取的措施还不够，那么他们可以把IdenTrust根证书移除，不过这样一来受影响的可就不只是Let's Encrypt证书了。这种情况万一真发生了，IdenTrust可能会决定主动（也可能是迫于各方压力）把Let's Encrypt的证书都作废。目前还没有看到有这种迹象——至少公开渠道没有看到。如果真走到了这一步，造成的灾难将是创纪录的。

Let's Encrypt的免费证书应用非常广泛，这带来了一个缺点，就是生态单一化。如果把所有TLS证书的颁发都集中在一个组织里面，无论这一家是Let's Encrypt还是某家商业提供商，都很让人担忧。我们现在还远未走到这一步，不过这次的事件已经展示了，任何一家CA如果颁发了大量证书，它这里的一个小问题都很有可能让这家CA走进困难境地，尤其是那些一年或者更长有效期的证书会有更多麻烦。

Let's Encrypt总体上来说在这件事情上做得很不错，能在很短的时间内查出问题、修复bug、部分地减轻了这个问题，其实这只是CA在某项技术细节上违背了规范而已。很可能剩下的这些尚未作废的证书其实并没有真正颁发给不可信的人。我并不是想说这些技术问题就可以忽略了，不过很明显我们应该有一些更值得深思的问题。这个bug本身导致的问题是件坏事，不过目前看来大家解决问题的方向是非常正确的。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～