HTTPS mit eigener CA

HTTPS verschlüsselt die Kommunikation zwischen Browser und Server und stellt sicher, dass niemand mitlesen oder Inhalte manipulieren kann. Im öffentlichen Internet übernehmen das Zertifikate vertrauenswürdiger Zertifizierungsstellen (CAs) wie Let’s Encrypt. Im lokalen Netzwerk – etwa für ein FHEM-Web-Interface, eine Nextcloud-Instanz oder ein Router-Backend – funktioniert dieser Weg jedoch nicht, weil interne Hostnamen und IP-Adressen von öffentlichen CAs nicht signiert werden. Hier ist eine eigene, private Zertifizierungsstelle die Lösung. Diese Anleitung baut sie mit OpenSSL vollständig auf.

Wie OpenSSL arbeitet

OpenSSL ist die Standard-Werkzeugsammlung für Verschlüsselung und Zertifikate unter Linux. Ihr Kern ist die asymmetrische Kryptografie: Zu jedem Zertifikat gehört ein Schlüsselpaar aus einem privaten und einem öffentlichen Schlüssel. Was mit dem einen verschlüsselt wird, lässt sich nur mit dem anderen entschlüsseln. Der private Schlüssel bleibt streng geheim auf dem Server, der öffentliche steckt im Zertifikat und darf frei verteilt werden.

Ein Zertifikat ist im Grunde der öffentliche Schlüssel plus Angaben zum Inhaber (Hostname, Gültigkeit), versehen mit einer digitalen Signatur der ausstellenden CA. Der Browser prüft diese Signatur: Stammt sie von einer CA, der er vertraut, gilt das Zertifikat als echt. So entsteht eine Vertrauenskette vom Server-Zertifikat über die CA bis zum Vertrauensanker im Betriebssystem.

Sicher ist das aus drei Gründen: Erstens beruht die Verschlüsselung auf mathematischen Problemen (Primfaktorzerlegung bei RSA), die mit ausreichender Schlüssellänge praktisch nicht zu brechen sind – deshalb wird hier durchgehend 4096 Bit verwendet. Zweitens verlässt der private Schlüssel niemals den Server. Drittens kann die Signatur nicht gefälscht werden, ohne den privaten Schlüssel der CA zu besitzen. Als Prüfsumme dient dabei SHA-256, ein kollisionssicheres Hash-Verfahren.

Das Konzept der privaten CA

Eine private CA ist eine selbst betriebene Zertifizierungsstelle, der ausschließlich die eigenen Geräte vertrauen. Das Prinzip besteht aus drei Bausteinen:

1. Wurzelzertifikat (Root-CA): Ein einmalig erzeugtes Schlüsselpaar mit sehr langer Laufzeit, das die Vertrauensbasis bildet. Sein privater Schlüssel wird streng geheim gehalten.
2. Server-Zertifikate: Für jeden Dienst wird ein eigenes Zertifikat erzeugt und mit der Root-CA signiert. Es enthält die Hostnamen und IP-Adressen des Dienstes (Subject Alternative Names).
3. Vertrauensanker: Nur das öffentliche Root-Zertifikat wird auf den eigenen Geräten als vertrauenswürdig hinterlegt. Damit gelten automatisch alle damit signierten Server-Zertifikate als gültig – ohne Browser-Warnung.

Zentrale Konfiguration (openssl.cnf)

Statt bei jedem Befehl unzählige Parameter anzugeben, werden alle Vorgaben einmalig in einer openssl.cnf hinterlegt. Genau hier werden die gewünschten Standards festgeschrieben: automatisch 4096 Bit, Prüfsumme SHA-256 und eine Standardlaufzeit von 730 Tagen (2 Jahre) für alle Server-Zertifikate. Die CA selbst erhält ihre lange Laufzeit beim Erzeugen separat.

Zuerst die Arbeitsverzeichnisse und die Verwaltungsdateien der CA anlegen:

mkdir -p ca/newcerts
touch ca/index.txt
echo 1000 > ca/serial

Dann die Datei openssl.cnf erstellen:

[ req ]
default_bits        = 4096
default_md          = sha256
prompt              = no
distinguished_name  = req_dn
x509_extensions     = v3_ca

[ req_dn ]
C  = DE
O  = Heimnetz
CN = Heimnetz Root CA

# Eigenschaften der Root-CA
[ v3_ca ]
basicConstraints     = critical, CA:TRUE
keyUsage             = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash

# Signier-Regeln der CA
[ ca ]
default_ca = CA_default

[ CA_default ]
dir             = ./ca
database        = $dir/index.txt
serial          = $dir/serial
new_certs_dir   = $dir/newcerts
certificate     = $dir/ca.crt
private_key     = $dir/ca.key
default_md      = sha256
default_days    = 730          # Server-Zertifikate: 2 Jahre
policy          = policy_any
copy_extensions = copy         # SAN aus dem CSR uebernehmen

[ policy_any ]
countryName         = optional
organizationName    = optional
commonName          = supplied

# Eigenschaften der Server-Zertifikate
[ v3_server ]
basicConstraints = CA:FALSE
keyUsage         = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName   = @alt_names

[ alt_names ]
DNS.1 = fhem.lan
IP.1  = 192.168.1.100

Die wichtigsten Stellen: default_bits = 4096 erzwingt automatisch starke Schlüssel, default_days = 730 setzt die 2-Jahres-Laufzeit für jedes signierte Server-Zertifikat, und copy_extensions = copy übernimmt die Subject Alternative Names aus der Anforderung – ohne sie verweigern moderne Browser das Zertifikat.

1. Root-CA erzeugen (10 Jahre)

Zuerst der private CA-Schlüssel. Er ist das Kronjuwel der gesamten Vertrauenskette und sollte mit einer Passphrase geschützt werden (dafür sorgt -aes256):

openssl genrsa -aes256 -out ca/ca.key 4096

Darauf das selbstsignierte Wurzelzertifikat. Die CA bekommt hier ihre lange Laufzeit von 3650 Tagen (10 Jahre):

openssl req -x509 -new -key ca/ca.key -sha256 -days 3650 -config openssl.cnf -extensions v3_ca -out ca/ca.crt

2. Server-Schlüssel und Anforderung (CSR) erzeugen

Für den abzusichernden Dienst werden ein eigener Schlüssel und eine Zertifikatsanforderung (CSR) erstellt. Der Server-Schlüssel bleibt ohne Passphrase (-nodes), damit der Dienst nach einem Neustart unbeaufsichtigt starten kann. Die 4096 Bit kommen automatisch aus der Konfiguration:

openssl req -new -nodes -keyout server.key -out server.csr -config openssl.cnf -subj "/CN=fhem.lan"

Die Hostnamen und IP-Adressen werden über den Abschnitt [ alt_names ] in der openssl.cnf gepflegt – dort wird für jeden Dienst eingetragen, unter welchen Namen er erreichbar ist.

3. Mit der eigenen CA signieren (automatisch 2 Jahre)

Jetzt signiert die CA die Anforderung. Da die Laufzeit bereits in der Konfiguration steht, entsteht das Server-Zertifikat ganz ohne weitere Angabe mit exakt 2 Jahren Gültigkeit:

openssl ca -config openssl.cnf -extensions v3_server -in server.csr -out server.crt

Das Ergebnis ist server.crt – ein gültiges, von der eigenen CA signiertes Zertifikat. Mit folgendem Befehl lassen sich Laufzeit und Inhalt jederzeit kontrollieren:

openssl x509 -in server.crt -noout -dates -ext subjectAltName

4. CA lokal als vertrauenswürdig einstufen

Damit Browser und System dem Zertifikat vertrauen, wird ausschließlich das öffentliche Wurzelzertifikat (ca.crt) – niemals der private CA-Schlüssel – auf den eigenen Geräten als vertrauenswürdig importiert.

Auf einem Debian-basierten Linux-System:

sudo cp ca/ca.crt /usr/local/share/ca-certificates/heimnetz-ca.crt
sudo update-ca-certificates

Firefox verwendet einen eigenen Zertifikatsspeicher: Unter Einstellungen → Datenschutz & Sicherheit → Zertifikate anzeigen → Zertifizierungsstellen → Importieren wird die ca.crt hinterlegt und als vertrauenswürdig für Websites markiert. Unter Windows wird die Datei per Doppelklick in den Speicher Vertrauenswürdige Stammzertifizierungsstellen importiert. Wichtig: Vertrauen entsteht nur auf den Geräten, auf denen die CA bewusst eingerichtet wurde – nirgendwo sonst.

5. HTTPS im Dienst aktivieren

Abschließend werden Server-Zertifikat und -Schlüssel im jeweiligen Dienst hinterlegt. In FHEM werden die Dateien als certs/server-cert.pem und certs/server-key.pem abgelegt und HTTPS aktiviert:

cp server.crt /opt/fhem/certs/server-cert.pem
cp server.key /opt/fhem/certs/server-key.pem

attr WEB HTTPS 1

Bei einer Nextcloud oder einem anderen Apache-Dienst werden stattdessen die Direktiven SSLCertificateFile (das Server-Zertifikat) und SSLCertificateKeyFile (der Schlüssel) im VirtualHost gesetzt.

Gültigkeit im Blick behalten

Da Zertifikate ablaufen, muss vor Ablauf ein neues erzeugt werden – einfach Schritt 2 und 3 wiederholen. Damit kein Termin übersehen wird, überwacht die Hausautomatisierung die Restlaufzeiten automatisch und warnt rechtzeitig per Messenger: siehe Absicherung & Backups.

Vorteile dieses Ansatzes

• Vollständig verschlüsselte Verbindungen auch im lokalen Netz – ohne Internet-Abhängigkeit.
• Keine Browser-Warnungen, da der eigenen CA gezielt vertraut wird.
• Volle Kontrolle über Laufzeiten (2 Jahre für Dienste, 10 Jahre für die CA), Schlüssellänge und Hostnamen.
• Eine zentrale Vertrauensstelle für beliebig viele interne Dienste.