[English]Zum 30. September 2021 sind einige Root-Zertifikate abgelaufen, die Let's-Encrypt zum Signieren der Benutzer-Zertifikate verwendet hat. Das führte dazu, dass bestimmte Geräte oder Anwendungen nicht mehr an Webseiten oder Mail-Server herankamen. Mir sind sowohl Fälle mit iOS 14/15 und macOS untergekommen, als auch Probleme mit dem Internet Information Server (IIS) sowie Microsoft Exchange. Zudem macht die Sophos UTM Firewall Applicance Probleme, weil diese ebenfalls ein betroffenes Let's-Encrypt-Zertifikat verwendet. Die Probleme lassen sich aber leicht lösen – hier noch eine kurze Übersicht bzw. Nachlese.
Anzeige
Das Let's-Encrypt Zertifikate-Problem
Zum heutigen 30. September 2021 verlieren einige von Let's Encrypt zum Signieren von Kundenzertifikaten verwendete Root-Zertifikat ihre Gültigkeit (Ablauf des Intermediate R3 am 29.9.2021 um 19:21:40 GMT – das DST Root CA X3 läuft am 30.9.2021 14:01:15 GMT aus). Clients, die nur die alten Root-Zertifikate kennen, können danach die Server-Zertifikate von Let's Encrypt nicht mehr verifizieren. Ich hatte im Blog-Beitrag 30. Sept. 2021: Knallt es bei Let's-Encrypt-Zertifikaten? darauf hingewiesen. Es war aber unklar, ob dies Auswirkungen habe – vermutet wurde, dass dies nur ganz alte Geräte, die keine Updates mehr bekommen (z.B. Android < v2.3.6) betroffen seien. Inzwischen ist aus Leserrückmeldungen aber klar, dass auch Geräte mit iOS 14 oder iOS 15, macOS etc. betroffen sein können.
Probleme mit Exchange und IIS
Mir liegen einige Kommentare vor, die von Problemen mit Exchange Server sowie dem Windows Internet Information Server (IIS) berichten. Das Problem war, dass der betreffende Server das ältere Let's Encrypt-Zertifikat bevorzugte. Hier hat der Neustart der betreffenden Server die Zertifikatskette wieder in Ordnung gebracht – wie es aus nachfolgenden Ausführungen hervorgeht.
Windows IIS klemmt mit iOS
Beim Windows Internet Information Server (IIS) scheint es Probleme mit iOS-Geräten gegeben zu haben. Auf heise gibt es diesen Kommentar, der einige Hinweise enthält.
der aber nur bei macOS und iOS auftrat, bei Abruf von einem Windows-Server IIS.
Bei allen Windows-Geräten gab es keine Probleme, mit keinem Browser.
Auf macOS trat das Problem auch beim Firefox auf.Abhilfe war:
-im Windows-Server Zertifikatspeicher das abgelaufene X3-Zertifikat löschen
-alle Let's-Encrypt Zertifikate NEU ausstellen
-IIS restarten (nur zur Sicherheit)Danach hatten die Apple-Geräte keine Probleme, ein Neustart dort war nicht erforderlich.
Warum das nur auf macOS und IOS auftrat, ist mir nicht ganz klar.
Weitere Kommentare wie hier im Blog bestätigen die Probleme mit iOS-Geräten. Auch in diesem Kommentar auf heise beklagt jemand Probleme mit IIS und Let's Encrypt-Zertifikaten. Martin Bene hat sich im englischsprachigen Blog mit diesem Kommentar gemeldet:
Anzeige
There are issues with IIS; the certificates are actually OK, but when building the certificate chain it sends, it prefers the old and now expired R3 intermediate certificate.
It keeps sending the expired intermediate certificate even after the actual expire date until the server is rebooted; this breaks Clients that don't provide intermediate certificates themselves (like iOS). Other clients (Windows) continue working just fine.
* Renewing the certificates on the server causes the chains to be rebuild and fixes the issue
* rebooting the server causes the chains to be rebuilt and also fixes the issue.
* just issuing an iisreset does NOT fix the issue
Das bestätigt das Problem, dass in vielen Fällen ein aktualisiertes Let's Encrypt-Zertifikat nicht wirksam wird. Erst ein Neustart des Windows-Servers bewirkt dass ein neues Zertifikat auch in die Zertifikatskette aufgenommen wird. Der Reset des IIS hilft leider nicht. Danach konnten auch die iOS-Geräte wieder kommunizieren.
Probleme mit Exchange
Auch in diesem Kommentar meldet Markus Probleme in Verbindung mit der Erreichbarkeit eines Exchange-Servers auf Grund von Zertifikate-Problemen. Hier sein Kommentar:
Lösung am Exchange Server das Zertifikat erneuern ! solltest du mit der win-acme Lösung arbeiten von Frankys web!
Hier kann ich erneut den Hinweis geben, der mich über Facebook erreichte: Bei mir hat ein Exchange Server Neustart geholfen. Nach dem Neustart wird die Zertifikatskette am Server richtig dargestellt.
Sophos UTM Firewall Appliance betroffen
Hier im Blog meldeten sich gleich mehrere Benutzer, die Probleme mit dem Zugang von iOS-Geräten in Verbindung mit Sophos UTM (Firewall Appliance) berichteten. Blog-Leser Michael J. schrieb in diesem Kommentar:
es sieht wirklich so aus, als gäbe es unter dem aktuellen iOS 15 Release Probleme mit der internen Mail App. Hier bekomme ich eine Meldung angezeigt, dass das Zertifikat abgelaufen ist, obwohl ein Ablaufdatum in der Zukunft angezeigt wird.
Habe das Zertifikat direkt am Server (win-acme), sowie reverse Proxy (Sophos UTM mit LE) gecheckt, alles OK.
Kann das jemand verifizieren/bestätigen?
Kurze Zeit später habe ich auf Facebook auch die Rückmeldung erhalten, dass auch iPhones mit iOS 14 keine Kommunikation mit Mail-Servern nutzen konnten. Michael ergänzt in einem späteren Kommentar:
Ich habe das Problem finden können. In der Sophos UTM gab es, zusätzlich zu den gültigen Root-CAs, noch die beiden bereits abgelaufenen Zertifikate. Diese habe ich rausgelöscht und schon war das Problem mit der Chain erledigt. Ist vielleicht ganz nützlich, wenn man auf Fehlersuche ist.
Laut diesem Kommentar lassen sich diese unter Webserver Protection -> Certificate Management -> Certificate Authority finden und löschen. Das Problem könnte mit dem bereits oben erwähnten Thema zu tun haben, dass neue Zertifikate in der Zertifikatskette unberücksichtigt bleiben, bis der zugrunde liegende Server neu gebootet wurde.
Auf Facebook haben ich noch eine weitere Rückmeldung erhalten: Ist beim Mac (BigSure) das Gleiche, das Root Zertifikat (R3) ist gestern abgelaufen. Unter Windows sind die Zertifikate gültig.
Es lag am Exchange und der Sophos UTM. Auf der UTM mussten die alten CA's gelöscht werden, danach wurde im Browser wieder alles korrekt angezeigt. Einzig Outlook am Mac hat noch gemeckert. Hier musste das abgelaufene Root-Cert aus dem Zertifikatsspeicher gelöscht werden, anschließend das Let's Encrypt Zertifikat erneuern und einen IISReset durchführen. Danach verbindet sich der Mac wieder fehlerfrei….
(Quelle: Sophos)
Ergänzung: Sophos hat zum inzwischen das Advisory: Let's Encrypt Root Certificate Expiry mit bebilderten Hinweisen herausgegeben (danke an den Leser für den Hinweis). Vielleicht helfen euch die gesammelten Hinweise weiter.
Ähnliche Artikel:
30. Sept. 2021: Knallt es bei Let's-Encrypt-Zertifikaten?
Autsch: Let's encrypt zieht 3 Millionen Zertifikate zurück
Windows: Achtung bei abgelaufenen Zertifikaten, nicht löschen
Ungepatchte Altgeräte: Zertifikate-Ablauf Ende 2020
Anzeige
FortiGate's SSL Inspection Mode schlägt auch an, auf Seiten wo Let's Encrypt verwendet wird! Egal wie alt das Zertifikat ist.
Hier hilft nur vorrübergehend im SSL Inspection Profil "Allow Expired certificates" zu setzen.
Hmpf!
Vielen lieben Dank!
Wir haben uns schon die Zähne ausgebissen, weil wir frisch Forti im Einsatz haben =)
Der bessere Workaround:
1: Prüfen ob das neue Zertifikatbundle (v28) heruntergeladen wurde
get system auto-update versions
2: Den DNS blackhole workaround anwenden.
Siehe https://www.fortinet.com/blog/psirt-blogs/fortinet-and-expiring-lets-encrypt-certificates
3: Je nachdem was man verwendet, folgendes anwenden:
flow-mode: diag ips share clear cert_verify_cache
proxy-mode: diag test app wad 99
Wir haben bei einem Kunden HTTPS-Scanning aktiv.
Löschen der alten CA, hat bei mir leider nicht geholfen, auch nicht der Import der neuen CA.
Hab mal eine Support-Anfrage geöffnet.
Ja, ist hier auch so.
@Manuel: Schreib gerne mal hier rein, wenn Du eine Antwort auf Deine Supportanfrage bekommen hast.
Bin so froh das Firefox mit eigenem Speicher kommt (NSS-Bibliothek+cert9.db) und unter Linux bei meinen Servern solche Probleme gar nicht erst auftreten können durch automatische Aktualisierung mit acme.sh
Respekt an die die sich mit Exchange und IIS gerne rumschlagen.
Wir nutzen einen Mailcow Mailserver und dort wird beim Aufrufen des Webmailclients bzw. beim Abrufen von E-Mails mit IOS 14.8 oder Safari 15.0 unter MacOS 11.6 das abgelaufene Root Zertifikat "DST Root CA X3" geladen und natürlich angemeckert. Mit Firefox unter MacOS funktioniert es einwandfrei, dort wird das aktuelle und gültige Rootzertifikat "ISRG Root X1" verwendet. Auch alle anderen Browser unter Windows funktionieren einwandfrei, aber E-Mails lassen sich so mit IOS eben nicht mehr ohne Zertifikatsfehler abrufen. Leider hat ein Neustart von Mailcow keine Verbesserung gebracht. Keine Ahnung wo oder wie wir im Mailcow das abgelaufene Root-Zertifikat löschen können. Unser eigenes LetsEncrypt Zertifikat ist noch aktuell und läuft erst im November aus.
Bei Facebook habe ich ähnliche Rückmeldungen mit diversen Mail-Servern erhalten. Einer schrieb, dass er nicht nur die Zertifikate erneuern und die Mail-Server neu starten musste. Er musste auch das Mail-Konto unter iOS löschen und neu anmelden. Danach habe es wieder funktioniert.
Gibt ein Advisory von Sophos:
^ttps://support.sophos.com/support/s/article/KB-000042993?language=en_US
Klingt komisch, aber bei uns und einem anderen Kollegen hat es geholfen unter „Web Protection/Filteroptionen/Sonstiges" und dann „Webfilter-Zwischenspeicherung", den Cache zu löschen, obwohl die Funktion "Cache aktivieren" nicht aktiv war!
Jepp, Cache löschen hat geholfen bei deaktiviertem Cache :)
Bei uns ist transparentes Web-Proxy aktiv.
Danke Dir!
WE darf kommen.
Danke für den Tipp! Das hat bei uns auch geholfen…
Angenehmes Wochenende.
Das hat uns geholfen! Bei uns war der Cache auch nicht aktiviert. Danke!
Mal wieder hat mir der Blog die Arbeit erleichtert! Vielen Dank für den täglichen Aufwand
Sophos UTM 9 machte heute bei uns heute auch Probleme – nach Neustart lief dann alles.
Löschen mussten und konnten wir auch nichts. Scheint als ob da immer noch was im Cache hing.
Vielen Dank ans Forum.
Unter Android kann ich Private DNS nicht mehr benutzen. Habe Zuhause Adguard Home laufen der via LetsCrypt bis Ende Dezember Gültig ist. Über Private DNS kann ich verschlüsselte DNS anfragen über Adguard filtern. Das funktioniert leider nicht mehr. Das Webinterface von Adguard kann ich aber nutzen und ist auch gültig. Alle Android Geräte(5 Stück) haben kein Zugriff mehr. Wenn einer eine Lösung hat, wäre ich dankbar
Sophos XG mit konfigurierter SSL Webserver (Exchange) Protection hat hier auch gesponnen. Zertifikat am Exchange erneuert, exportiert und in der Sophos eingebunden hat nicht ausgereicht.
Unter Zertifikate -> Authorities -> mussten zwei im Sep. abgelaufene Zertifikate gelöscht werden. Dann ging's immer noch nicht.
Zusätzlich habe ich dann noch auf der Sophos:
https://letsencrypt.org/certificates/
die zwei Root Certificates und weiter unten das Active Let's Encrypt R3 als PEM importiert.
Neustart Exchange + Neustart Router und es ging an zwei Standorten wieder.
Hoffe jemandem is damit geholfen..
Danke dir, das war MEINE Lösung.
Endlich hat es funktioniert.
Problem lag final noch an der Sophos UTM.
Dort das Zertifikat von deinem Link (Lets's Encrypt R3 hatte mir noch gefehlt) hoch geladen (Webserver Protection, Certificate Management, Certificate Authority) und schwupps gingen alle Clients wieder.
Merci für die Info!
Hast mir sehr geholfen….
Sophos hat ein update Bundle released (steht auch so im KBA), seither sind bei uns alle Probleme verschwunden.
Kurze Notiz: Die Tipps hier und in den Sophos Foren haben bei uns nicht gezogen – wir fahren WAF und Web Protection.
Mein Problemfeld: Synology Rackstation (Mit DSM 6.2.4) mit Synology VPN-Server mit OpenVPN-Protokoll, Client 2.5.3 für Windows. Funktionierte seit gestern Nachmittag nicht mehr mit Fehlermeldung "ungültiges Zertifikat".
Lösung: Auf der Synology das Let's-Encrypt Zertifikat erneuert (möglicherweise nicht unbedingt erforderlich). Dann aus Synology VPN-Server im OpenVPN-Menü die Konfigurationsdateien erneut exportiert und auf dem Windows-Rechner im config-Ordner des OpenVPN Clients die bestehenden Dateien mit den neuen überschrieben.
Danach ging der Verbindungsaufbau wieder reibungslos.
Ich kann das Problem auch bestätigen.
Betrifft nur Mac OS, überall sonst wird das korrekte ISRG in der Zertifikatskette angezeigt. Nur der Mac zeigt das abgelaufene DST Root Zertifikat an.
Mein heutiger Support-Fall bzgl. Letsencrypt:
Ausgangslage:
Exchange-Server benutzt einen Debian-Server mit LetsEncrypt als Smarthost (SMTP-Relay). Seit gestern blieben die Mails in der Queue vom Exchange mit "CertExpired" Fehler.
Habe das Zertifikat vom Debian Server geprüft, neu erzeugt, etc. aber alles ok. Exchange geprüft etc, auch alles ok.
Dann habe ich mir mal die Stammzertifikate vom Windows Server angeguckt und siehe da, völlig veraltet und "ISRG Root X1" fehlte. Aber warum, sollten sich ja automatisch aktualisieren. Einstellungen durchsucht, nix gefunden.
Also mal testweise per Internet Explorer auf den Debian Webserver. Dürfte ja auch nicht laden. Aber die Seite lädt, Zertifikat, als auch der Pfad sind ok. Ich zurück zu den Stammzertifikaten und siehe da, alle aktualisiert.
Mein Fazit, surfe regelmässig auf Windows Servern mit dem Internet-Explorer, damit die Stammzertifikate aktuell gehalten werden…
Geknallt hats bei mir zwar nicht, nur Probleme gabs dennoch.
Problem & Lösung zu Firefox Version < 50
SSL Fehler: "Diese Verbindung ist nicht sicher"
"Domain… verwendet ein ungültiges Sicherheitszertifikat"
Fehlercode: sec_error_unknown_issuer
Tritt auf bei: zahllosen Websites.
Ursache: DST Root CA X3 ist abgelaufen.
Fehlerquelle: Firefox verwendet einen eigenen Zertifikat Speicher. Die Zertifikate dort laufen ohne Updates aus. Ja … Firefox Updaten, nur Kunde ist König (produktives Alt-Add-On), daher Alternative:
Lösung
Wer nicht updaten kann oder will: An einer weniger eingeschränkten Umgebung und/oder mit einem aktuelleren Browser die Website aufrufen, das Zertifikat / die Zertifikatkette exportieren (Schloss Symbol … SSL zertifikate Anzeigen). Das waren bei mir ISRG Root X1, sowie R3.
Dann im betroffenen Firefox Zertifikate importieren (Einstellungen, Extras, Datenschutz & Sicherheit, Zertifikate anzeigen).
Übrigens
Bei aktuellen Versionen kann man Firefox zwingen den Windows Zertifikat Speicher ebenfalls abzufragen (eigene Zertifikate, Intranet usw.)
Vielen Dank für professionellen Blog