Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Sven Schumacher]

LetsEncrypt Zertifikate für z.B. Grafana oder andere auf dem gleichen Host nutzbar machen.

IOBROKER verweist auf den ACME-Adapter um Zertifikate für ADMIN zu erzeugen.
Allerdings hat man regelmäßig z.B. Grafana oder andere Adapter/Dienste laufen, die auch ein Zertifikat brauchen und das über den Weg nicht können.

ACME legt die Zertifikate in einem JSON unter system.certificates ab. Sogar im Klartext.
Also habe ich Script erzeugt, welches diese dort extrahiert und unter /opt/iobroker/certificates ablegt. Benannt nach dem Schema
[collection]_key.pem
[collection]_cert.pem
[collection]_chain.pem

Von dem Ort aus kann man das nun weiter verwenden.

Das Script erzeugt die Keys beim Start und danach läuft es alle 24h. Nicht übermäßig kompliziert, aber nützlich.

const fs = require('fs');
const path = '/opt/iobroker/certificates/';  // Übliches Verzeichnis für Zertifikate

// Funktion zum Speichern der Zertifikatsdateien
function speichereZertifikate(collectionName, privateKey, publicCert, chainCert) {
    // Erstellen des Verzeichnisses, falls es nicht existiert
    if (!fs.existsSync(path)) {
        fs.mkdirSync(path, { recursive: true });
    }

    // Dateien mit dem Collection-Namen speichern
    const privateKeyPath = `${path}${collectionName}_key.pem`;
    const publicCertPath = `${path}${collectionName}_cert.pem`;
    const chainCertPath = `${path}${collectionName}_chain.pem`;

    // Speichern des privaten Schlüssels
    fs.writeFileSync(privateKeyPath, privateKey);
    console.log(`Privater Schlüssel gespeichert unter: ${privateKeyPath}`);

    // Speichern des Zertifikats
    fs.writeFileSync(publicCertPath, publicCert);
    console.log(`Zertifikat gespeichert unter: ${publicCertPath}`);

    // Falls eine Zertifikatskette vorhanden ist, diese speichern
    if (chainCert) {
        fs.writeFileSync(chainCertPath, chainCert);
        console.log(`Zertifikatskette gespeichert unter: ${chainCertPath}`);
    } else {
        console.log('Keine Zertifikatskette für die Collection: ' + collectionName + ' gefunden.');
    }
}

// Funktion zum Abrufen und Speichern der Zertifikate aus allen Collections
function verarbeiteZertifikate() {
    getObject('system.certificates', function (err, obj) {
        if (err || !obj || !obj.native || !obj.native.collections) {
            console.log('Fehler: Zertifikatssammlungen konnten nicht abgerufen werden.');
            return;
        }

        const collections = obj.native.collections;

        // Alle Collections durchlaufen
        Object.keys(collections).forEach(function (collectionName) {
            const collection = collections[collectionName];

            if (collection.key && collection.cert) {
                // Privater Schlüssel und Zertifikat aus der Collection extrahieren
                const privateKey = collection.key;
                const publicCert = collection.cert;

                // Zertifikatskette extrahieren, falls vorhanden
                const chainCert = collection.chain ? collection.chain.join('\n') : null;

                // Zertifikate mit dem dynamischen Collection-Namen speichern
                speichereZertifikate(collectionName, privateKey, publicCert, chainCert);
            } else {
                console.log(`Keine gültigen Zertifikate für die Collection: ${collectionName} gefunden.`);
            }
        });
    });
}

// Beim Start einmalig die Zertifikate verarbeiten
verarbeiteZertifikate();

// Alle 24 Stunden (86400000 ms) das Skript erneut ausführen
schedule("0 0 * * *", function () {
    verarbeiteZertifikate();
});

javascript.0	18:28:09.851	info	Start JavaScript script.js.common.System.ACME_Letsencrypt_export (Javascript/js)
javascript.0	18:28:09.925	info	script.js.common.System.ACME_Letsencrypt_export: registered 0 subscriptions, 1 schedule, 0 messages, 0 logs and 0 file subscriptions
javascript.0	18:28:09.940	info	script.js.common.System.ACME_Letsencrypt_export: Privater Schlüssel gespeichert unter: /opt/iobroker/certificates/home_key.pem
javascript.0	18:28:09.947	info	script.js.common.System.ACME_Letsencrypt_export: Zertifikat gespeichert unter: /opt/iobroker/certificates/home_cert.pem
javascript.0	18:28:09.949	info	script.js.common.System.ACME_Letsencrypt_export: Zertifikatskette gespeichert unter: /opt/iobroker/certificates/home_chain.pem

[mcm1957]

@sven-schumacher said in [Aufruf] Welche guten JavaScripts setzt ihr ein?:

/opt/iobroker/certificates/

Danke f.d. Skript.

@apollon77
@Thomas-Braun

const path = '/opt/iobroker/certificates/'; // Übliches Verzeichnis für Zertifikate

Frage:
Ist das Anlegen eines neuen privaten Ordners in /opt/iobroker "zulässig" oder eher davon abzuraten? Auch wenn es derzeit funktioniert, kann es da zukünftig zu Problemen kommen oder ist der Platz explizit für private Daten vorgesehen?

[Sven Schumacher]

@mcm1957 Ich weiß es nicht sicher. Allerdings ist das /opt/iobroker eben eh da und früher hat letsencrypt dort seine Zertifikate abgelegt.
Es ist im Zweifel kein Problem ein anderes Verzeichnis zu nutzen. Das ist ja im Quelltext leicht zu ändern.

const path = '/opt/iobroker/certificates/';  // Übliches Verzeichnis für Zertifikate

Da könnte man auch /etc/eigenezertifikate/ eintragen oder so. Ist vermutlich egal.

[sigi234]

@mcm1957
Muss das für Windows Systeme auch angepasst werden?

Wäre für das Meeting interessant.

[Sven Schumacher]

@sigi234 windows benutzt einen "\" anstatt eines "/" ...
Ich habe iobroker bisher nur unter debian / Raspian eingesetzt. Halte ich auch für die bessere Lösung.

[Thomas Braun]

@mcm1957 sagte in [Aufruf] Welche guten JavaScripts setzt ihr ein?:

Ist das Anlegen eines neuen privaten Ordners in /opt/iobroker "zulässig" oder eher davon abzuraten?

Unterhalb von /opt/iobroker kannste treiben was du willst. Ich würde aber empfehlen, das Dinge die nicht unmittelbar zum iobroker gehören (certs für grafana z. B.) da nicht reingerührt werden. Hat da nix zu suchen und da werden die auch nicht gesucht.

[Sven Schumacher]

@thomas-braun Ich nutze es so, aus Gewohnheit.
Aber wenn es schöner anders geht, dann gerne einen Tipp, den ich gerne berücksichtigen werde. Ich bin bei Linux nicht zu tief drin. Ich nutze das nur.

[Thomas Braun]

@sven-schumacher

Das Standard-Verzeichnis ist /etc/ssl/certs/ (bzw. /etc/ca-certificates/)
Da tummelt sich auch der große Rest.

[mcm1957]

@sigi234 said in [Aufruf] Welche guten JavaScripts setzt ihr ein?:

@mcm1957
Muss das für Windows Systeme auch angepasst werden?

Wäre für das Meeting interessant.

Nö soweit ich weiß.
Node setzt das um. Im Gegenteil, ih glaub in node / jsscript funktioniert\ gar nicht. Ich

[mcm1957]

@sven-schumacher said in [Aufruf] Welche guten JavaScripts setzt ihr ein?:

@mcm1957 Ich weiß es nicht sicher. Allerdings ist das /opt/iobroker eben eh da und früher hat letsencrypt dort seine Zertifikate abgelegt.
Es ist im Zweifel kein Problem ein anderes Verzeichnis zu nutzen. Das ist ja im Quelltext leicht zu ändern.

War mir nur nicht sicher ob /opt/iobroker für Daten die nciht von ioBroker oder einem Adapter kommen "freigegeben" ist. Da das der Fall zu sein scheint - alles OK, abgesehen von der generellen Anregung von Thomas (die dann aber auf Windows angepasst werden muss)

[Thomas Braun]

@mcm1957 sagte in [Aufruf] Welche guten JavaScripts setzt ihr ein?:

War mir nur nicht sicher ob /opt/iobroker für Daten die nciht von ioBroker oder einem Adapter kommen "freigegeben" ist.

Das ist ein gutes Stichwort...
Ich bin in dem Thema 'Certificates' aber überhaupt nicht firm, allerdings muss man da mit den Rechten auf den Verzeichnissen aufpassen, insbesondere beim 'geheimen' Teil der Schlüssel.
LetsEncrypt hat wohl
/var/lib/letsencrypt/backups
/etc/letsencrypt/
usw. verwendet. Jedenfalls nix in /opt/iobroker.
Ich könnte mir auch vorstellen, das der 'iob fix' da die Rechte wieder 'gleichmacht' und die Verzeichnisse zu offen hinlegt.

[Sven Schumacher]

@thomas-braun als letsencrypt noch in iobroker selbst lief, war es bei mir /opt/iobroker/letsencrypt/certificates... Oder so ähnlich.

Aber gerne kann das Script hier auch mit /etc/certs/ veröffentlicht werden. Hauptsache es hilft.

[apollon77]

@mcm1957 Offiziell gibts da nix. und ja /opt/iobroker kann man eigenen kram anlegen. besser da also in den unterverzteichnissen die "iobroker gehören" :-)

[mcm1957]

@apollon77 said in [Aufruf] Welche guten JavaScripts setzt ihr ein?:

@mcm1957 Offiziell gibts da nix. und ja /opt/iobroker kann man eigenen kram anlegen. besser da also in den unterverzteichnissen die "iobroker gehören" :-)

OK, danke f.d. Klarstellung. War nur unsicher ...
Ergo alles paletti :+1:

[Sven Schumacher]

@mcm1957

Ich hab ein Git angelegt ... mein erstes ;)

https://github.com/bitboy00/iobroker-skripte/tree/main

Da könnten noch andere Sachen entstehen. Das Script habe ich nochmal angepasst und umgebaut. Sollte jetzt etwas zeitgemäßer sein und der Pfad ist auch jetzt /etc/ssl/certs/

[MartinP]

ESP01S mit original-Firmware ansprechen - das ist mehr so eine WIFI <-> seriell Brücke... mein Script beschränkt sich auf das Absetzen von bestimmten Telegrammen an den ESP01S, die dieser weitergibt an das Relais Board auf dem er Huckepack aufsitzt ...
https://de.aliexpress.com/item/1005004658293317.html

Erspart das Flashen mit Tasmota ...

https://forum.iobroker.net/topic/64248/garagentor-fernbedienung-esp01-javascript?_=1726738714727

[OliverIO]

@sven-schumacher

Also ich verstehe nicht so ganz um was für Zertifikate es hier geht?
Ssl Webserver ?
Dann so wie von Grafenau beschrieben.
https://grafana.com/docs/grafana/latest/setup-grafana/set-up-https/

Wobei, wenn es um öffentlichen Zugriff geht. ich immer einen reverse proxy dazwischen schalten würde. Dann kommen die Zertifikate dort hin.
Graugans scheint ja sicher genug zu sein das es das aushält.

[Sven Schumacher]

@oliverio Ja, SSL ...

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.

[OliverIO]

@sven-schumacher

Ssl ist keine Sicherung für den Server sondern nur eine Sicherung für den Transport. Auf den Server dazwischen über die Daten transportiert werden kann keiner mitlesen.
Deinen Server kann man trotzdem versuchen anzugreifen

[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 ;)