Zertifikate

Node64 verwaltet alle TLS-Zertifikate an einer Stelle: Let's Encrypt per DNS- oder HTTP-Challenge, 26 DNS-Anbieter plus ipv64, eine eigene CA fürs Heimnetz, hochgeladene und selbst signierte Zertifikate. PROXY64, DNS64 und die Oberfläche nutzen sie – und du kannst sie an NAS, Proxmox, Windows und andere Geräte verteilen.

Überblick

• Die Zertifikatsverwaltung gehört zum Kern von Node64 (Menüpunkt Zertifikate). Sie läuft unabhängig davon, welche Module an sind.
• Erneuert wird automatisch, auch wenn gerade kein Modul das Zertifikat nutzt – und auch, wenn PROXY64 aus ist.
• Die Spalte „benutzt von“ zeigt, wer ein Zertifikat verwendet, und schützt so vor versehentlichem Löschen.
• Schlüssel und Zugangsdaten liegen verschlüsselt in der Datenbank der Node.

Wege zum Zertifikat

Wählst du beim Anfordern „Automatisch“, nimmt Node64 ipv64 DNS-01, wenn alle Namen in deinem ipv64-Account liegen, sonst HTTP-01.

ipv64 DNS-01

Der bequemste Weg für alle Namen in deinem ipv64.net-Account, etwa deine DynDNS-Domains. Node64 setzt den nötigen TXT-Eintrag selbst über die ipv64-API.

• Voraussetzung: der ipv64-API-Key unter Einstellungen → ipv64 (siehe ipv64.net verknüpfen).
• Wildcards wie *.deinname.ipv64.net gehen.
• Es muss kein Port offen sein, der Name muss im Internet nicht einmal erreichbar sein. Praktisch auch für Dienste, die nur im Heimnetz laufen.

Alias über ipv64

Für Domains bei einem anderen Anbieter, dessen Zugangsdaten du Node64 nicht geben willst. Du legst beim Anbieter einmal einen CNAME an, der die Prüfung an ipv64 weiterreicht:

_acme-challenge.cloud.example.com.  CNAME  _acme-challenge.<präfix>.<deine-ipv64-domain>.

Die genauen Werte zeigt dir Node64 beim Anlegen. Danach läuft jede Erneuerung ohne weiteres Zutun über ipv64.

Anderer DNS-Anbieter (26)

Für Domains bei einem dieser Anbieter hinterlegst du einen DNS-Zugang mit den Feldern des Anbieters (Token, Key …). Er wird verschlüsselt gespeichert. Wildcards gehen auch hier. Die Anbindung baut auf lego v4.35.2 auf.

ipv64 selbst kommt als eigener Weg dazu (ipv64 DNS-01).

HTTP-01

Let's Encrypt ruft eine Prüfdatei über Port 80 ab. Das läuft über den gemeinsamen Eingang von Node64. Voraussetzungen: Port 80 ist im Router auf die Node weitergeleitet, und der Name zeigt per DNS auf deinen Anschluss. Wildcards gehen mit HTTP-01 nicht.

Eigenes Zertifikat hochladen

Gekaufte Zertifikate kommen oft mit einem Schlüssel, der durch ein Passwort geschützt ist. Node64 versteht diese Formate:

• Ist das Passwort falsch oder fehlt es, sagt die Seite das ausdrücklich.
• Gespeichert wird der entschlüsselte Schlüssel – verschlüsselt mit dem Schlüssel der Node. Das Passwort selbst wird nicht gespeichert und steht nicht im Audit.
• Hochgeladene Zertifikate lassen sich nicht automatisch erneuern. Node64 warnt dich vor dem Ablauf.

Eigene CA fürs Heimnetz

Für Geräte, die kein öffentliches Zertifikat bekommen können – nas.lan, drucker.home.arpa oder eine private IP. Deine Geräte vertrauen der CA einmal, danach sind alle ihre Zertifikate gültig.

• Erzeugen: ECDSA P-256 oder RSA 3072, 10 Jahre gültig. Standard ist „nur private Namen und Adressen“ (u. a. *.lan, *.home.arpa, *.internal, *.local, *.home sowie private IPv4/IPv6). Auf Wunsch erlaubst du zusätzlich eigene Domains. Weil die CA per Name Constraints eingeschränkt ist, ließen sich mit einem gestohlenen CA-Schlüssel keine Internet-Domains fälschen.
• Importieren: Eine vorhandene CA mit Schlüssel als PEM, auch eine Zwischen-CA unter einer Offline-Root (z. B. aus step-ca, OpenSSL oder XCA).
• Ausstellen: Im Formular „Zertifikat hinzufügen“ den Weg „Eigene CA“ wählen, Namen und IPs je Zeile eintragen. Laufzeit 1–825 Tage, Standard 397 (825 ist die Grenze von Apple).
• Erneuern: automatisch im letzten Drittel der Laufzeit, höchstens 30 Tage vor Ablauf.

So installierst du die CA auf deinen Geräten (Karte Eigene CAs):

Eine CA lässt sich erst löschen, wenn sie kein Zertifikat mehr ausstellt.

Selbst signiert

Sofort und ohne Voraussetzung, auch für IPs. ECDSA P-256 (Standard) oder RSA 2048, Laufzeit standardmäßig 397 Tage. Browser warnen, bis du dem Zertifikat vertraust – und nach jeder Erneuerung erneut. Für mehrere Geräte ist eine eigene CA bequemer.

Weitere ACME-Stellen

Standard ist Let's Encrypt, wahlweise auch dessen Testumgebung (Staging) – ideal, um nicht in die Rate-Limits zu laufen. Unter ACME-Stellen kannst du weitere Stellen hinzufügen, die ACME sprechen. Vorlagen gibt es für:

• Beim Hinzufügen fragt Node64 das Verzeichnis ab und meldet, wenn die Stelle EAB verlangt. Die Nutzungsbedingungen der Stelle nimmst du dabei an.
• Der EAB-Schlüssel liegt verschlüsselt in der Datenbank.
• Beim Anfordern wählst du die Stelle unter „Ausstellende Stelle“. Alle Wege (ipv64, Alias, DNS-Anbieter, HTTP-01) gelten für jede Stelle.

Verlängerung und Meldungen

• Zertifikate mit „automatisch“ erneuert Node64 30 Tage vor Ablauf.
• Schlägt eine Erneuerung fehl, gibt es den nächsten Versuch nach 6 Stunden.
• Zertifikate der eigenen CA werden im letzten Drittel ihrer Laufzeit erneuert, höchstens 30 Tage vor Ablauf.
• Meldungen an deine Standardkanäle: bei einem Fehlschlag (einmal je Störung), bei Entwarnung und 14 bzw. 3 Tage vor Ablauf.
• Ohne Zertifikate und ohne Abnehmer läuft im Hintergrund nichts.

Wer die Zertifikate nutzt

Seit DNS64 1.11.0 holt DNS64 selbst keine Zertifikate mehr, das macht die Zentrale. Beim Update ziehen ältere Zertifikate und die Heimnetz-CA von DNS64 einmal automatisch um – mit gleichem Schlüssel, deine Geräte merken nichts.

Zertifikat der Oberfläche

Unter Einstellungen → Allgemein → Erreichbarkeit dieser Node → Zertifikat der Oberfläche legst du fest, womit sich die Oberfläche ausweist. Das gilt für den HTTPS-Port (NODE64_HTTPS_PORT) und den Namen am Eingang. Ein Wechsel greift sofort, ohne Neustart.

Ist NODE64_TLS_CERT gesetzt, nutzt der HTTPS-Port weiter diese Datei (siehe Konfiguration).

Herunterladen

Das Download-Menü steht in jeder Zeile der Liste.

Jeder Download mit Schlüssel steht im Audit – mit Format, Name und ob er über die Seite oder die API kam.

Abruf per API

Mit einem normalen API-Key (Einstellungen → API-Keys, siehe Lokale API) holen sich andere Geräte ihr Zertifikat selbst ab.

In den Beispielen steht http://node64.lan:8080 für die Adresse deiner Node, DEIN_API_KEY für den API-Key und 3 für die Kennung des Zertifikats aus GET /api/certs.

# Liste der Zertifikate mit Kennung
curl -H "Authorization: Bearer DEIN_API_KEY" http://node64.lan:8080/api/certs

# Ablauf und Fingerabdruck (ETag) eines Zertifikats
curl -H "Authorization: Bearer DEIN_API_KEY" http://node64.lan:8080/api/certs/3/meta

# fullchain.pem laden und die Antwort-Kopfzeilen (mit ETag) sichern
curl -D headers.txt -o fullchain.pem -H "Authorization: Bearer DEIN_API_KEY" \
  "http://node64.lan:8080/api/certs/3/bundle?format=fullchain"

# Nur bei Änderung laden: 304 = nichts Neues, 200 = neue Datei
ETAG=$(grep -i '^etag:' headers.txt | cut -d' ' -f2 | tr -d '\r')
curl -s -o fullchain.pem -w '%{http_code}\n' -H "Authorization: Bearer DEIN_API_KEY" \
  -H "If-None-Match: $ETAG" "http://node64.lan:8080/api/certs/3/bundle?format=fullchain"

# PKCS#12 mit Passwort
curl -X POST -o cert.p12 -H "Authorization: Bearer DEIN_API_KEY" -H "Content-Type: application/json" \
  -d '{"password":"DEIN_P12_PASSWORT","legacy":false}' http://node64.lan:8080/api/certs/3/p12

Beispiel-Skripte

Linux mit nginx – täglich per Cron

Das Skript holt das Zertifikat nur, wenn es sich geändert hat, und lädt nginx danach neu. Speichere es z. B. als /etc/cron.daily/node64-cert und mach es ausführbar (chmod +x).

#!/bin/sh
# Holt das Zertifikat nur bei Änderung und lädt nginx neu
NODE=http://node64.lan:8080   # Node64 im eigenen Netz
KEY=DEIN_API_KEY              # API-Key
ID=3                          # Kennung aus GET /api/certs
DIR=/etc/ssl/node64
mkdir -p "$DIR" && cd "$DIR" || exit 1
ETAG=$(cat etag 2>/dev/null)
CODE=$(curl -s -o new.zip -D headers -w '%{http_code}' -H "Authorization: Bearer $KEY" \
  -H "If-None-Match: $ETAG" "$NODE/api/certs/$ID/bundle?format=zip")
if [ "$CODE" = 200 ]; then
  unzip -o -q new.zip && chmod 600 privkey.pem
  grep -i '^etag:' headers | cut -d' ' -f2 | tr -d '\r' > etag
  systemctl reload nginx
fi
rm -f new.zip headers

In der nginx-Konfiguration zeigst du dann auf /etc/ssl/node64/fullchain.pem und /etc/ssl/node64/privkey.pem.

Proxmox VE

Wie oben, nur statt systemctl reload nginx:

pvenode cert set fullchain.pem privkey.pem --force --restart

Synology DSM

Lade das ZIP herunter und importiere unter Systemsteuerung → Sicherheit → Zertifikat → Hinzufügen → Importieren die Dateien privkey.pem, cert.pem und chain.pem.

Windows (PowerShell als Administrator)

$h = @{ Authorization = "Bearer DEIN_API_KEY" }
Invoke-RestMethod -Method Post -Uri "http://node64.lan:8080/api/certs/3/p12" -Headers $h `
  -ContentType "application/json" -Body '{"password":"DEIN_P12_PASSWORT"}' -OutFile cert.p12
Import-PfxCertificate -FilePath cert.p12 -CertStoreLocation Cert:\LocalMachine\My `
  -Password (ConvertTo-SecureString "DEIN_P12_PASSWORT" -AsPlainText -Force)

Sicherung und Umzug

• Zertifikate, Schlüssel, CAs, DNS-Zugänge und EAB-Daten liegen in node64.db. Die Schlüssel sind dort mit /data/secret.key verschlüsselt.
• Beide Dateien gehören zusammen. Ohne secret.key lassen sich die Schlüssel nicht mehr lesen. Das vollständige Backup der Node enthält beides, siehe Update & Backup.
• Neuer Rechner: Zieh das ganze Volume /data um. Die Zertifikate gelten dort sofort weiter.

Grenzen

• Rate-Limits von Let's Encrypt gelten wie üblich, z. B. 50 Zertifikate je registrierter Domain und Woche und 5 gleiche Zertifikate je Woche. Zum Ausprobieren nimmst du die Testumgebung (Staging).
• IP-Adressen im Zertifikat gibt es nur mit der eigenen CA oder selbst signiert, nicht über ACME.
• Keine Sperrlisten (CRL/OCSP) für die eigene CA. Ein kompromittiertes Zertifikat löschst du und stellst es neu aus. Bei Verdacht auf die CA selbst legst du eine neue CA an und tauschst sie auf den Geräten.

DNS-01-Prüfung

Bevor Node64 bei DNS-01 die Zertifizierungsstelle prüfen lässt, schaut es selbst nach, ob der TXT-Eintrag schon sichtbar ist. Diese Prüfung hängt an keinem einzelnen Resolver:

• Direkt bei den Nameservern der Domain, bei Bedarf per TCP, falls UDP 53 umgeleitet oder gesperrt ist.
• Öffentlich, alle gleichzeitig: DoH über feste IPs bei Cloudflare, Quad9, Google, DNS4EU, dnsforge, AdGuard und Mullvad, dazu Port 53 bei 1.1.1.1, 9.9.9.9, 8.8.8.8 und 2606:4700:4700::1111. Sperrt ein DNS-Filter in deinem Netz einzelne davon (etwa cloudflare-dns.com), stört das nicht mehr.
• Liefert dein eigener Resolver bei der Suche nach den Nameservern 0.0.0.0 oder antwortet er nicht, weicht Node64 auf die öffentlichen Resolver aus.
• Die Fehlermeldung unterscheidet, ob der Eintrag noch nicht sichtbar ist („record not visible“) oder ob gar kein öffentlicher Resolver erreichbar war („no public resolver reachable either …“), und nennt den Stand je Nameserver.

Unter Zertifikate führt ein Link im Konto-Kasten zur Seite DNS-01-Prüfung (/certificates/dns-check). Jetzt testen prüft dort jeden Weg einzeln – die ipv64-Nameserver direkt und jeden öffentlichen Resolver. Außerdem trägst du dort eigene Resolver ein, die zuerst gefragt werden: IP, IP:Port, https://, tls:// oder quic://, höchstens 10.

Fehlerbehebung

Fehlertexte von DNS-Anbietern zeigt Node64 geschwärzt: Tokens und Schlüssel erscheinen weder in der Oberfläche noch in API, Log oder Cluster-Abgleich im Klartext.

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.