Kurzanleitung: Ein selbstsigniertes Zertifikat für die Dev-Umgebung

Update 04.05.2022: Inzwischen mache ich meine Entwicklung nicht mehr in einer Linux-VM, sondern direkt unter Windows mit der Symfony-CLI, die einen lokalen Webserver inkl. Proxy für verschiedene PHP-Versionen mitbringt. Der beherrscht das Kunststück, sich in lokalen Browsern auch um die Zertifikate für den HTTPS-Zugriff zu kümmern und einfach so zu funktionieren. Das vereinfacht die Einrichtung und den Betrieb einer lokalen Entwicklungsumgebung immens, ganz besonders unter Windows, weil man sich Gehampel mit Linux-VMs oder dem WSL oder gar einem Windows-Apache komplett sparen kann. Damit arbeite ich nun schon seit einer ganzen Weile und es hat die Komplexität meiner Entwicklungsumgebung sehr reduziert, was immer wünschenswert ist.

Nun zum ursprünglichen Artikel:

Man hat eine Dev-Umgebung für PHP (in einer VM oder wo auch immer), aber man hat das Projekt so konfiguriert, dass es nur über HTTPS funktioniert? Dann muss ein Zertifikat her, sonst heult Chrome rum, der nimmt nämlich keine dauerhaften Ausnahmen an. Da ich nun schon zum hundertsten Mal ein Zertifikat für ein neues Testprojekt erstelle, habe ich das mal niedergeschrieben, inkl. lustiger Stolpersteine, über die ich jedes Mal stolpere. Und damit ich das nicht jedes Mal wieder machen muss, direkt ein Wildcard-Zertifikat.

Die Kurzform als Erinnerung für mich:

1. Eine Konfigurationsdatei erstellen, siehe diese Stackoverflow-Antwort. Die brauchen wir, weil openssl die Alternative Names nicht über die Kommandozeile annimmt. Wichtig ist, dass die Wildcard-Domain in der Konfigurationsdatei bei den Alternative Names gelistet ist, der Common Name kann dann irgendwie gefüllt werden. In der Datei kann man auch schon die Fragen beantworten, die openssh beim Generieren stellen wird.
2. openssl req -config wildcard.dev.lan.conf -new -x509 -sha256 -newkey rsa:3072 -nodes -keyout wildcard.dev.lan.key -days 3650 -out wildcard.dev.lan.crt.
3. Alle möglichen Daten für das Zertifikat eingeben oder einfach nur bestätigen, wenn man das schon in der Konfigurationsdatei gemacht hat.

4. Key und Crt dem Webserver beibringen. Bei Apache in der Kurzform etwa so:

   <VirtualHost *:443>
       ServerName myproject.dev.lan
       DocumentRoot "/path/to/myproject/web"
       <Directory "/path/to/myproject/web">
           Require all granted
           AllowOverride All
       </Directory>
       SSLEngine On
       SSLCertificateFile /path/to/wildcard.dev.lan.crt
       SSLCertificateKeyFile /path/to/wildcard.dev.lan.key
   </VirtualHost>
   

5. Firefox kann Ausnahmen einfach akzeptieren, Chrome will es komplizierter: Zertifikat im Security-Tab der Dev-Tools ansehen, In eine p7b-Datei exportieren und im Zertifikatsmanager in die "Vertrauenswürdigen Stammzertifizierungsstellen" importieren. Chrome neu starten und voilà, das Schloss ist grün.

Jetzt können wir ganz viele Unterprojekte von dev.lan aufsetzen und für alle das gleiche Zertifikat einsetzen. Kein Gefummel mehr, einfach Config kopieren, Name und Pfade anpassen, ab geht die Post. Zum Beispiel die Symfony-Demo-Applikation, die sollte man sich sowieso mal ansehen.

Wichtige Stolpersteine:

1. SHA1-Zertifikate sind aus gutem Grund out, also einfach nie mehr welche erzeugen.
2. Zumindest der aktuelle Chrome mag für Wildcard-Zertifikate mindestens zwei Dots. Also *.lan funktioniert einfach nicht. Habe ich ausprobiert, bleibt ohne weiteren Kommentar einfach rot. Daher *.dev.lan oder irgendwas anderes mit mindestens zwei Dots benutzen.

Nachtrag 29.08.2018: .local ist eine sehr schlechte Wahl für sowas und macht lustige Probleme, weil .local für Zeroconf-Adressen reserviert ist. Nehmt also etwas anderes, etwa .lan, das ist für den Einsatz in rein lokalen Umgebungen vorgesehen. Ich habe die Beispiele entsprechend geändert.

Und noch ein kleiner Hinweis am Rande: Ubuntu 18.04 und vermutlich auch spätere Versionen machen große Probleme mit dnsmasq, das man für die Auflösung von Wildcard-Domains benutzt. Ich habe einige Stunden recherchiert und herumprobiert und letztlich war es ganz einfach, siehe diese Antwort bei Ask Ubuntu, viele andere Anleitungen haben das nicht hinbekommen. Jetzt löst auf dem Ubuntu-System myproject.dev.lan schön nach 127.0.0.1 auf, ohne dass ich für jedes Projekt an hosts-Dateien herumfummeln muss.

Nachtrag 30.08.2018: Chrome will die DNS-Namen nicht mehr im CN-Feld, sondern als Alternative Names, sonst bleibt die Warnung stehen. Um so ein Zertifikat zu erzeugen, muss man sich eine Konfigurationsdatei basteln und die beim Erzeugen von Schlüssel und Zertifikat benutzen. Ich habe die Anleitung entsprechend aktualisiert.**