Wenn die Zertifikatsprüfung Ihres Browsers Alarm schlägt

Bei Problemen in der Zertifikatsprüfung ist nicht immer die CA Schuld
Häufig bereiten falsche Implementierung oder inkomkpatible Softwarstände von Browsern und Mailclients bei der Zertifikatsprüfung Probleme

Seit dem 01.06.2020 bemängeln Browser bei der Zertifikatsprüfung vieler WebSites die sogenannte Zertifikatskette. In einigen Fällen unterstellen sie sogar, dass das zugehörige Zertifikat unzulässig sei. Und so manche Fachanwendung verschiedener Hersteller verweigert dann komplett den Dienst, sobald sie auf bestimmte Inhalte zugreifen soll, die mit SSL geschützt sind. Aber woran liegt das? Und vor allem: Was kann bzw. sollte man tun, um diese Probleme zu vermeiden?

Schnelleinstieg

SSL- bzw. TLS-Zertifikate finden seit vielen Jahren an verschiedenen Stellen Verwendung. Dabei gibt es naturgemäß inhaltliche und technische Unterschiede. So existieren neben den „self-signed certificates“, die Sie nur im internen Netz anwenden sollten, auch die Zertifikate von den „Certificate Authorities“. Diese dienen beispielsweise der Absicherung von personenbezogenen Daten beim Austausch mit Webseiten oder bei der Verschlüsselung des Mailverkehrs.

Inzwischen sollten die Unterschiede in der Aussagefähigkeit von Zertifikaten genau so bekannt sein, wie auch die in der Qualität der Implementierung (TLS-Version, Codierung, HSTS). Doch zunächst noch einmal in aller gebotenen Kürze: Sind die implementierten Zertifikate korrekt, erfüllen sie ihren Dienst.

Hintergründiges

Zum besseren Verständnis liefern wir gerne ein paar Hintergrundinformationen. Dazu werfen wir mal einen genaueren Blick auf die Zertifikate eines namhaften Anbieters. Sectigo, ehemals Comodo, verwendet drei eigenständige Root- oder auch Stamm-Zertifikate. Hier der Auszug:

Zertifikat Algorithmus Gültig bis
AddTrust External CA Root
https://crt.sh/?id=1
sha1WithRSAEncryption 30. Mai 2020
USERTrust RSA Certification Authority
https://crt.sh/?id=1199354
sha384WithRSAEncryption Januar 2038
COMODO RSA Certification Authority
https://crt.sh/?id=1720081
sha384WithRSAEncryption Januar 2038

Lassen Sie uns diesen Auszug gemeinsam interpretieren: Das mit SHA-1 signierte „AddTrust External CA Root“ Zertifikat lief am 30. Mai 2020 aus (1. Zeile). Natürlich gibt es Nachfolger für dieses Stammzertifikat. Diese werden als COMODO RSA Certification Authority und USERTrust RSA Certification Authority bezeichnet und laufen erst in 2038 wieder ab (2. und 3. Zeile). Doch in der Vergangenheit konnten einige Software-Clients die neueren SHA-2 Root Zertifikate nicht verwenden. Das heißt: Browser oder Mailclients waren bzw. sind nicht kompatibel. Dadurch tauchen Probleme und Fehlermeldungen bei der Zertifikatsprüfung auf, deren Ursache NICHT bei der CA zu suchen ist.

Handlungsbedarf

Doch was jetzt? Schließlich war das abgelaufene SHA-1 Zertifikat ja aus Gründen der Kompatibilität notwendig. Es besteht auf zwei Seiten Handlungsbedarf: nämlich sowohl bei den Herstellern von Mail- und Browsersoftwares sowie bei den Website- und Mailserver-Betreibern.

Zum Auslöser (nicht Verursacher) des Problems:

  • Korrekt arbeitende Clients (Browser, Mail-Clients, SSL-Bibliotheken für SOAP, PHP oder andere Software) erkennen, dass ein mittlerweile nicht mehr gültiges neben einem noch lange Zeit gültigen Zertifikat angeboten wird. Deshalb verfolgen sie die Zertifikatsketten bis zum bitteren Ende. Dadurch erkennen sie nämlich, dass das eigentlich zur Anwendung kommende Zertifikat für z.B. bb-one.net nach wie vor gültig ist und dass die Certificate Authority sich korrekt identifiziert.
  • Leider aber gibt es auch nicht ganz so korrekt arbeitende Software-Clients. Für diese muss ein Workaround her. Das ist natürlich nicht ganz unproblematisch. Denn entweder muss man hierfür ein neues Zertifikat anfordern und implementieren. Oder man muss das „Intermediate Certificate“ von Hand korrigieren. Im Klartext bedeutet dies, dass der mittlerweile ungültige Teil entfernt werden muss.

Welche der beiden Methoden zur Anwendung kommen, sollte der WebSite-Betreiber entscheiden. Welche Methode die formal bessere ist, ist wenigsten eine Diskussion wert. Tatsache ist: die „Nachbesserungen“ wären unnötig, wenn alle Software-Clients korrekt arbeiten würden.

Zertifikatsprüfung als Vorab-Test

Zwei beliebte Testmöglichkeiten, die u.a. Aufschluss über die SSL-Implementierung bzw. das verwendete SSL-Zertifikat geben, sind die Tests des eco Verband der Internetwirtschaft e.V. und von Qualys. Zwei Screenshots zeigen die jeweiligen Fehlermeldungen.

Weil ein formal wesentlicher Teil des Tests negativ ausfällt, wird das Gesamtergebnis mit Null Punkten bewertet.

 

Hier wird festgestellt, dass eines der beiden zusätzlichen Zertifikate fehlerhaft ist und, worin dieser Fehler begründet ist.

Schlussbemerkung

Zum Abschluss sei noch erwähnt, dass sich im Kontext „Zertifikatsprüfung“ wieder sehr schön zeigt, wie man bei allen Tools und Tests nicht vergessen werden darf, dass der geneigte Benutzer damit auch umgehen können sollte. Das Ergebnis der Tests muss richtig interpretiert werden, dann klappt’s auch mit dem abgelaufenen, nun nicht mehr benötigten zweiten Stammzertifikat. Denn noch einmal: die Verschlüsselung, die mittels SSL erfolgt, ist nicht betroffen, der Ausgeber des bewertenden Zertifikates identifiert sich korrekt mit einem gültigen eigenen Root-Zertifikat. So what?