Autsch: Let’s encrypt zieht 3 Millionen Zertifikate zurück

[English]Kleine Meldung zum Feierabend: Let's encrypt ist ein Fehler bei der Zertifikatsausstellung passiert und die müssen jetzt 3 Millionen ausgestellter TLS-Zertifikate zurückziehen.

Zwischen Erfolg und Misserfolg ist es oft ein schmaler Grad – gerade noch ging es steil bergauf, dann ein Schritt zu weit rechts und Du stürzt gnadenlos ab.

Griff nach den Sternen: Milliarden Zertifikate

Ich hatte es vor einigen Tagen schon mitbekommen, Let's encrypt hat 1 Milliarde TSL-Zertifikate ausgestellt. Ich hatte es bewusst nicht im Blog drin – ist aber heute hier im Kommentar von Ralf kurz thematisiert worden. Der Beitrag der Let's Encrypt-Macher ist hier abrufbar.

Grandioser Erfolg, da kann man nur gratulieren. Ich bin hier im Blog auch mit den kostenlosen Let's Encrypt TLS-Zertifikaten gestartet, habe aber seit letztem Jahr ein kostenpflichtiges Zertifikat, was 12 Monate vorhält.

Drei vor, zwei zurück: 3 Millionen Zertifikate ungültig

Das obige ist der Griff nach den Sternen. Nun aber zurück nach den Niederungen der Praxis. Gerade lese ich bei Golem, dass Let's Encrypt 3 Millionen TLS-Zertifikate wegen eines Fehlers zurückziehen muss.

TLS: Let's Encrypt muss drei Millionen Zertifikate zurückziehen #letsencrypt https://t.co/tFNwhGKp5d

— Golem.de (@golem) March 3, 2020

Der Fehler führt dazu, das die Prüfung der CAA-DNS-Records nicht korrekt durchgeführt werden kann. Die Details sind in der Let's Encrypt-Community offen gelegt:

On 2020-02-29 UTC, Let's Encrypt found a bug in our CAA code. Our CA software, Boulder, checks for CAA records at the same time it validates a subscriber's control of a domain name. Most subscribers issue a certificate immediately after domain control validation, but we consider a validation good for 30 days. That means in some cases we need to check CAA records a second time, just before issuance. Specifically, we have to check CAA within 8 hours prior to issuance (per BRs §3.2.2.8), so any domain name that was validated more than 8 hours ago requires rechecking.

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.

We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.

Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.

In knapp: Die Prüfung der CAA-DNS-Records wird bei der Zertifikatsausstellung nicht sauber geprüft. Das ermöglicht ein Zertifikat für eine Domain mit einer Gültigkeit bis zu x+30 Tage auszustellen, selbst wenn jemand später CAA-Einträge für diesen Domainnamen installiert, die die Ausstellung durch Let's Encrypt verbieten. Der Fehler existiert seit dem 25. Juli 2019. Eine detailliertere Erklärung hat Hanno Böck auf Golem veröffentlicht.

Betroffene Nutzer wurden per Mail informiert und müssen sich jetzt umgehend ein neues Zertifikat ausstellen lassen. Auf der Webseite hier kann die URL einer zu prüfenden Web-Site eingegeben werden. Dann wird geprüft, ob diese von den zurückgezogenen Zertifikaten betroffen sind.

I guess some people will find this helpful https://t.co/GEzdrRUX4z quick and dirty script to check if you need to replace @letsencrypt cert on a host due to CAA issue

— hanno (@hanno) March 3, 2020

Hanno Böck hat auf GitHub ein kleines Script veröffentlicht, welches prüft, ob man sein Zertifikat erneuern muss.