Am 30. Mai 2020 erlebten wir eine seltene Situation in der Public-Key-Infrastruktur des Internets, als zwei der Stammzertifikate ausliefen, eine von der anderen SSL Verifizierungsstelle jeweils gegengezeichnet.
Theoretisch ist dies nichts Ungewöhnliches. Zertifikate laufen ständig ab (normalerweise in einem Jahr oder sogar in 90 Tagen, wenn Sie Let’s Encrypt verwenden), und die Zertifikate der Zertifizierungsstellen laufen nach einigen Jahren ab. Aber am 30. Mai deckte die auslaufende Zertifizierungsstelle ein grundlegendes Problem auf, das dazu führte, dass unsere API für einige unserer Kunden nicht verfügbar war.
Am 30. Mai als die Zertifikate der Zertifizierungsautoritäten ausliefen, erreichten uns Supportanfragen, dass es ein Zertifikatsproblem mit unserem Dienst gab. Dies war eine unerwartete Meldung, da wir sorgfältig prüfen, ob unsere Zertifikate gültig sind und nicht in absehbarer Zeit ablaufen. Eine schnelle Überprüfung im Browser bestätigte auch, dass alles normal zu sein schien und dass die API korrekt reagierte.
Beim Betrachten der Statistiken unserer Infrastruktur stellten wir fest, dass die Anzahl der API-Aufrufe zurückgegangen ist, aber sie waren bei weitem nicht annähernd null, wie es bei einem komplettem SSL Ausfall zu erwarten gewesen wäre. Wenn Dinge nicht vollständig funktionieren, ist es oft einfacher zu erkennen, was nicht funktioniert, als in Situationen, in denen einige Dinge funktionieren und andere nicht.
Eine umfangreiche Prüfung ergab schließlich, dass es auch bei anderen Diensten im Internet zu Problemen gekommen ist. Schnell fanden wir Hinweise auf die Ursache: https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
- Das Zertifikat unserer Zwischenzertifizierungsstelle Sectigo RSA Organization Validation Secure Server CA war gültig.
- Im Pfad 1 war das Wurzelzertifikat USERTrust RSA Certification Authority gültig, und die gesamte Kette war gültig.
- In Pfad 2 lief das Zertifikat unserer Stammzertifizierungsstelle USERTrust RSA Certification Authority am 30. Mai um 10:48 UTC ab.
- Das Zertifikat der Wurzelzertifizierungsstelle AddTrust External CA Root, das das Zertifikat von USERTrust RSA kreuzweise signierte, lief am 30. Mai um 10:48 UTC ab.
Dies war eine interessante Situation. Es gab einen gültigen Pfad zur USERTrust RSA Certification Authority, und es gab auch einen abgelaufenen Pfad. Der Browser war in der Lage, die gültige Kette zu finden, aber die Locke war nicht in der Lage, sie zu finden. Der Test von Quality SSL Labs zeigte, dass das System funktionierte und die Zertifikatskonfiguration einwandfrei funktionierte.
Unser Team begann mit der zweiten Änderung unseres öffentlichen Zertifikats und versuchte, den Dienst für die verbleibenden Kunden wiederherzustellen, und kurz nach dem Einsatz bestätigte es ihnen, dass sie den Dienst wieder erreichen können. Der Vorfall war nun endlich vorbei, und der Dienst wurde für alle Kunden wiederhergestellt. Aber warum haben einige unserer Kunden überhaupt erst den Zugang verloren, wenn selbst der SSL-Scanner sagt, dass das Zertifikat gültig ist?
Das Zertifikat war in der Tat gültig, und die gesamte Zertifikatskette wurde von der Zertifizierungsstelle Comodo/Sectigo einigermaßen korrekt generiert (das Ablaufen eines Zertifikats während des Wochenendes ist keine gute Praxis). Was nicht vorgesehen war, war die Art und Weise, wie die Client-Bibliotheken mit dieser Situation umgehen werden, in erster Linie OpenSSL, dass die große Mehrheit von HTTPS auf der Erde betreibt. Bei der Analyse des Vorfalls sind wir auf einen interessanten OpenSSL-Fehler aus dem Jahr 2014 gestoßen, der besagt:
Don’t use expired certificates if possible.
Quelle: https://github.com/openssl/openssl/commit/0930251df814f3993bf2c598761e0c7c6d0d62a2
When looking for the issuer of a certificate, if current candidate is expired, continue looking. Only return an expired certificate if no valid certificates are found.
Das bedeutet, dass vor der Implementierung dieser Änderung OpenSSL jedes Mal, wenn es ein ungültiges Zertifikat in der Kette entdeckt, das Zertifikat für ungültig erklärt und die Verbindung verweigert. Nachdem diese Änderung implementiert wurde, überspringt OpenSSL das abgelaufene Zertifikat und sucht korrekterweise weiter nach zusätzlichen Zertifikaten, die beweisen können, dass das Zertifikat gültig ist. Diese winzige Änderung passt sich der Art der Zertifikatskette an – eine einzige Zertifizierungsstelle kann von mehreren Zertifizierungsstellen unterzeichnet werden, von denen einige noch gültig sind und andere nicht mehr. Alles sieht großartig aus, warum also die Auswirkungen?
Wenn man weiter gräbt, so ist diese Änderung an OpenSSL nur ein Teil von OpenSSL 1.1.1 und nicht Teil von OpenSSL 1.0.x. Das bedeutet zum Beispiel, dass alle Versionen von Ubuntu 16.04 und älter, Debian 9 und älter, CentOS 7 und älter oder RedHat 7 und älter betroffen sind, aber alle diese sind immer noch allgemein unterstützte Versionen, zumindest vom Sicherheitsstandpunkt aus.
Aber warum haben die Browser die Zertifikate korrekt verifiziert? Die Browser werden mit ihren eigenen SSL/TLS-Bibliotheken und ihren eigenen Methoden zur Überprüfung der PKI ausgeliefert. Chrome wird mit BoringSSL und Firefox mit NSS ausgeliefert, unabhängig von den SSL/TLS-Bibliotheken des zugrundeliegenden Betriebssystems, hat nicht den gleichen Fehler und wird viel öfter aktualisiert.
Und jetzt haben wir endlich ein vollständiges Bild davon, was passiert war und warum nur Backend-Implementierungen einiger Kunden betroffen waren und warum es einige Systeme mit veralteten Zertifikatsspeichern gab, die ein viel älteres Stammzertifikat benötigten.
Wie geht es weiter? Wir wenden uns an betroffene Kunden und erklären, was passiert ist. Wir verbessern unser Tool zur Überprüfung von Zertifikaten, um den Ablauf in der gesamten Kette zu überprüfen, und nicht nur unser Zertifikat.
FAQ
Wurde die Nichtverfügbarkeit des Dienstes durch ein Problem auf den LOX24-Servern verursacht?
Nein, der Dienst funktionierte weiter und war nur für veraltete Systeme nicht verfügbar.
Was sollte ich tun, um zu vermeiden, dass in Zukunft eine ähnliche Situation mit LOX24 oder anderen Diensten auftritt?
Aktualisieren Sie Ihre OpenSSL auf mindestens Version 1.1.1 und LibreSSL auf mindestens 3.2.0. Aktualisieren Sie auch Ihre Zertifikatsspeicher, unter Linux oft als „ca-certificates“-Paket.
Ist das Zertifikat von LOX24 abgelaufen?
Nein, das Zertifikat von LOX24 lief nicht ab und ist immer noch gültig. Was abgelaufen ist, war eine von 3 Versionen der CA-Zertifikate der Zertifizierungsstellen, die unser Zertifikat unterzeichnet hat.
War irgendein anderer Anbieter betroffen oder war das Problem spezifisch für LOX24?
Es gab leider auch andere Anbieter, die betroffen waren: Heroku, Stripe, kernel.org, Datadog, Gandi.net und viele andere.
