Sectigo: Abgelaufenes Root-Zertifikat entfacht Ärger

Viele ältere TLS-Clients kommen mit einem abgelaufenen Rootzertifikat namens Addtrust nicht klar.

Artikel von Hanno Böck veröffentlicht am 2. Juni 2020, 10:01 Uhr

Am 30. Mai ist ein 20 Jahre altes Root-Zertifikat abgelaufen. (Bild: Dafne Cholet / Flickr / Wikimedia Commons/CC-BY 2.0)

Ein vor wenigen Tagen abgelaufenes Root-Zertifikat der Firma Sectigo führt in vielen Fällen zu Fehlern bei der TLS-Zertifikatsprüfung. Zwar sind die betroffenen Zertifikate weiterhin gültig, verschiedene ältere Clients sind aber nicht in der Lage, den korrekten Vertrauenspfad zu berechnen. Betroffen sind Tools, welche die GnuTLS-Bibliothek nutzen, und ältere OpenSSL-Versionen.

Das problematische Zertifikat, um das es geht, trägt den Namen "AddTrust External Root CA". Es wurde im Jahr 2000 ausgestellt und war für 20 Jahre gültig, am 30. Mai 2020 lief seine Gültigkeit aus. Addtrust gehört zu Sectigo, einer ehemals unter dem Namen Comodo bekannte Zertifizierungsstelle.

Cross-signiertes Zwischenzertifikat lief am Samstag ab

Neuere Zertifikate werden von diesem Addtrust-Zertifikat schon lange nicht mehr ausgestellt, stattdessen nutzt Sectigo ein Root-Zertifikat namens Usertrust. Doch da es immer eine Zeit lang dauert, bis ein solches Root-Zertifikat in allen Clients angekommen ist, hat Sectigo für lange Zeit empfohlen, ein Cross-signiertes Zwischenzertifikat mitzuliefern. Dieses sorgte dafür, dass auch Clients, die nur das alte Addtrust-Zertifikat kennen, die Gültigkeit von Zertifikaten prüfen konnten.

Dieses Zwischenzertifikat lief zeitgleich mit dem Addtrust-Rootzertifikat ab. Doch viele Server verschicken es weiterhin. Was nun passiert, hängt vom Client ab. Korrekt arbeitende Clients sollten das überflüssige, abgelaufene Zwischenzertifikat einfach ignorieren und die Gültigkeit anhand des neueren Usertrust-Zertifikats prüfen. Manche Clients bilden aber in solch einem Fall eine Zertifikatskette mit dem abgelaufenen Zwischenzertifikat, stellen fest dass diese nicht gültig ist und brechen dann mit einem Fehler ab.

Alle aktuellen Browser kommen mit der Situation klar und ignorieren das abgelaufene Zwischenzertifikat. Probleme gibt es aber mit vielen Tools, die direkt die Zertifikatsfunktion von TLS-Bibliotheken nutzen. OpenSSL führt die Prüfung erst in Version 1.1 korrekt durch, viele Systeme nutzen aber ältere OpenSSL-Versionen. LibreSSL kommt erst in der aktuellsten Version 3.2.0 mit dem Problem klar.

Probleme vor allem mit GnuTLS

Die meisten Probleme treten mit der GnuTLS-Bibliothek auf. Dort gibt es inzwischen zwar einen Patch, aber noch kein neues Release. Erst die Version 3.6.14 wird das Problem beheben.

Neben manchen Zertifikaten, die direkt von Sectigo gekauft wurden, sind auch eine ganze Reihe von Resellern betroffen, darunter etwa die französische Firma Gandi. Diese Reseller stellen Zertifikate unter eigenem Namen mit einem eigenen Zwischenzertifikat aus, indirekt signiert sind sie aber ebenfalls von den Addtrust- und Usertrust-Zertifiktaen von Sectigo.

Andrew Ayer von der Firma SSLMate hat in einem Blogpost das Problem detailliert beschrieben. Ayer sammelt auf Twitter auch Fehlerberichte, die in dem Zusammenhang auftreten.

Unnötiges Zwischenzertifikat aus der Zertifikatskette entfernen

Betreiber von Servern, die von dem Problem betroffen sind, können sich behelfen, indem sie das abgelaufene Zwischenzertifikat aus der Zertifikatskette entfernen und beim Verbindungsaufbau nicht mehr mitschicken. Das ist auch unabhängig von diesem Problem sinnvoll, denn ein zusätzliches Zertifikat sorgt für einen größeren TLS-Handshake und somit für unnötige Verzögerungen beim Verbindungsaufbau. Services wie Hardenize oder der SSL-Labs-Checker warnen bei abgelaufenen Zwischenzertifikaten.

Wenn auf dem Client das Problem auftritt, kann das Addtrust-Zertifikat aus dem lokalen Zertifikatsspeicher entfernt werden. Mittelfristig sollten in gängigen Distributionen auch Updates dafür sorgen, dass dieses alte Zertifikat entfernt wird und dass die TLS-Bibliotheken mit solchen Situationen besser klarkommen.