Die Veraltung des Root-Zertifikats AddTrust führte zu Störungen in Systemen mit OpenSSL und GnuTLS.

Am 30. Mai lief die 20-jährige Gültigkeit des Wurzelzertifikats ab AddTrust, der wurde verwendet zur Erstellung einer cross-signierten Signatur in den Zertifikaten eines der größten Zertifizierungsstellen, Sectigo (Comodo). Die cross-signierte Signatur stellte die Kompatibilität mit älteren Geräten sicher, in deren Speicher für Wurzelzertifikate das neue Wurzelzertifikat USERTrust nicht hinzugefügt wurde.

Theoretisch hätte das Ablaufen des Wurzelzertifikats AddTrust lediglich zu Kompatibilitätsproblemen mit älteren Systemen (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 usw.) führen sollen, da das zweite Wurzelzertifikat, das in der cross-signierten Signatur verwendet wird, 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-signierten Signatur in TLS-Clients festgestellt, die keine Browser verwenden, einschließlich solcher auf Basis von OpenSSL 1.0.x und GnuTLS. Eine sichere Verbindung konnte nicht mehr hergestellt werden, da eine Fehlermeldung über das Ablaufen des Zertifikats angezeigt wurde, wenn auf dem Server ein Zertifikat von Sectigo verwendet wird, das über die Vertrauenskette mit dem Wurzelzertifikat AddTrust verbunden ist.

Wenn Benutzer moderner Browser die Ablauffrist des Root-Zertifikats AddTrust bei der Verarbeitung von Cross-signed Zertifikaten von Sectigo nicht bemerkt haben, traten in verschiedenen Drittanwendungen und Serverprozessoren Probleme auf, was zu Störungen in der Funktionalität viele Infrastruktur, die verschlüsselte Kommunikationskanäle für die Interaktion zwischen Komponenten verwendet.

Zum Beispiel gab es Probleme Zugriffsprobleme bei einigen Paket-Repositorys in Debian und Ubuntu (apt gab einen Zertifikatsüberprüfungsfehler aus), Skriptanfragen über die Tools „curl“ und „wget“ scheiterten, und es traten Fehler bei der Verwendung von Git auf, es gab Störungen in der Funktionsweise der Streaming-Plattform Roku, die Handler hörten auf zu reagieren, Stripe und DataDoges begannen Abstürze in Anwendungen von Heroku, es konnten keine OpenLDAP-Clients mehr verbunden werden, Probleme beim Versand von E-Mails an SMTPS- und SMTP-Server mit STARTTLS wurden festgestellt. Zudem gibt es Probleme in verschiedenen Ruby-, PHP- und Python-Skripten, die das http-Client-Modul verwenden. In den Browsern gibt es Probleme mit Bluetooth-Stack und hängt mit der fehlerhaften Verarbeitung der Berechtigung BLUETOOTH_PRIVILEGED bei setPhonebookAccessPermission zusammen. Bei den als gefährlich eingestuften Schwachstellen wurden 7 Probleme in Frameworks und Anwendungen, 4 in Systemkomponenten, 2 im Kernel und 10 in offenen und proprietären Komponenten für Qualcomm-Chips behoben. Epiphany, in dem die Blocklisten für Werbung nicht mehr geladen werden.

Programme in Go sind nicht betroffen, da in Go eigene Implementierung TLS.

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-Zweige verwendet werden, das Problem trat jedoch auch beim Arbeiten mit dem Paketmanager APT in den aktuellen Versionen Debian 10 und Ubuntu 18.04/20.04 auf, da APT die GnuTLS-Bibliothek verwendet. Der Kern des Problems liegt darin, dass viele TLS/SSL-Bibliotheken das Zertifikat als lineare Kette interpretieren, während gemäß RFC 4158 das Zertifikat einen gerichteten, verteilten Zyklographen mit mehreren Vertrauensanker darstellen kann, die berücksichtigt werden müssen. Diese Fehlentwicklung in OpenSSL und GnuTLS es ist bekannt besteht schon seit vielen Jahren. In OpenSSL wurde das Problem in der Version 1.1.1 behoben, während in GnuTLS nicht verfügbar es noch ungepatcht ist..

Um einen Ausfall zu umgehen, wird empfohlen, das Zertifikat „AddTrust External CA Root“ aus dem System-Store zu entfernen (z. B. aus /etc/ca-certificates.conf und /etc/ssl/certs löschen und anschließend „update-ca-certificates -f -v“ ausführen). Danach kann OpenSSL Kreuzsignierte Zertifikate normal verarbeiten. Bei Verwendung des APT-Paketmanagers kann auf eigenes Risiko die Zertifikatsprüfung für einzelne Anfragen deaktiviert werden (z. B. „apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false“).

Um das Problem zu beheben, , aber bisher ist er noch nicht in und RHEL wird empfohlen, das Zertifikat AddTrust auf die schwarze Liste zu setzen:

trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Dieser Ansatz nicht funktioniert funktioniert jedoch nicht für GnuTLS (zum Beispiel wird weiterhin ein Fehler bei der Zertifikatsüberprüfung angezeigt, wenn das Tool wget gestartet wird).

Auf der Serverseite kann man die Reihenfolge der Zertifikate in der Vertrauenskette ändern, die vom Server an den Client gesendet wird (wenn das mit „AddTrust External CA Root“ verbundene Zertifikat aus der Liste entfernt wird, erfolgt die Überprüfung durch den Client erfolgreich). Um die neue Vertrauenskette zu überprüfen und zu generieren, kann ein Dienst verwendet werden. whatsmychaincert.com. Das Unternehmen Sectigo auch bereitgestellt ein alternatives, kreuzunterzeichnetes Zwischenzertifikat „AAA Certificate Services„, das bis 2028 gültig ist und die Kompatibilität mit älteren Betriebssystemversionen ermöglicht.

Zusatz: Das Problem besteht auch zeigt sich in LibreSSL.

Quelle: opennet.ru