Let's Encrypt-Zertifikate-Ärger mit Windows, Sophos UTM, macOS/iOS (30.9.2021)

Sicherheit (Pexels, allgemeine Nutzung)[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:

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!

https://github.com/win-acme/win-acme/issues/1929

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:


Anzeige

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….

Let's Encrypt issue(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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Problemlösung, Sicherheit, Störung, Windows abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

23 Antworten zu Let's Encrypt-Zertifikate-Ärger mit Windows, Sophos UTM, macOS/iOS (30.9.2021)

  1. secondJo sagt:

    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!

  2. Manuel Himmler sagt:

    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.

  3. ACMEv2 sagt:

    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.

  4. Marco sagt:

    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.

    • Günter Born sagt:

      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.

  5. Rx3z sagt:

    Gibt ein Advisory von Sophos:
    ^ttps://support.sophos.com/support/s/article/KB-000042993?language=en_US

  6. Markus sagt:

    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!

  7. Dirk Zinken sagt:

    Mal wieder hat mir der Blog die Arbeit erleichtert! Vielen Dank für den täglichen Aufwand

  8. Conrad sagt:

    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.

  9. Matthias R. sagt:

    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

  10. Michael R. sagt:

    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..

    • Benjamin sagt:

      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….

  11. da dude sagt:

    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.

  12. Juergen sagt:

    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.

  13. Bob sagt:

    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.

  14. pitgrap sagt:

    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…

  15. Fredel sagt:

    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

Schreibe einen Kommentar zu Heisenberg70 Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.