Die Ablauffrist des Wurzelzertifikats AddTrust hat zu Problemen in Systemen mit OpenSSL und GnuTLS geführt.

Am 30. Mai lief die 20-jährige Gültigkeit des Wurzelzertifikats ab. AddTrust, der wurde verwendet für die Erstellung einer Cross-Signatur in den Zertifikaten eines der größten Zertifizierungsstellen, Sectigo (Comodo). Die Cross-Signatur ermöglichte die Kompatibilität mit veralteten Geräten, in deren Wurzelzertifikatsspeicher das neue Wurzelzertifikat USERTrust nicht hinzugefügt wurde.

Theoretisch hätte das Ablaufen des Wurzelzertifikats AddTrust nur zu Kompatibilitätsproblemen mit veralteten Systemen (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 usw.) führen sollen, da das zweite in der Cross-Signatur verwendete Wurzelzertifikat weiterhin gültig ist und moderne Browser es bei der Überprüfung der Vertrauenskette berücksichtigen. In der Praxis wurden Probleme bei der Überprüfung der Cross-Signatur in TLS-Clients festgestellt, die keine Browser verwenden, darunter solche, die auf OpenSSL 1.0.x und GnuTLS basieren. Eine sichere Verbindung konnte nicht mehr hergestellt werden, und es trat ein Fehler bezüglich des Ablaufs des Zertifikats auf, wenn auf dem Server ein Zertifikat von Sectigo verwendet wurde, das über die Vertrauenskette mit dem Wurzelzertifikat AddTrust verbunden war.

Obwohl Benutzer moderner Browser den Ablauf des Wurzelzertifikats AddTrust bei der Verarbeitung von Cross-signierten Zertifikaten von Sectigo möglicherweise nicht bemerkt haben, traten in verschiedenen Drittanwendungen und Serververarbeitern Probleme auf, die zu zu einer Störung Funktionsstörungen vieler Infrastrukturen führten, die verschlüsselte Kommunikationskanäle zur Interaktion zwischen Komponenten verwenden.

Zum Beispiel gab es Probleme Zugriffsprobleme auf einige Paket-Repositories in Debian und Ubuntu (apt gab einen Zertifikatsprüfungsfehler aus), Skripte, die mithilfe der Tools „curl“ und „wget“ aufgerufen wurden, endeten mit einem Fehler, und es traten Probleme bei der Verwendung von Git auf. Die Funktionalität der Streaming-Plattform Roku war gestört, und die Handler von Stripe und DataDogsind ausgefallen, es traten Abstürze in Heroku-Anwendungen auf, OpenLDAP-Clients konnten sich nicht mehr verbinden, es gab Probleme beim Versenden von E-Mails an SMTPS- und SMTP-Server mit STARTTLS. Zudem traten Probleme in verschiedenen Ruby-, PHP- und Python-Skripten auf, die ein Modul mit einem HTTP-Client verwenden. Bei den Browsern war Epiphany betroffen, in dem die Blocklisten für Werbung nicht mehr geladen werden konnten. betroffen Epiphanie, bei der die Werbeblockierungslisten nicht mehr geladen werden.

Programme in der Programmiersprache Go sind nicht von diesem Problem betroffen, da Go eine eigene Implementierung von TLS anbietet.

Es wurde angenommen,, dass das Problem ältere Versionen von Distributionen betrifft (einschließlich Debian 9, Ubuntu 16.04, RHEL 6/7), in denen problematische OpenSSL-Versionen verwendet werden, aber das Problem trat auch beim Arbeiten mit dem Paketmanager APT in den aktuellen Versionen von Debian 10 und Ubuntu 18.04/20.04 auf, da APT die GnuTLS-Bibliothek verwendet. Das Kernproblem besteht darin, dass viele TLS/SSL-Bibliotheken das Zertifikat als lineare Kette interpretieren, während gemäß RFC 4158 das Zertifikat einen gerichteten, verteilten, zyklischen Graphen mit mehreren Vertrauensanker darstellen kann, die zu berücksichtigen sind. Über diese Unzulänglichkeit in OpenSSL und GnuTLS damit dass Google sich darauf vorbereitet, eine eigene Lösung für den Austausch von Dateien mit dem Namen Nearby Sharing herauszubringen, die von Smartphones mit Android unterstützt wird. wird seit vielen Jahrenberichtet. In OpenSSL wurde das Problem in der Version 1.1.1 behoben, während es in GnuTLS unbehandelt bleibt. Als Umgehungsvorschlag zur Behebung des Fehlers wird empfohlen, das Zertifikat „AddTrust External CA Root“ aus dem systemweiten Speicher zu entfernen (zum Beispiel aus /etc/ca-certificates.conf und /etc/ssl/certs, und dann „update-ca-certificates -f -v“ auszuführen), nach dem OpenSSL beginnt, gekreuzt signierte Zertifikate korrekt zu verarbeiten. Bei Verwendung des APT-Paketmanagers kann auf eigene Gefahr die Überprüfung von Zertifikaten für bestimmte Anfragen deaktiviert werden (zum Beispiel „apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false“)..

Zur Eindämmung des Problems wird empfohlen, das Zertifikat AddTrust auf die schwarze Liste zu setzen:

trust dump —filter „pkcs11:id=$CB;type=cert“ \ Fedora und RHEL > /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit

trust dump —filter «pkcs11:id=;type=cert» \
Dieser Ansatz
führt jedoch bei GnuTLS weiterhin zu Problemen (zum Beispiel wird beim Start der wget-Anwendung weiterhin ein Zertifikat-Überprüfungsfehler angezeigt).

Auf der Serverseite kann man funktioniert nicht die Reihenfolge

der auf der Vertrauenskette gesendeten Zertifikate an den Client ändern (wenn das mit „AddTrust External CA Root“ verbundene Zertifikat aus der Liste entfernt wird, wird die Überprüfung durch den Client erfolgreich sein). Um die neue Vertrauenskette zu prüfen und zu erstellen, kann der Dienst whatsmychaincert.com verwendet werden. Das Unternehmen Sectigo hat außerdem zertifiziert, dass es ein alternatives, gekreuzt signiertes Zwischenzertifikat „AAA Certificate Services “ anbietet, das bis 2028 gültig ist und die Kompatibilität mit älteren Versionen des Betriebssystems gewährleistet. Zusatz: Das Problem tritt auchin LibreSSL auf.«, die bis 2028 gültig sein wird und die Kompatibilität mit älteren Betriebssystemversionen gewährleistet.

Ergänzung: Das Problem ist ebenfalls zeigt sich in LibreSSL.

Quelle: opennet.ru