Lokales HTTPS für die Entwicklung: eine private CA, Trust Stores und die localhost-Ausnahme

Ziel

Die Anwendung lokal über HTTPS mit einem Zertifikat ausliefern, das Browser und Kommandozeilenwerkzeuge akzeptieren, damit sich Secure-Cookies, Mixed-Content-Regeln und OAuth-Redirect-URIs wie in der Produktion verhalten – ohne Zertifikatswarnungen und ohne öffentliche Zertifikate für Namen, die einem nicht gehören.

Voraussetzungen

Wissen, wann es unnötig ist: Die Spezifikation zu Secure Contexts behandelt einen Origin als potenziell vertrauenswürdig, wenn sein Host eine Adresse in 127.0.0.0/8 oder ::1/128 ist, und – bei User Agents, die localhost-Namen wie von der Spezifikation gefordert auf Loopback auflösen – wenn er localhost lautet oder auf .localhost endet; schlichtes http://localhost erhält daher in solchen Browsern bereits die APIs für sichere Kontexte. Lokales HTTPS lohnt sich dort, wo TLS-spezifisches Verhalten getestet wird, ein Entwicklungshostname ausserhalb des Loopbacks verwendet wird oder mehrere Dienste unter einem Wildcard-Namen laufen. Let's Encrypt empfiehlt für localhost, ein eigenes Zertifikat zu erzeugen, selbstsigniert oder von einem lokalen Root signiert, und es im Trust Store des Betriebssystems als vertrauenswürdig einzustufen.

Schritte

1. Einmal pro Entwicklungsmaschine eine private CA erstellen. mkcert -install erzeugt eine lokale CA und installiert sie laut README im System-Trust-Store sowie, sofern vorhanden, im Firefox-Store. Den CA-Schlüssel niemals committen oder weitergeben; das README warnt, dass rootCA-key.pem die vollständige Macht gibt, sichere Anfragen von der eigenen Maschine abzufangen.
2. Leaf-Zertifikate nur für Entwicklungsnamen ausstellen, zum Beispiel mkcert app.localhost "*.dev.example.test" 127.0.0.1; niemals für Produktionshostnamen.
3. Den lokalen Server oder Reverse Proxy mit dem Zertifikat und dem Schlüssel konfigurieren; das README hält fest, dass mkcert Server nicht selbst konfiguriert. Die Dateien aus der Versionskontrolle und aus Container-Images heraushalten.
4. Nicht browserbasierte Clients dazu bringen, der CA zu vertrauen. Das README dokumentiert NODE_EXTRA_CA_CERTS für Node.js, das auf die Root-Datei im von mkcert -CAROOT ausgegebenen Ordner verweist; andere Laufzeitumgebungen lesen den System-Store oder benötigen eine eigene Variable. Die Variable pro Werkzeug im Setup-Skript festhalten.
5. Auf einer zweiten Maschine oder in einem Dev-Container Schritt 1 wiederholen; jede Maschine hat ihre eigene CA, sodass Leaf-Zertifikate neu erzeugt statt kopiert werden.
6. Eine Prüfung im Setup-Skript ergänzen: Eine Anfrage an den lokalen HTTPS-Endpoint muss erfolgreich sein, ohne die Verifikation zu deaktivieren.

Erwartetes Ergebnis

Der Browser zeigt für den Entwicklungs-Origin ein gültiges Zertifikat, Secure-Cookies funktionieren, und niemand gewöhnt sich an, Zertifikatswarnungen wegzuklicken.

Grenzen und Prüfbasis

Eine private CA im System-Store ist eine Sicherheitsentscheidung für diese Maschine; der Schlüssel sollte nur für die besitzende Person lesbar sein. Mobile Geräte benötigen einen separaten Import der Root-Datei, beschrieben im mkcert-README, das unter seinen Root-Stores auch Java (wenn JAVA_HOME gesetzt ist) und den von Firefox genutzten NSS-Store aufführt, auswählbar über TRUST_STORES. Das Vorgehen wurde aus den zitierten Dokumenten zusammengestellt; es werden keine Messwerte behauptet.