Man hat eine Dev-Umgebung (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 Ein Key mit 3072 Bit Länge. 2048 Bit gehen natürlich auch und sparen Ressourcen, aber davon hat unser Devserver ja genug.
  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.**

Noch keine Kommentare

Die Kommentarfunktion wurde vom Besitzer dieses Blogs in diesem Eintrag deaktiviert.