Skip to content

Technik Blog

IoT, Smart Home & Mikrocontroller einfach erklärt

Menu
  • Smarthome
  • Gartenautomation
  • Mikrocontroller
    • Arduino
    • ESP32 & Co.
    • Calliope Mini
    • Raspberry Pi & Pico
  • Solo Mining
  • Über mich
Menu

Node-RED mit HTTPS absichern – SSL/TLS einrichten und Verbindung verschlüsseln

Veröffentlicht am 21. Oktober 202617. Oktober 2026 von Stefan Draeger

Node-RED wird häufig im Heimnetz eingesetzt, um Smart-Home-Geräte, Sensoren oder andere Dienste zu steuern. Auch dort ist eine verschlüsselte Verbindung sinnvoll, denn standardmäßig erfolgt der Zugriff über unverschlüsseltes HTTP.

Noch wichtiger wird HTTPS, wenn Node-RED von außen erreichbar ist. Dann sollte die Kommunikation zwischen Browser und Node-RED unbedingt verschlüsselt werden.

Ein Benutzername mit Passwort schützt zwar den Zugriff, verschlüsselt aber nicht die Verbindung. Genau dafür sorgt HTTPS.

In diesem Beitrag zeige ich dir, wie du Node-RED mit HTTPS absicherst.

Node-RED mit HTTPS absichern – TLS-Zertifikat einrichten & Verbindung verschlüsseln
Dieses Video auf YouTube ansehen.

Hinweis: Häufig wird noch der Begriff SSL-Zertifikat verwendet. Technisch korrekt ist heute jedoch TLS-Zertifikat, da moderne HTTPS-Verbindungen über TLS abgesichert werden. SSL gilt als veraltet. In diesem Beitrag verwende ich daher überwiegend den Begriff TLS-Zertifikat.

Inhaltsverzeichnis

  • Warum HTTPS bei Node-RED wichtig ist
  • Das SSL-/TLS-Zertifikat
  • Eigenes TLS-Zertifikat für Node-RED erstellen
  • TLS-Zertifikate in Docker einbinden
    • Docker-Container nach Änderung neu erstellen
  • Die richtige settings.js finden und HTTPS aktivieren
    • Hinweis bei selbstsignierten TLS-Zertifikaten
  • Fazit

Warum HTTPS bei Node-RED wichtig ist

Bei einer normalen HTTP-Verbindung werden die Daten zwischen deinem Browser und Node-RED unverschlüsselt übertragen. Vereinfacht gesagt können Informationen auf dem Übertragungsweg mitgelesen werden, wenn jemand Zugriff auf das Netzwerk oder den Datenverkehr hat.

Bei HTTPS wird die Verbindung zusätzlich mit TLS verschlüsselt. Browser und Node-RED bauen dabei zunächst eine geschützte Verbindung auf. Erst danach werden die eigentlichen Daten übertragen.

Das betrifft nicht nur die Anmeldung am Node-RED-Editor, sondern auch Steuerbefehle, Formulardaten oder Inhalte aus einem Dashboard.

Vereinfacht sieht der Unterschied so aus:

HTTP vs. HTTPS bei Node-RED
HTTP vs. HTTPS bei Node-RED

Spätestens wenn Node-RED nicht nur lokal genutzt wird, sondern auch von außen erreichbar ist, sollte die Verbindung verschlüsselt sein.

Das SSL-/TLS-Zertifikat

Damit Node-RED eine HTTPS-Verbindung anbieten kann, wird ein SSL-/TLS-Zertifikat benötigt. Dieses Zertifikat weist gegenüber dem Browser die Identität des Servers nach und wird gleichzeitig für den Aufbau der verschlüsselten Verbindung verwendet.

Für das Zertifikat hast du zwei Möglichkeiten: entweder ein Zertifikat einer vertrauenswürdigen Zertifizierungsstelle oder ein selbst signiertes Zertifikat.

Ein selbstsigniertes Zertifikat verschlüsselt die Verbindung ebenfalls. Da dieses Zertifikat jedoch nicht von einer dem Browser bekannten Zertifizierungsstelle bestätigt wurde, erscheint beim Aufruf von Node-RED normalerweise eine Sicherheitswarnung. Der Browser kann in diesem Fall nicht überprüfen, ob das Zertifikat tatsächlich zu dem aufgerufenen Server gehört.

Hinweis im Browser bei selbst signierten TLS-Zertifikaten
Hinweis im Browser bei selbst signierten TLS-Zertifikaten

Bei einem Zertifikat einer vertrauenswürdigen Zertifizierungsstelle kann der Browser diese Prüfung durchführen. Die HTTPS-Verbindung wird dann ohne entsprechende Zertifikatswarnung aufgebaut.

Für ein ausschließlich im eigenen Heimnetz betriebenes Node-RED kann ein selbstsigniertes Zertifikat durchaus eine Möglichkeit sein. Soll Node-RED jedoch öffentlich über das Internet erreichbar sein, sollte ein Zertifikat einer vertrauenswürdigen Zertifizierungsstelle verwendet werden.

Eigenes TLS-Zertifikat für Node-RED erstellen

Für den Einsatz im eigenen Heimnetz kannst du zunächst ein selbstsigniertes TLS-Zertifikat erstellen. Dieses verschlüsselt die Verbindung zwischen Browser und Node-RED, wird vom Browser jedoch nicht automatisch als vertrauenswürdig eingestuft.

Am einfachsten lässt sich das Zertifikat mit OpenSSL erzeugen.

Wechsle zunächst in das Node-RED-Verzeichnis:

cd ~/.node-red

und erstelle dort ein Verzeichnis und wechsle in dieses

mkdir certs
cd certs

Anschließend erzeugst du einen privaten Schlüssel und das dazugehörige Zertifikat:

openssl req -x509 -newkey rsa:4096 \
  -keyout privkey.pem \
  -out cert.pem \
  -sha256 \
  -days 365 \
  -nodes
erstellen eines eigenen TLS-Zertifikats über WSL unter Windows 11
erstellen eines eigenen TLS-Zertifikats über WSL unter Windows 11

Während der Erstellung fragt OpenSSL einige Angaben ab. Besonders wichtig ist der Eintrag Common Name (CN). Hier kannst du beispielsweise den Hostnamen deines Node-RED-Servers eintragen.

Nach dem Erstellen befinden sich zwei neue Dateien im Verzeichnis:

  • privkey.pem – enthält den privaten Schlüssel und sollte nicht weitergegeben werden
  • cert.pem – enthält das eigentliche TLS-Zertifikat

Mit diesen beiden Dateien kann HTTPS anschließend in Node-RED aktiviert werden.

TLS-Zertifikate in Docker einbinden

Meine Node-RED-Installation verwendet aktuell ein Docker-Volume für die persistenten Daten:

services:
  node-red:
    image: nodered/node-red
    container_name: nodered
    ports:
      - "1880:1880"
    environment:
      - npm_config_python=/usr/bin/python3
    volumes:
      - node_red_data:/data
    restart: unless-stopped

volumes:
  node_red_data:

Für das TLS-Zertifikat lege ich auf dem Docker-Host zusätzlich ein Verzeichnis certs an:

Anzeigen des Verzeichnisinhalts für Node-RED Container
Anzeigen des Verzeichnisinhalts für Node-RED Container

Dieses Verzeichnis wird anschließend zusätzlich in den Container eingebunden:

services:
  node-red:
    image: nodered/node-red
    container_name: nodered
    ports:
      - "1880:1880"
    environment:
      - npm_config_python=/usr/bin/python3
    volumes:
      - node_red_data:/data
      - ./certs:/certs:ro
    restart: unless-stopped

volumes:
  node_red_data:

Mit

- ./certs:/certs:ro

wird das lokale Verzeichnis certs im Container unter /certs bereitgestellt. Der Zusatz :ro bindet das Verzeichnis nur lesbar ein.

Node-RED kann anschließend auf folgende Dateien zugreifen:

  • /certs/cert.pem
  • /certs/privkey.pem

Diese Pfade verwenden wir anschließend in der settings.js, um HTTPS zu aktivieren.

Docker-Container nach Änderung neu erstellen

Nachdem das Zertifikatsverzeichnis in der docker-compose.yml ergänzt wurde, reicht ein einfacher Neustart des bestehenden Containers nicht aus. Docker übernimmt Änderungen an Volumes erst, wenn der Container neu erstellt wird.

Dazu genügt:

docker compose up -d --force-recreate
Docker Container nach einer Änderung neu erstellen
Docker Container nach einer Änderung neu erstellen

Ein neues Node-RED-Image muss dabei nicht gebaut werden. Es wird lediglich der Container mit der aktualisierten Konfiguration neu erstellt.

Anschließend kannst du prüfen, ob die Zertifikate im Container verfügbar sind:

docker exec -it nodered ls -l /certs

Dort sollten nun cert.pem und privkey.pem angezeigt werden.

Die richtige settings.js finden und HTTPS aktivieren

Damit Node-RED das TLS-Zertifikat verwendet, muss die Datei settings.js angepasst werden. Gerade bei einer Docker-Installation ist wichtig, wirklich die Datei zu bearbeiten, die vom laufenden Node-RED verwendet wird.

Welche settings.js aktiv ist, zeigt Node-RED beim Start in den Logs an:

docker logs nodered --tail 50

Dort findest du eine Zeile wie:

Settings file  : /data/settings.js

Damit ist klar: Im Container verwendet Node-RED die Datei

/data/settings.js

Da /data bei meiner Installation über ein Docker-Volume eingebunden ist, kann ich zusätzlich prüfen, wo dieses Volume auf dem Host liegt:

docker inspect nodered --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

Die Ausgabe kann beispielsweise so aussehen:

/var/lib/docker/volumes/stdr_node_red_data/_data -> /data
/mnt/c/Users/stdr/node-red/certs -> /certs
Ausgeben der verbundenen Verzeichnisse im Docker Container Node-RED
Ausgeben der verbundenen Verzeichnisse im Docker Container Node-RED

Damit befindet sich die tatsächlich verwendete settings.js auf dem Docker-Host unter:

/var/lib/docker/volumes/stdr_node_red_data/_data/settings.js

In dieser Datei wird anschließend der HTTPS-Bereich aktiviert:

https: {
    key: require("fs").readFileSync("/certs/privkey.pem"),
    cert: require("fs").readFileSync("/certs/cert.pem")
},

Wichtig ist, dass der Block nicht mehr mit // auskommentiert ist.

Nach dem Speichern genügt ein Neustart des Containers:

docker restart nodered

Anschließend kannst du erneut die Logs prüfen. Wenn die Konfiguration korrekt geladen wurde, erscheint:

Server now running at https://127.0.0.1:1880/
Ausgabe des TLS aktiviert ist im Log von Node-RED beim starten
Ausgabe des TLS aktiviert ist im Log von Node-RED beim starten

Damit ist HTTPS in Node-RED aktiv.

Hinweis bei selbstsignierten TLS-Zertifikaten

Nach der Aktivierung von HTTPS ist die Node-RED-Oberfläche über eine Adresse wie

https://localhost:1880

erreichbar. Wird dabei ein selbstsigniertes Zertifikat verwendet, zeigt der Browser allerdings zunächst eine Sicherheitswarnung an.

Hinweis im Browser bei selbst signierten TLS-Zertifikaten
Hinweis im Browser bei selbst signierten TLS-Zertifikaten

Typisch ist beispielsweise die Meldung:

NET::ERR_CERT_AUTHORITY_INVALID

Der Grund dafür ist, dass das Zertifikat nicht von einer öffentlich vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. Der Browser kann deshalb nicht automatisch bestätigen, dass das verwendete Zertifikat tatsächlich vertrauenswürdig ist.

Die Verbindung selbst wird dennoch über HTTPS verschlüsselt.

Gerade in einer lokalen Entwicklungs- oder Testumgebung ist diese Warnung daher zunächst normal. Über „Erweitert“ kann die Seite in der Regel trotzdem geöffnet werden. Je nach Browser erscheint anschließend beispielsweise die Option:

Weiter zu localhost (unsicher)

Wichtig ist dabei die Unterscheidung: Die Bezeichnung „unsicher“ bedeutet in diesem Fall nicht, dass keine Verschlüsselung verwendet wird. Sie weist lediglich darauf hin, dass der Browser dem verwendeten Zertifikat beziehungsweise dessen Aussteller nicht vertraut.

Für lokale Tests oder Systeme im eigenen Netzwerk kann ein selbstsigniertes Zertifikat ausreichend sein. Soll Node-RED dagegen öffentlich erreichbar sein, sollte ein Zertifikat einer vertrauenswürdigen Zertifizierungsstelle verwendet werden.

Fazit

Damit läuft mein Node-RED nun nicht mehr über eine unverschlüsselte HTTP-Verbindung, sondern über HTTPS. Der eigentliche Aufwand hält sich dabei in Grenzen: Zertifikat erstellen, die Dateien in den Docker-Container einbinden und anschließend den HTTPS-Bereich in der richtigen settings.js aktivieren.

Gerade der letzte Punkt war bei meiner Docker-Installation wichtig. Entscheidend ist nicht irgendeine settings.js auf dem Host, sondern die Datei, die vom laufenden Node-RED tatsächlich verwendet wird.

Beim selbst signierten Zertifikat bleibt allerdings die Warnung des Browsers bestehen. Die Verbindung ist trotzdem verschlüsselt – der Browser kann lediglich nicht bestätigen, dass das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle stammt.

Für mein lokales Setup reicht mir diese Variante zunächst aus. Soll Node-RED später über eine Domain oder dauerhaft aus dem Internet erreichbar sein, würde ich stattdessen ein offiziell signiertes Zertifikat verwenden.

Wie sich beispielsweise ein kostenloses Zertifikat von Let’s Encrypt einrichten lässt, schaue ich mir in einem separaten Beitrag an.

Transparenzhinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und redaktionell geprüft. Mehr zur Nutzung von KI

Letzte Aktualisierung am: 17. Oktober 2026

Foto von Stefan Draeger
Über den Autor

Stefan Draeger — Entwickler & Tech-Blogger

Ich zeige praxisnah, wie du Projekte mit Arduino, ESP32 und Smarthome-Komponenten umsetzt – Schritt für Schritt, mit Code und Schaltplänen.

Mehr Artikel von Stefan →

Schreibe einen Kommentar Antwort abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

Kontakt & Hilfe

Fragen oder Feedback?

Du hast eine Idee, brauchst Hilfe oder möchtest Feedback loswerden? Erstelle einfach ein Support-Ticket.

Support-Ticket erstellen
Keine Beiträge verpassen

Newsletter abonnieren

Erhalte regelmäßig Updates zu neuen Projekten, Tutorials und Tipps rund um Arduino, ESP32, Smarthome und IoT direkt in dein Postfach.

Newsletter abonnieren
Videos & Tutorials

Draeger-IT auf YouTube

Entdecke meine Videos zu Arduino, ESP32, Raspberry Pi, Smarthome und spannenden Elektronikprojekten – mit Tutorials, Tests und Praxisbeispielen.

YouTube-Kanal besuchen
Freiwillige Unterstützung

Unterstütze meinen Blog

Wenn dir meine Inhalte gefallen, freue ich mich über deine Unterstützung auf Tipeee. So hilfst du dabei, den Blog am Leben zu halten und neue Beiträge zu ermöglichen.

Auf Tipeee unterstützen

Vielen Dank für deinen Support!
– Stefan Draeger

Kostenlose Online-Werkzeuge

Tools

Praktische Generatoren, Rechner und Hilfsmittel für deine Elektronik- und Entwicklungsprojekte.

Generatoren & Konverter

  • QR-Code Generator
  • Passwort Generator
  • PNG zu WebP konvertieren
  • Bilder online komprimieren
  • Code online formatieren

Rechner & Tabellen

  • Unix-Zeitstempel-Rechner
  • ASCII-Tabelle
  • ASCII Code umrechnen – Text, Dezimal, Hex & Binär
  • Spannung, Strom, Widerstand und Leistung berechnen
  • Widerstandsrechner

LED-Matrix

  • 8×8 LED Matrix Tool
  • 8×16 LED Matrix Modul von Keyestudio
  • 16×16 LED Matrix Generator
Kontakt

Anschrift & Kontaktdaten

Stefan Draeger

Königsberger Str. 13
38364 Schöningen

Telefon 01556 5432686

E-Mail info@draeger-it.blog

Blogverzeichnis Bloggerei.de TopBlogs.de das Original - Blogverzeichnis | Blog Top Liste Blogverzeichnis trusted-blogs.com
Social Media

Folge mir auf

Weitere Projekte, Videos und Neuigkeiten findest du auch auf meinen Social-Media-Kanälen.

  • f Facebook
  • in LinkedIn
  • ▶ YouTube
  • ♪ TikTok
  • P Pinterest
  • ◎ Instagram
Rechtliche Informationen

Rechtliches

  • Impressum
  • Datenschutzerklärung
  • Disclaimer
  • Cookie-Richtlinie (EU)
  • KI-Transparenz bei draeger-it.blog
©2026 Technik Blog | Built using WordPress and Responsive Blogily theme by Superb
Cookie-Zustimmung verwalten
Wir verwenden Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wir tun dies, um das Surferlebnis zu verbessern und um personalisierte Werbung anzuzeigen. Wenn Sie diesen Technologien zustimmen, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn Sie Ihre Zustimmung nicht erteilen oder zurückziehen, können bestimmte Funktionen beeinträchtigt werden.
Funktional Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt. Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
  • Optionen verwalten
  • Dienste verwalten
  • Verwalten von {vendor_count}-Lieferanten
  • Lese mehr über diese Zwecke
Einstellungen anzeigen
  • {title}
  • {title}
  • {title}