NEWS

Sven Schumacher

@negalein für alles rund um Wetter, Pollen, Luftmessung könnte man auch "Umwelt" sagen.

Das acme-script würde ich, wenn ich nach so etwas suchen würde, vermutlich unter "System" suchen.

Sven Schumacher

Mein iobroker hängt im Netz und ist über SSL abgesichert. Letsencrypt.
Aber seit ACME.Adapter der Weg für iobroker ist, ein Cert zu bekommen, hatte ich zunächst keinen Weg gefunden, wie ich das für Grafana verwenden kann, weil es eben nicht mehr im Dateisystem liegt. Auch andere Adapter können nicht auf solche Zertifikate zugreifen.

Deshalb das Script. Das Speichert die im Dateisystem und da kann man sie dann eben für alle anderen Dienste auf dem PI weiterverwenden, die auch im Netz sein sollen.

Sven Schumacher

@negalein https://forum.iobroker.net/topic/77021/acme-letsencrypt-zertifikate-extrahieren/1

Hier dann auch das Script zum extrahieren der mit dem acme.adapter erzeugten letsencrypt Zertifikate. Für die Verwendung durch andere Adapter oder Software auf dem iobroker Rechner.

Sven Schumacher

@oliverio schon klar ... Ich vertraue hier - bei meiner nicht ganz so sensiblen Steuerung - auf den aktuellen und immer gepflegten Debian-Unterbau.
Dazu lasse ich natürlich nur Ports durch, die ich wirklich brauche.

Und dann habe ich keine SSL-Fehler, sondern ein schönes Cert für alle Dienste. Was iobroker seit der "Verbesserung" durch die Einführung von ACME eben nicht mehr so hinbekommt, ohne Hilfe.

Sicher ist Paranoia durchaus ein gutes Konzept zum Schutz solcher Dinge. Allerdings ist mir der Aufwand zu groß. Und man hört auch nicht wirklich oft davon, dass Hoster ihre Debian-Server hinter Reverse-Proxys verstecken. Aber ja, es kann die Sicherheit verbessern, auf Kosten des Aufwands.

UND es ist hier ganz sicher off-Topic

Sven Schumacher

Ich habe einen iobroker, der einige Dienste von Außen erreichbar macht.

Seit dem IoBroker-Admin nur noch auf den ACME.Adapter verweist, hatte ich das Problem, dass ich das erhaltene Cert nur noch für den Admin nutzen konnte. Es tauchte nirgendwo mehr im Dateisystem auf.

Ich habe die Zertifikate letzte Woche dann unter system.certificates bei den Objekten gefunden. Dort stehen sie neben den anderen eingetragenen Zertifikaten in einem JSON in einer "collection", die man im ACME.Adapter anlegt.

Das Script extrahiert key, cert und chain aus der oder den collections und speichert sie in nutzbarer Form in einem Verzeichnis, welches am Anfang des Scripts definiert ist.
Dem Namen wird der Name der collection vorangestellt. (Falls man mehrere collections nutzen möchte ist das erforderlich)

Es wird per Voreinstellung ein Flag im gleichen Verzeichnis erzeugt, wenn ein bestehendes Zertifikat sich geändert hat. Damit kann ein systemctl/cron/Aufgabenplanung-Job prüfen, ob ein Dienst neu gestartet werden muss. Das habe ich so gemacht, weil es ohne besondere Rechte funktioniert und unabhängig vom OS oder Geschmacksrichtung.

Die Konfiguration erfolgt in den Zeilen:

// Configuration
const certificatesPath = '/opt/iobroker/certificates/'; // Default certificates directory
const createFlag = true; // Control whether to create the restart flag

Ich habe mich für /opt/iobroker/certificates/ als Pfadvorgabe entschieden, weil IOBROKER da Schreibrechte besitzt, ohne dass man etwas ändern muss.
Wer da was anderes möchte muss ggf. die Recht selbst anpassen.

So kann man die Files in Admin bei den Zertifikaten verlinken und in anderen Adapter nutzen, die die collections von ACME nicht sehen.
Oder man kann z.B. Grafana damit ausstatten.

Um das mit GitHub auch mal zu üben, hab ich das hier angelegt. Fragen, Anregungen, Verbesserungsvorschläge oder Hinweise gerne hier. Das Script kann man immer aktuell vom GitHub laden.

Beispiel für debian systemctl timer-job (wenn man Grafana automatisch neu starten will, wenn es ein neues Cert gibt):
Ich habe hier eine collection "home" ... ihr müsste das an eure Namen anpassen, wenn hier unten etwas steht wie
FLAG_FILE="/opt/iobroker/certificates/home_new_ssl_cert.txt"
"home" ist hier der Name der collection, die ich im ACME.Adapter konfiguriert habe

Ebenso ist grafana natürlich nur ein Beispiel.

Wir brauchen ein Script, was prüft ob das Flag existiert und dann entweder grafana neu startet und das flag löscht , oder eben nichts tut,

Scriptdatei erstellen:

sudo nano /usr/local/bin/grafana-restart.sh

Diesen Inhalt einfügen

#!/bin/bash

# Path to the flag file
FLAG_FILE="/opt/iobroker/certificates/home_new_ssl_cert.txt"

# Name of the Grafana service
GRAFANA_SERVICE="grafana-server"

# Check if the flag file exists
if [ -f "$FLAG_FILE" ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Flag file found. Restarting Grafana..."

    # Restart the Grafana service
    systemctl restart "$GRAFANA_SERVICE"

    # Check if the restart was successful
    if [ $? -eq 0 ]; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Grafana restarted successfully. Deleting flag file."

        # Delete the flag file
        rm "$FLAG_FILE"
    else
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Failed to restart Grafana. Flag file not deleted."
        exit 1
    fi
else
    echo "$(date '+%Y-%m-%d %H:%M:%S') - No flag file found. No action needed."
fi

Das Script ausführbar machen:

sudo chmod +x /usr/local/bin/grafana-restart.sh

Dann brauchen wir eine systemd-Dienstdatei:

sudo nano /etc/systemd/system/grafana-restart.service

in der dann stehen muss:

[Unit]
Description=Restart Grafana if SSL Certificate Flag Exists

[Service]
Type=oneshot
ExecStart=/usr/local/bin/grafana-restart.sh

Dazu einen Timer, der die Dienstdatei zur gewünschten Zeit aufruft.

sudo nano /etc/systemd/system/grafana-restart.timer

mit dem Inhalt:

[Unit]
Description=Timer to Restart Grafana if SSL Certificate Flag Exists at 01:00 AM Daily

[Timer]
OnCalendar=*-*-* 01:00:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl neu starten, damit der den neuen Dienst sehen kann.

sudo systemctl daemon-reload

Und den Dienst aktivieren:

sudo systemctl enable --now grafana-restart.timer

Und prüfen ob das funktioniert hat:

Flag manuell erzeugen:

sudo touch /opt/iobroker/certificates/home_new_ssl_cert.txt

Dienst von Hand starten (nicht erst um 01:00)

sudo systemctl start grafana-restart.service

Status ausgeben:

systemctl status grafana-restart.timer

Dann sollte das ungefähr so aussehen am Ende:

Sep 22 18:03:02 iobroker2 systemd[1]: Starting Restart Grafana if SSL Certificate Flag Exists...
Sep 22 18:03:02 iobroker2 grafana-restart.sh[115815]: 2024-09-22 18:03:02 - Flag file found. Restarting Grafana...
Sep 22 18:03:02 iobroker2 grafana-restart.sh[115815]: 2024-09-22 18:03:02 - Grafana restarted successfully. Deleting flag fil>
Sep 22 18:03:02 iobroker2 systemd[1]: grafana-restart.service: Succeeded.
Sep 22 18:03:02 iobroker2 systemd[1]: Finished Restart Grafana if SSL Certificate Flag Exists.

Sven Schumacher

@negalein
Ich habe das Thema zu dem Script eröffnet. https://forum.iobroker.net/topic/77021/acme-letsencrypt-zertifikate-extrahieren
Ja, die Diskussion hier ist nicht sinnvoll. Sorry, dass ich mich hab provozieren lassen.

Dass MIC nicht mehr online ist, ist schade. Gibt es im Forum eine Art WIKI?

Sven Schumacher

@sven-schumacher Und dann das Übliche:

Ich habe:

alles gemacht, wozu ICH in der Lage bin, um den Fehler reproduzierbar zu machen.
es so einfach gemacht, wie es geht, um alle möglichen fremden Fehlerquellen ausschließen zu können.
es von mehreren Orten und Systemen getestet.
es ausführlich auf GitHub beschrieben.

Aber auf GITHUB erwartet man, dass ich auch wireshark-Protokolle erstellen und auswerten soll. Das kann ich auf den Maschinen nicht und ich kann die Ergebnisse auch nicht wirklich lesen und verstehen.

Aber dort ist man der Meinung, ich müsse mir mehr Mühe geben.

Nein! Ich bin letztlich User, nicht DevOp. Genau an der Stelle scheitern viele Linuxprojekte für Anwender, weil hier Hürden entstehen, die unüberwindbar sind.

Dann bleibt der Fehler eben bestehen. Mit Mosquitto geht jetzt (fast) alles.
Ich hab’ nur noch Fragen zu QOS … aber das ist etwas anderes. SSL/TLS geht, und zwar mit genau den Certs und mit genau den Einstellungen, die bei dem Adapter nicht funktioniert haben.

Sven Schumacher

@marc-berg Dann natürlich ohne Integration in Admin ... Das ist weniger übersichtlich.
Deswegen hatte ich das nicht gleich schon versucht.

Vorteil ist, dass es keine states erzeugt. Das hilft bei der Performance.

Aber dann bleibt mir da wohl nichts übrig. Scheint auch niemanden dort zu interessieren, der bug.

Sven Schumacher

Ich möchte gerne einen MQTT anbieten, der per TLS verschlüsselt kommuniziert.

Unverschlüsselt geht es problemlos. Von außen, aus dem lokalen Netz und local.
Mit TLS hatte ich auf keinem Weg Erfolg. So teste ich jetzt auf dem Server selbst zwei Instanzen:
mqtt.0 ist der Server
mqtt.1 ist der Client

Ich nutze vom Client die IP 127.0.0.1 um zum Server zu verbinden. Eine Firewall ist auf dem Rechner selbst nicht installiert.

Ohne TLS/SSL klappt die Verbindung umgehend und ich sehe die States von mqtt.0 in mqtt.1
Mit TLS zeigt der Client an, dass er verbunden ist, aber der Server weiß davon nicht. Der Client macht dann einen neuen Versuch sich zu verbinden. Allerdings ohne Erfolg.

SSL-Verbindungen zu Admin, Grafana, NodeRed und VIS sind fehlerfrei.

Ich sehe auch mit "Silly"-Einstellungen keine Einträge im Log im Admin.

Ich habe offizielle LetsEncrypt-Zertifikate benutzt, die für SSL wunderbar funktionieren.
Ich habe auch selbst signierte Zertifikate benutzt. Zum Test habe ich nicht nur moderne Zertifikate erstellt, sondern auch TLS 1.1 kompatible RSA-Zertifikate.

Hat schon mal jemand einen Server mit dem MQTT.Adapter erstellt, der z. B. mit MQTT-Explorer erreichbar war?
Wenn SSL hier aus irgendeinem Grund eben nicht geht; welchen Broker könnte ich noch einsetzen?

gibt es irgendwo andere logs?

Das hier sehe ich mit TCPDUMP

sudo tcpdump -i any host 192.168.240.105 and tcp port 8883
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
14:24:57.729311 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [S], seq 3221089395, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
14:24:57.729332 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [S.], seq 165142938, ack 3221089396, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:24:57.730863 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [.], ack 1, win 1026, length 0
14:24:57.732400 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [P.], seq 1:256, ack 1, win 1026, length 255
14:24:57.732410 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [.], ack 256, win 501, length 0
14:24:57.733087 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [P.], seq 1:1098, ack 256, win 501, length 1097
14:24:57.736429 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [P.], seq 256:681, ack 1098, win 1022, length 425
14:24:57.737160 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [P.], seq 1098:1672, ack 681, win 501, length 574
14:24:57.779762 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [.], ack 1672, win 1026, length 0

Das log zeigt den Versuch einer Verbindung vom Laptop. Wenn ich eine Weile warte, dann kommt das gleiche immer wieder mit jeweils einem zufälligen Port im Hohen Bereich

Sven Schumacher

@negalein warum gibt es zwei Sektionen "System" ? Ein bisschen verwirrend

Sven Schumacher