Das Problem scheint mir zu sein, dass LetsEncrypt "ISRG Root X1" weiterhin mit ausliefert (neben dem R3), wenn auch als abgelaufen. Da z.B. ältere Android-Geräte das nicht prüfen, ist da die Kompatibilität weiterhin gegeben.
Neuere Clients sollten in der Theorie wenn sie bemerken dass ISRG Root X1 abgelaufen ist auf R3 zurückgreifen, so dass da kein Problem entsteht. In der Praxis passiert das scheinbar nicht in jedem Fall
Das mitgelieferte "ISRG Root X1" ist nicht abgelaufen (das gilt noch bis 2024), sondern das Zertifikat mit dem dieses unterschrieben wurde (DST Root X3) ist am 30.09.2021 abgelaufen (siehe Erklärung im Blog).
Wir werden aber kurzfristig eine Möglichkeit einbauen, die bevorzugte Zertifikatskette im LiveConfig auszuwählen.
So oder so müssen eventuelle Probleme aber i.d.R. beim jeweiligen Client behoben werden.
Viele Grüße
-Klaus Keppler
Alle von Let's Encrypt ausgestellten Zertifikate enthalten seit vielen Monaten bereits die "neue" Kette an Zwischenzertifikaten (also "R3" und "ISRG Root X1"). Eine Neuausstellung würde daran nichts ändern.
Details werden gerade per Ticket geklärt.
Das können wir so nicht bestätigen. Wir hatten in den letzten Tagen auf anderen Systemen ein ähnliches Problem mit den LE Zertifikaten, die beide Zwischenzertifikate enthielten und nach einem "force renew" nur noch das aktuell gültige. Alle Probleme waren dann gelöst.
Das können wir so nicht bestätigen. Wir hatten in den letzten Tagen auf anderen Systemen ein ähnliches Problem mit den LE Zertifikaten, die beide Zwischenzertifikate enthielten und nach einem "force renew" nur noch das aktuell gültige. Alle Probleme waren dann gelöst.
Das halte ich für ausgeschlossen: die von LiveConfig über Let's Encrypt abgerufenen Zertifikate enthalten derzeit immer beide Zwischenzertifikate (das ist derzeit der Standard bei Let's Encrypt). Da muss also irgendwo der Certbot im Spiel gewesen sein (möglicherweise wurde das betroffene Zertifikat mal über den Certbot oder eine andere Drittsoftware mit einer anderen Zertifikatskette angefordert, und LiveConfig hat bei einer späteren Zertifikatsbestellung für die selbe Domain dann auch die "kürzere" Chain zugewiesen bekommen).
Das halte ich für ausgeschlossen: die von LiveConfig über Let's Encrypt abgerufenen Zertifikate enthalten derzeit immer beide Zwischenzertifikate (das ist derzeit der Standard bei Let's Encrypt). Da muss also irgendwo der Certbot im Spiel gewesen sein (möglicherweise wurde das betroffene Zertifikat mal über den Certbot oder eine andere Drittsoftware mit einer anderen Zertifikatskette angefordert, und LiveConfig hat bei einer späteren Zertifikatsbestellung für die selbe Domain dann auch die "kürzere" Chain zugewiesen bekommen).
Da haben wir wohl aneinander vorbei gesprochen. Mit anderem System meinte ich tatsächlich nicht Liveconfig, sondern zig Hosts mit "win-acme" auf dem auch aktuelle Zertifikate drauf waren. Windows, Android und Co hatten damit keine Probleme, aber diverse IOS Geräte etc. Nach einem "force renewal" war denn der Spuk vorbei. Wenn uns das hier nicht hilft... aber ein neu erzeugtes Zertifikat in Liveconfig sieht erstmal so aus, als ob es was bringt.
Nach einem "force renewal" war denn der Spuk vorbei. Wenn uns das hier nicht hilft... aber ein neu erzeugtes Zertifikat in Liveconfig sieht erstmal so aus, als ob es was bringt.
Um das noch einmal klar zu stellen: ein reines Renewal ändert NICHTS an der Liste der Zwischenzertifikate. Weder mit LiveConfig, noch mit irgendeinem anderen ACME-Client.
Beim Abruf des Zertifikats kann der CA-Server optional verschiedene Chain-Listen als Alternative anbieten. LiveConfig nimmt aktuell immer die von der CA empfohlene (Standard-)Chain.
Offenbar verhält sich der "win-acme" da anders.
Wie bereits erwähnt bereiten wir eine Möglichkeit vor, optional ebenfalls eine andere Chain auszuwählen.
iOS-Geräte sollten mit der Standard-Chain übrigens allgemein keine Probleme haben, höchstens einzelne Apps die mit veralteten oder kaputten SSL-Bibliotheken gebaut sind.
Ähm... also bei dem betroffenen Server liegen jetzt unter /etc/apache2/sites-enabled/ keine Verlinkungen mehr sondern die originalen .conf Dateien. Und diese werden bei einer Änderung im LC auch nicht überschrieben sondern nur die im Verzeichnis /etc/apache2/sites-available.
Das sieht irgendwie nicht so ganz gewollt aus.
Danke für den Hinweis, ist im aktuellen Preview-Update (20211005.4) korrigiert. Ein anschließender Aufruf von "/usr/lib/liveconfig/lcservice.sh fix-symlinks" korrigiert das wieder (betrifft nur Systeme wo die Preview 20211004.x installiert war).
ZitatUm das noch einmal klar zu stellen: ein reines Renewal ändert NICHTS an der Liste der Zwischenzertifikate. Weder mit LiveConfig, noch mit irgendeinem anderen ACME-Client.
naja, hier doch.
Validierungs-Fehler in CURL/OpenSSL treten ja auf, weil LiveConfig die CA-Chain in die *-ca.crt gelegt hat. Das wäre so kein Problem, gäbe es nicht die abgelaufenen oder ähnliche veraltete Zertifikate. Löse ich nun einen Renew dieser alten Zertifikate aus, ist das abgelaufene CA-Zertifikat auch weg und somit funktioniert die Validierung wieder.
Danke für das Update und die umfangreichen Infos!
Dann müssen wir genau unterscheiden um was für Zertifikate es geht.
Alle gültigen Zertifikate (d.h. innerhalb der letzten 90 Tagen ausgestellt) enthalten die Chain aus "R3" und "ISRG Root X1" (signiert von DST). Daran ändert sich auch mit einem Renewal nichts.
Sollte es noch andere abgelaufene (ungültige) Zertifikate geben, dann stellt sich da ja die Frage nach dem Grund. Sind die Zertifikate "Karteileichen" (aus früheren LC-Versionen, wo LE-Zertifikate nicht automatisch mit der Domain gelöscht wurden), dann ist da auch kein Renewal möglich (da keine Validierung mehr möglich ist).
Aber auch unabhängig davon stellen diese alten (abgelaufenen) Zertifikate per se erstmal kein Problem dar. Wenn auf einem Server ausgehende SSL-Verbindungen zu Let's-Encrypt-Zielen nicht klappen, haben wir ja zwei mögliche Ursachen identifiziert:
Andere Probleme sind uns bislang nicht bekannt, aber mit den vorgenannten Themen hatte auch niemand gerechnet. Sollte es also darüber hinaus noch reproduzierbare Fehler geben, bitte immer her damit. Ohne konkrete Fehlerbeschreibungen können wir aber auch nicht helfen. Wichtig ist immer:
Bei Probleme mit eingehenden Verbindungen brauchen wir einen konkreten Domainnamen, bei ausgehenden Verbindungen sollte man das z.B. mit folgendem Befehl testen:
openssl s_client -connect letsencrypt.org:443 -showcerts -servername letsencrypt.orgWir haben eben die Preview (2.13.0) noch mal aktualisiert. Damit werden die Ablaufdaten der Zwischenzertifikate (Let's Encrypt) korrigiert und somit wieder richtig angezeigt.
Danke. Ist schon bekannt wann dies in die neue offizielle LiveConfig-Version übernommen wird?
Update: Danke für die Bereitstellung der 2.13 Release-Version
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!