Es war jener Montagmorgen, der eigentlich ein Dienstag war. (nach einem Feiertag).
Gerade wurde der Arbeitsplatz-PC hochgefahren. Das Telefon klingelt. Man wird darüber informiert, dass einige wichtige Webseiten sich nicht mehr öffnen lassen. Offenbar gibt es einen SSL Zertifikatsfehler, weshalb das UTM-System (=vereinfacht Firewall) den Verbindungsaufbau kurzerhand unterbindet.
Der erste Gedanke der mir in diesem Moment durch den Kopf schießt ist: „Hab ich etwas an unserer Konfiguration verändert?“.
Nein, habe ich nicht…
Analyse
Nach näherer Analyse der betroffenen Seiten, stelle ich schließlich fest, dass offenbar immer ein SSL-Zertifikat von Sectigo der Dreh- und Angelpunkt der Problematik ist. Genaugenommen passt bei den besuchten Seiten die Zertifikatskette nicht. (Zertifikat abgelaufen!)
Dies lässt sich mit Hilfe der Seite https://www.ssllabs.com/ssltest/ recht einfach überprüfen. Gibt man dort eine der Websiteadressen ein, die sich nicht öffnen lassen (wegen des Zertifikatsfehlers), wird man nach Abschluss des Tests, der ein paar Minuten dauert, darauf hingewiesen, dass ein Zertifikat am 30 May 2020 abgelaufen ist.
Firewalls mit aktiver Zertifikatinspektion, springen hier dann offenbar gerne darauf an, erkennen ein abgelaufenes Zertifikat in der Zertifikatskette und unterbinden die Verbindung. An sich, ein absolut korrektes Verhalten!
Schaut man sich das abgelaufene Zertifikat genauer an, sieht das so aus:
| USERTrust RSA Certification Authority Fingerprint SHA256: 1a5174980a294a528a110726d5855650266c48d9883bea692b67b6d726da98c5 Pin SHA256: x4QzPSC810K….. |
|
| Valid until | Sat, 30 May 2020 10:48:38 UTC (expired 2 days, 19 hours ago) EXPIRED |
| Key | RSA 4096 bits (e 65537) |
| Issuer | AddTrust External CA Root |
| Signature algorithm |
SHA384withRSA |
Workaround
Aufgrund dessen, dass unzählige Webseiten betroffen sind, blieb vielen Admins kurzerhand nichts Anderes übrig, als vorhandene Konfigurationen zu adaptieren und Sicherheitsmechanismen ggf. aufzuweichen.
Einerseits ging man tlw. dazu über, „nicht vertrauenswürdigen SSL Zertifikaten“ zu vertrauen, oder aber -noch schlimmer- die Zertifikatsprüfung komplett abzuschalten!
Handlungsbedarf
Handlungsbedarf besteht bei abgelaufenen Zertifikaten in erster Linie bei den Websitebetreibern, die eben solche SSL Zertifikate einsetzen, nicht direkt bei den diversen Herstellern von Sicherheitsausstattung wie Firewalls, Contentfilter etc, wenngleich das Problem wohl teilweise auf eine ältere Implementierung von OpenSSL zurückgeführt werden kann. Ebenso scheinen einige Hersteller noch einen alten Zertifikatsstore einzusetzen usw.
Sofern man freilich uralte (nicht mehr gewartete!) „Securityhardware“ einsetzt, sollte man diese so schnell wie möglich austauschen!
Auszüge aus dem Artikel (calnetweb.berkeley.edu – unten verlinkt):
- Client software based on OpenSSL prior to version 1.1.1 appears to have broken certificate path validation logic and will require workarounds
- OpenLDAP clients on some platforms appear to have broken certificate path validation logic and will require workarounds
- Clients configured to explicitly trust the AddTrust root may need client reconfiguration to either:
- rely on operating system or vendor managed truststores or
- explicitly trust the USERTrust RSA Certification Authority root or the alternative legacy AAA Certificate Services root (valid until Dec 2028).
Hier der gesamte (interessante!) Artikel von calnetweb.berkeley.edu
Dennoch sollten alle Betreiber von Webseiten darauf achten, dass alle Zertifikate“up-to-date“ sind und abgelaufene Zertifikate ersetzen / entfernen.