Beiträge von kk

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    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.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Zitat von mhagge

    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.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    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:

    Code
    rm /etc/ssl/certs/8d33f237.0


    Wir bereiten nun ein Update vor, welches u.a. folgende Änderungen vornimmt:

    1. die Datei /etc/ssl/certs/8d33f237.0 wird gelöscht
    2. die Chain-Zertifikate werden künftig nicht mehr in /etc/ssl/certs/[...]-ca.crt gespeichert, sondern in /etc/ssl/certs/[...].chain (also nicht mehr mit der Dateiendung ".crt", damit c_rehash diese künftig nicht mehr berücksichtigt.


    Ich melde mich noch mal sobald das Update bereitsteht und wir das Verhalten so bestätigen konnten.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    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.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Zitat von TCRserver

    Es sind aber in allen Fällen aktuelle Geräte mit aktueller Software!


    Bei aktuellen Geräten mit aktueller Software gibt es (zumindest was LiveConfig betrifft) definitiv keine Probleme.
    Ansonsten bitte konkrete Beispiele nennen (Betriebssystem, Version, konkrete Domain - gerne an support@liveconfig.com).


    Alle bei uns heute aufgeschlagenen Fälle lagen an zu alten Clients (wir hatten es heute schon mit Windows XP SP1 zu tun), nicht durch LiveConfig verwaltete Let's-Encrypt-Zertifikate (da wurde die CA-Chain nicht aktualisiert) oder veralteten Servern (Debian 8 mit OpenSSL 1.0.2 ist problematisch).


    Mit aktuellen Systemen ist uns bislang kein einziger Fall bekannt.


    Zitat

    Danach ist auch der Anzeige Fehler in LC behoben, bei dem jeweiligen Zertifikat.


    Dass LiveConfig Let's-Encrypt-Zertifikate derzeit als "abgelaufen" anzeigt ist ein lokales Problem, das gerade behoben wird (nur ein Darstellungsfehler, die Zertifikate an sich sind gültig und auch korrekt installiert).


    Viele Grüße


    -Klaus Keppler

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Zitat von pkambach

    ich habe hier zumindest auch Probleme bei mehreren Kunden - In der Zertifikatskette in Chrome z.B. steht das abgelaufene Root-Zertifikat drin (welche Version und OS es ist, weiß ich noch nicht).


    Soweit ich das sehe stimmt die Zertifikatskette. Ohne die Info welches OS das ist kann man leider nichts sagen.
    Falls es sich um ein Windows XP (vor SP3) oder gar etwas Älteres handelt, wird das nicht erkannt.
    https://letsencrypt.org/docs/certificate-compatibility/


    Workaround: das ISRG X1 Root manuell auf dem betroffenen Rechner installieren.
    Saubere Lösung: betroffenen Rechner grundsätzlich aktualisieren. ;)
    (wenn der tatsächlich sooo alt ist dass er die Zertifikatskette nicht akzeptiert, dann ist SSL das geringste Problem...)


    Viele Grüße


    -Klaus Keppler

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Ja, können wir bestätigen (betrifft die Übersicht der SSL-Zertifikate, da ist jeweils das Symbol "Zertifikat ist abgelaufen").


    Eventuell prüft LiveConfig intern die Zertifikatsgültigkeit noch über einen alten Validierungspfad. Wir kümmern uns darum, Update wird kurzfristig bereitgestellt.
    Die Zertifikate sind dennoch gültig, der Fehler betrifft nur die Anzeige innerhalb der Übersicht in LiveConfig.


    Viele Grüße


    -Klaus Keppler

  • Apache-Sicherheitsupdate / PHP-FPM

    Guten Morgen,


    vor rund zwei Wochen wurde eine Sicherheitslücke im Apache-Webserver bekannt: CVE-2021-40438. Mit einem CVSS-Score von 9.8 (!) ist dieser Bug als kritisch eingestuft.


    Für Ubuntu gab es vor wenigen Tagen bereits die ersten Updates, welche allerdings dazu führten dass PHP-FPM in manchen Konfigurationen nicht mehr funktionierte (Ubuntu Bug #1945311). Nachdem Ubuntu nun die Patches von Debian nachgezogen hat, scheint wieder soweit alles zu funktionieren (auf unseren Ubuntu 16/18/20 Testservern können wir aktuell keine Probleme feststellen).


    Für Debian stehen die entsprechenden Updates derzeit noch aus, dürften aber in Kürze auch freigegeben werden (siehe Debian Security-Tracker). Nach dem aktuellen Stand gehen wir davon aus, dass es mit den Debian-Updates (anders als bei Ubuntu) keine Probleme geben sollte. Wir empfehlen aber, eventuelle Updates erst mal nur auf einem Server auszurollen und dort PHP-FPM anschließend zu testen.


    Sobald wir weitere Infos haben, werden wir diese hier bekanntgeben.


    Viele Grüße


    -Klaus Keppler

  • DST Root CA X3 wird am 30. September ablaufen.

    Zitat von ñull

    Wie verhindern wir, dass es dabei zu Problemen kommt?


    Nach unserem aktuellen Kenntnisstand gibt es keinen Handlungsbedarf. :D


    Seit 04. Mai 2021 stellt Let's Encrypt die Zertifikate standardmäßig so aus, dass in der CA-Chain auch das Zwischenzertifikat "DST Root CA X3" enthalten ist (siehe Ankündigung). Man kann das z.B. mit unserem SSL-Check prüfen - etwa für demo.liveconfig.com.


    Somit sollen auch ältere Android-Geräte keine Sicherheitswarnung anzeigen.


    Es besteht also kein Grund, Zertifikate neu auszustellen.

  • Ausblick auf das nächste große Release

    Hallo zusammen,


    heute möchten wir einen kleinen Einblick und Ausblick auf die LiveConfig-Entwicklung geben.


    Der "Kern" von LiveConfig ist inzwischen rund zehn Jahr alt. Die Architektur insgesamt hat sich bislang sehr gut bewährt - aber sie stößt in manchen Bereichen an ihre Grenzen. Insbesondere die Integration externer Dienste (Backup, Policy-Daemon, etc.) oder der Dateiaustausch mit Multi-Server-Systemen läuft nicht so wie wir es uns wünschen.


    So haben wir die letzten 18 Monate (war da sonst noch was? ;)) genutzt, um den technischen Unterbau komplett auszutauschen und mit modernsten Mitteln neu aufzusetzen. Es gibt nun eine neue "Kernbibliothek", welche die Grundlage für alle LiveConfig-Tools darstellt und eine noch nie dagewesene Integration ermöglicht. Einzelne Komponenten dieser Bibliothek sind jetzt schon in LiveConfig enthalten, der größte Teil kommt aber erst mit dem nächsten Release zum Einsatz.


    Dieses nächste Release - LiveConfig 3 - ist aktuell in Arbeit. Neben dem neuen Backend gibt es mit dieser Version eine neue, modernere Oberläche sowie viele Features, die bislang technisch nicht möglich waren. Die kritischsten Komponenten (die Lua-Scripte zur Systemverwaltung sowie das komplette Datenbankmodell) bleiben unverändert erhalten, um einen zuverlässigen Übergang zu ermöglichen.


    Heute in zwei Wochen starten wir in die (geschlossene) Alpha-Phase, am 31.01.2022 startet die Beta-Phase.


    Während der Alpha-Phase "verpasst" niemand etwas, wir führen diese bewusst geschlossen durch um möglichst viele Ressourcen in die Entwicklung stecken zu können. Während der Beta-Phase hat dann jeder die Möglichkeit, LiveConfig 3 ausführlich zu testen und Feedback zu geben.


    Aktuell liegen wir sehr gut im Zeitplan, und die neuen Features machen richtig Spaß. Am liebsten würden wir LC3 jetzt schon zeigen, aber eine dreistellige Anzahl an offenen ToDo-Punkten muss erst noch abgearbeitet werden. Wir werden hier im Forum regelmäßig über den Entwicklungsfortschritt berichten, den Kreis der Alpha-Teilnehmer stückweise erweitern und so möglichst transparent und pünktlich das neue Release veröffentlichen.


    Weitere Details zum genauen Funktionsumfang und den wichtigsten neuen Features werden wir mit dem Start der Beta-Phase veröffentlichen. Vielen Dank schonmal für das Verständnis!


    Viele Grüße


    -Klaus Keppler


    PS: das "aktuelle" LiveConfig 2.x wird selbstverständlich auch weiter entwickelt. Da wir Komponenten-orientiert arbeiten ist das kein doppelter Aufwand. Manche "große" Features sind aber erst mit dem neuen Backend möglich.

  • Sicherheitsabfrage vor Löschung / Undo-Funktion

    Danke für die Vorschläge. Wir haben den "löschen"-Button nun so verlegt, dass dieser nur noch im ersten Tab ("Postfach") auftaucht. Sollten in dem Postfach auch Mails liegen, dann erscheint im Rückfrage-Dialog eine zusätzliche Zeile: "Alle in diesem Postfach enthaltenen E-Mails werden unwiderruflich gelöscht.". In anderen Tabs ist das Löschen des Postfachs somit auch nicht mehr möglich:


    forum.liveconfig.com/cms/attachment/19/


    Eine Eingabe der kompletten Mailadresse zur Bestätigung ist bei einzelnen Kunden sicherlich sinnvoll, andere Kunden treibt das aber garantiert in den Wahnsinn. ;) Wir denken da eher an eine zusätzliche Checkbox, die zum Löschen von Postfächern angeklickt werden muss (was Profi-Anwender auch auf Dauer irgendwie abschalten können sollten).
    Ein zeitversetztes Löschen geht in die Richtung "Papierkorb" (steht bereits auf der Ideenliste). Wir überarbeiten die gesamte GUI derzeit (weitere Infos dazu spätestens Anfang Oktober), da können wir sicher noch die eine oder andere Anregung aufnehmen.


    Die oben gezeigte Änderung ist in LiveConfig 2.12.3 enthalten (ab sofort als Preview online, Stable-Release Anfang kommender Woche).


    Viele Grüße & ein schönes Wochenende


    -Klaus Keppler

  • Bitte die Möglichkeit bereitstellen, Mails in einen Spam-Ordner sortieren zu können!

    Ich verstehe das nicht. Der Kunde wünscht einen Spam-Ordner, um darin ausdrücklich nach versehentlich als Spam markierten Mails zu suchen, damit ihm keine wichtigen Mails entgehen?


    Es landen doch alle E-Mails im Posteingang. Ein "Spam-Ordner" macht es somit unübersichtlicher und sorgt dafür, dass wichtige E-Mails eher noch später gefunden werden.


    Genau hier erkennt man doch eigentlich, wie unsinnig ein "Spam-Ordner" ist. Die Arbeit gehört vielmehr in ein sinnvolles Tuning des Spamfilters investiert, so dass es möglichst wenige "verdächtige" E-Mails gibt.


    Für Unbelehrbare werden wir etwas auf Basis von ManageSieve vorbereiten - werden das aber ausdrücklich nicht empfehlen.