Eine reine DNS-Verwaltung von Domains (also "ohne Webspace") ist mit LiveConfig nicht möglich.
Webspace wird rein technisch auch schon für Weiterleitungen benötigt (irgendein Webserver muss ja konfiguriert werden, um Anfragen entsprechend weiterzuleiten).
Zum Ändern der Standard-Version: https://www.liveconfig.com/de/…d-php-version-%C3%A4ndern
Wenn die Distribution PHP 7.4.x mitbringt, dann gibt es eigentlich keinen dringenden Grund, statt dessen das PHP 7.4.x von LiveConfig zu installieren. Auch wenn die Versionsnummer der Distributions-Variante kleiner ist, enthält dieses dennoch alle relevanten Sicherheitspatches.
Im Zweifelsfall kann man aber über "Serververwaltung" -> "Web", Box "PHP-Versionen" eine nicht mehr gewünschte PHP-Version ausblenden (Checkbox "darf nicht für neue Konfigurationen ausgewählt werden" aktivieren).
Viele Grüße
-Klaus Keppler
Bitte prüfen Sie zuerst einmal, was da an DynDNS-Updates hereinkommt.
(geht z.B. via /var/log/liveconfig/access.log - da nach "update" suchen)
Es gibt hirntote DynDNS-Clients, die sekündlich einen Lösch- und danach einen Update-Auftrag schicken. Wäre es "nur" eine sekündliche Aktualisierung dann wäre das kein Problem (LiveConfig ignoriert idempotente Aufträge). Aber ein "Löschen" und "Neuanlegen" ist eben was anderes. Wenn der BIND nun etwas länger braucht als der Client die Updates reinschickt, kann's knallen.
Wir haben bereits ein Rate-Limit für DynDNS-Updates vorbereitet (die technischen Voraussetzungen sind in v2.13 enthalten), der Rest sollte nächste Woche folgen.
Viele Grüße
-Klaus Keppler
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.
Ä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).
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.
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 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.
(gelöscht)
Wer Probleme mit wget oder curl unter Debian 9 hat, muss lediglich das System aktualisieren (GnuTLS in älteren Versionen hat Probleme mit dem abgelaufenen DST Root X3, auf aktuellen Debian9-Installationen passt aber alles).
PS: die v2.13.0 steht nun als Preview bereit, alle Tests hier verliefen soweit reibungsfrei.
In /etc/ca-certificates.conf braucht man eigentlich gar nicht eingreifen. Das "DST Root X3" darf da (nach aktuellem Kenntnisstand) ruhig drin stehen bleiben, da es "ganz normal" abgelaufen ist.
[UPDATE]Wichtig ist lediglich, dass der Server möglichst aktuell ist (also alle normalen Updates eingespielt sind)[/UPDATE]
Für den Zusammenhang: wenn das abgelaufene DST Root X3 drin bleibt und man aber die Datei /etc/ssl/certs/8d33f237.0 nicht gelöscht hat, dann erhält man bei ausgehenden OpenSSL-Verbindungen die Fehlermeldung "Certificate expired". Wenn man das DST Root X3 wiederum aus der ca-certificates.conf entfernt (bzw. darin deaktiviert) hat, bekommt man die Fehlermeldung "unable to get issuer certificate". Beide Fehlermeldungen zeigen aber, dass OpenSSL da (warum auch immer) den falschen Validierungspfad wählt.
Aktueller Kenntnisstand und ausführliche Erklärung:
Auf einem zweiten Liveconfig-Server (beides gleicher Versionsstand, von Liveconfig wie auch Debian) gab es allerdings überhaupt keine Probleme :confused:
Das haben wir inzwischen auch herausgefunden: das Problem taucht nur unter Debian/Ubuntu auf, wenn nachträglich CA-Zertifikate hinzugefügt oder gelöscht wurden (insbes. via /usr/local/share/ca-certificates/, oder Änderungen in /etc/ca-certificates.conf). Der Befehl "c_rehash" wird nur dann ausgeführt, wenn mindestens ein Zertifikat hinzugefügt oder gelöscht wurde.
Ich denke wir haben das Problem lokalisiert.
Durch den Aufruf von "update-ca-certificates" wird das Tool "c_rehash" ausgeführt, welches wiederum alle Zertifikate in /etc/ssl/certs/ ausliest und einen Hashwert berechnet. Dort speichert LiveConfig ja auch die Zertifikatsketten der eigenen Zertifikate.
c_rehash stößt somit unter anderem auf das Zwischenzertifikat "R3" (US/O=Let's Encrypt/CN=R3, Hash=8d33f237) und legt dafür einen entsprechenden Symlink an (/etc/ssl/certs/8d33f237.0).
Wenn nun ein OpenSSL-Client eine Verbindung irgendwohin aufbaut, erhält er vom Server dessen SSL-Zertifikat sowie eine Liste der Zwischenzertifikate, mit denen der Client einen Validierungspfad erzeugen kann. Aktuell sieht diese Liste bei Let's Encrypt so aus:
#0: Subject: /CN=(Domainname)
#0: Issuer:/C=US/O=Let's Encrypt/CN=R3
#1: Subject: /C=US/O=Let's Encrypt/CN=R3
#1: Issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
#2: Subject: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
#2: Issuer: /O=Digital Signature Trust Co./CN=DST Root CA X3
#0 ist das eigentliche Client-Zertifikat, #1 das Zwischenzertifikat (R3), und #2 eben der Sonderfall für alte Clients, welche das Let's-Encrypt-CA-Zertifikat noch nicht kennen (also alte Android-Endgeräte etc.).
Das Problem liegt nun irgendwo im Verhalten von OpenSSL bei der Prüfung des Zwischenzertifikates (#1). Wenn hierfür nämlich der Hashwert-Symlink /etc/ssl/certs/8d33f237.0 existiert, dann hüpft es direkt weiter zur Prüfung von #2 - sucht also nach einem gültigen Zertifikat vom Aussteller "DST Root CA X3". Gibt's ja aber nicht, weil abgelaufen.
Existiert der Hash-Symlink (8d33f237.0) nun aber nicht, dann sucht OpenSSL erst im eigenen CA-Truststore ob es einen Aussteller namens "ISRG Root X1" findet. Den gibt's, also ist alles prima.
Auf den ersten Blick würde ich sagen, dass es sich hier um einen Bug in OpenSSL handelt. Möglicherweise ist dieses Verhalten aber auch bewusst und irgendwo in den Untiefen dokumentiert. Es dürfte bislang schlicht keine Rolle gespielt haben, weil wohl noch nie im vergleichbaren Umfang "abgelaufene" Chain-Zertifikate (hier: #2) in großem Stil ausgeliefert wurden, um Legacy-Clients noch eine Weile zu unterstützen.
Workaround: die Datei /etc/ssl/certs/8d33f237.0 löschen. Das hält auch eine Weile an, die Hash-Files werden i.d.R. erst beim Update von CA-Zertifikaten aktualisiert:
rm /etc/ssl/certs/8d33f237.0Wir bereiten nun ein Update vor, welches u.a. folgende Änderungen vornimmt:
Ich melde mich noch mal sobald das Update bereitsteht und wir das Verhalten so bestätigen konnten.
Kurzer Zwischenstand:
das Problem scheint zu sein, dass OpenSSL 1.1 das abgelaufene DST X3 im eigenen Trust-Store (anders als von Let's Encrypt erwartet) eben nicht ignoriert. LiveConfig kann/darf das aber auch nicht einfach aus den Chain-Files löschen, weil es wiederum mit ausgeliefert werden muss damit ältere Clients die Verbindung hinbekommen.
Anders formuliert: das DST X3 muss zwar ausgeliefert werden, darf aber lokal auf dem Server nicht mehr als "vertrauenswürdig" aufgeführt werden. Blöderweise scheint das Script "c_rehash" (was von update-ca-certificates verwendet wird) sich da recht ungünstig zu verhalten, so dass sogar trotz Blacklisting in /etc/ca-certificates.conf dieses Zertifikat immer noch aktiv in der CA-Liste landet.
Wir sind einer Lösung auf der Spur, melden uns in Kürze nochmal.
Aber es ist immer eine Drittsoftware im Spiel!
Die vermutlich ggü. einer alten OpenSSL Bibliothek gelinkt ist.
Das ist durchaus möglich, OpenSSL 1.0.2 ist seit Ende 2019 "End-Of-Life" (= keine Updates mehr), und verhält sich bei der Prüfung des Zertifikatpfades möglicherweise anders als erwartet:
https://www.openssl.org/blog/b…etsEncryptRootCertExpire/