HTTPS für Localhost: SSL-Zertifikate für die lokale Entwicklung

Moderne Web-APIs (Service Workers, Geolocation, Zwischenablage, Kamera) erfordern HTTPS — auch während der Entwicklung. Dieser Leitfaden zeigt, wie Sie vertrauenswürdiges HTTPS auf localhost ohne Browser-Warnungen erhalten.

Warum Sie Let’s Encrypt nicht für localhost verwenden können

Let’s Encrypt validiert den Domainbesitz durch Überprüfung einer Datei auf Ihrem Server oder eines DNS-Eintrags. localhost ist keine echte Domain — sie löst nur auf Ihrem Computer auf 127.0.0.1 auf. Niemand kann verifizieren, dass Sie localhost „besitzen”, daher wird keine öffentliche CA ein Zertifikat dafür ausstellen.

Ihre Optionen für localhost HTTPS:

1. mkcert — erstellt lokal vertrauenswürdige Zertifikate (empfohlen)
2. Selbstsigniertes Zertifikat — funktioniert, zeigt aber Browser-Warnungen
3. Tunneling-Dienst — ngrok, Cloudflare Tunnel (echte Domain, echtes Zertifikat)

Option 1: mkcert (empfohlen)

mkcert erstellt eine lokale Zertifizierungsstelle auf Ihrem Rechner, fügt sie zu Ihrem System-Vertrauensspeicher hinzu und stellt von dieser CA signierte Zertifikate aus. Browser vertrauen diesen Zertifikaten ohne Warnungen.

mkcert installieren

# macOS
brew install mkcert

# Linux (erfordert libnss3-tools für Firefox)
sudo apt install libnss3-tools
brew install mkcert  # oder von GitHub-Releases herunterladen

# Windows
choco install mkcert
# oder: scoop install mkcert

Lokale CA einrichten

mkcert -install
# Ausgabe: Created a new local CA
# Die lokale CA ist jetzt im System-Vertrauensspeicher installiert

Dies fügt ein Stammzertifikat zu Ihren System- und Browser-Vertrauensspeichern hinzu. Machen Sie dies einmal — es funktioniert für alle zukünftigen Zertifikate.

Zertifikate generieren

# Für localhost
mkcert localhost 127.0.0.1 ::1

# Für eine benutzerdefinierte lokale Domain
mkcert myapp.test "*.myapp.test" localhost 127.0.0.1

# Ausgabe:
# Created a new certificate valid for the following names:
#  - "localhost"
#  - "127.0.0.1"
#  - "::1"
# The certificate is at "./localhost+2.pem" and the key at "./localhost+2-key.pem"

Mit Ihrem Entwicklungsserver verwenden

Node.js/Express:

const https = require('https');
const fs = require('fs');
const app = require('./app');

https.createServer({
  key: fs.readFileSync('./localhost+2-key.pem'),
  cert: fs.readFileSync('./localhost+2.pem'),
}, app).listen(3000);

Nginx (lokal):

server {
    listen 443 ssl;
    server_name localhost;
    ssl_certificate     /path/to/localhost+2.pem;
    ssl_certificate_key /path/to/localhost+2-key.pem;
    # ...
}

Vite / webpack dev server:

// vite.config.js
import fs from 'fs';
export default {
  server: {
    https: {
      key: fs.readFileSync('./localhost+2-key.pem'),
      cert: fs.readFileSync('./localhost+2.pem'),
    },
  },
};

Sicherheitswarnung

Teilen Sie niemals den mkcert Root-CA-Schlüssel (rootCA-key.pem in mkcert -CAROOT). Jeder, der ihn hat, kann vertrauenswürdige Zertifikate für jede Domain auf Ihrem Rechner erstellen — im Wesentlichen eine lokale Man-in-the-Middle-Fähigkeit.

mkcert ist nur für die Entwicklung gedacht. Für die Produktion verwenden Sie Let’s Encrypt.

Option 2: Selbstsigniertes Zertifikat

Wenn Sie mkcert nicht installieren können, generieren Sie ein selbstsigniertes Zertifikat mit OpenSSL:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 \
  -keyout localhost-key.pem -out localhost-cert.pem \
  -days 365 -nodes -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Nachteil: Browser zeigen eine Sicherheitswarnung an, da selbstsignierte Zertifikate von keiner CA vertraut werden. Sie müssen sich jedes Mal durch die Warnung klicken (oder eine Ausnahme hinzufügen).

Option 3: Tunneling (echte Domain + echtes Zertifikat)

Verwenden Sie einen Tunneling-Dienst, um Ihren lokalen Server mit einer echten Domain und einem echten Zertifikat bereitzustellen:

# ngrok
ngrok http 3000
# Gibt Ihnen: https://abc123.ngrok.io

# Cloudflare Tunnel
cloudflared tunnel --url http://localhost:3000
# Gibt Ihnen: https://random-name.trycloudflare.com

Wann dies sinnvoll ist: Testen von Webhooks, Teilen mit einem Teamkollegen, Testen von OAuth-Callbacks, die HTTPS erfordern.

mkcert vs. selbstsigniert vs. Tunneling

Häufig gestellte Fragen

Kann ich dasselbe mkcert-Zertifikat im Team verwenden?

Teilen Sie nicht den Root-CA-Schlüssel. Jeder Entwickler sollte mkcert -install auf seinem eigenen Rechner ausführen, um seine eigene lokale CA zu erstellen. Sie können die generierten Zertifikate (die .pem-Dateien) teilen, aber jede Person muss die CA installiert haben, um ihnen zu vertrauen.

Funktioniert mkcert mit Docker?

Ja. Mounten Sie die Zertifikatsdateien in den Container und referenzieren Sie sie in der Serverkonfiguration. Der Container selbst benötigt keine mkcert-Installation — nur die .pem-Dateien. Ihr Hostrechner (auf dem der Browser läuft) benötigt die installierte mkcert-CA.

Welche lokale Domain sollte ich verwenden?

Verwenden Sie .test (z. B. myapp.test) — sie ist von der IETF für Tests reserviert und wird niemals mit einer echten Domain in Konflikt geraten. Vermeiden Sie .dev (gehört Google) und .local (wird von mDNS verwendet). Fügen Sie einen Eintrag in /etc/hosts hinzu, um Ihre .test-Domain auf 127.0.0.1 zu verweisen.

Wie wechsle ich von localhost-HTTPS zu Produktions-HTTPS?

Sie sind vollständig getrennt. Ihr localhost-Zertifikat (mkcert/selbstsigniert) bleibt auf Ihrem Entwicklungsrechner. Für die Produktion besorgen Sie ein echtes Zertifikat von Let’s Encrypt via GetHTTPS. Ihr Code sollte Zertifikatspfade aus Umgebungsvariablen lesen, sodass der Wechsel nur eine Konfigurationsänderung ist.