Wie zuletzt beschrieben, funktioniert das lokale SSL nun grundsätzlich. Aber im Browser bekommt man beim Aufruf von https://gruniversal.mars trotzdem ne Warnung angezeigt, dass die Konfiguration nicht korrekt ist (oder ein böser Mensch sich zu schaffen macht):
Die kann man zwar wegklicken, aber am Ende wünscht man sich doch einen “sauberen” Weg, der ohne Fehlermeldungen auskommt. Was kann man da machen? Und was genau bedeutet der Fehler eigentlich?
Im Jahre 2020 sollte Verschlüsselung Standard für die Übertragung von Daten mit Webservern sein. Spätestens seitdem Browser mit dezenten “Not Secure”-Hinweisen auf die Gefahren unverschlüsselter Datenübertragung hinweisen, bietet es sich an konsequent auf SSL (korrekter eigentlich TLS) zu setzen.
Daher macht es Sinn auch die lokale Umgebung SSL-fähig zu machen um gleich während der Entwicklung festzustellen, ob es Lücken in der Verschlüsselung gibt oder ob die Anwendung überhaupt mit SSL sauber funktioniert.
Kernstück der Verschlüsselung sind Zertifikate, die den Webserver identifizieren und den Datenstrom nach außen unleserlich machen. Aber woher bekommt man ein solches Zertifikat für den lokalen Einsatz?
(Hinweis: Um meine lokale Konfiguration und mein Vorhaben besser zu verstehen, ist es sinnvoll vorher Teil 1 und Teil 2 dieser kleinen Artikelserie zu lesen.)
Im letzten Schritt hatte ich erfolgreich die lokale Domain gruniversal.mars für meine lokalen Entwicklungen eingerichtet. Nun möchte ich hierzu die Subdomain www.gruniversal.mars einrichten und Aufrufe von gruniversal.mars automatisch dorthin umleiten.
Die Einrichtung selbst ist vergleichbar zur Einrichtung der Domain. Zunächst wird die Subdomain in der hosts-Datei zusätzlich bekannt gemacht:
david@mars ~ $ sudo vim /etc/hosts
127.0.0.1 gruniversal.mars 127.0.0.1 www.gruniversal.mars
Danach folgt die Konfiguration im Webserver. Dabei muss man keinen neuen Virtual-Host anlegen, sondern kann den bestehenden um den neuen Servernamen ergänzen, indem man ihn als ServerAlias angibt.
david@mars ~ $ sudo vim /etc/apache2/sites-available/001-gruniversal.mars.conf
<VirtualHost *:80>
ServerName gruniversal.mars
ServerAlias www.gruniversal.mars
DocumentRoot /home/david/workspace/websites/gruniversal.de/
</VirtualHost>
Nach einem entsprechenden Reload des Apache ist die Subdomain dann ebenfalls verfügbar. Damit ist der einfache Teil abgeschlossen.
Ich verwende als Betriebssystem aktuell Linux Mint und möchte meine Website auch lokal anschauen und entwickeln können. Dafür bietet es sich an auch ein ähnliches Setup zu haben, was für mich z.B. heißt, dass die Website auch eine eigene lokale Domain bekommt. Da mein Rechner “Mars” heißt, hab ich dazu folgendes in meine hosts-Datei eingetragen um die lokale Domain gruniversal.mars einzurichten:
david@mars ~ $ sudo vim /etc/hosts
127.0.0.1 gruniversal.mars
Damit der Apache die Domain ebenfalls kennt, ist folgendes notwendig:
david@mars ~ $ sudo vim /etc/apache2/sites-available/001-gruniversal.mars.conf
<VirtualHost *:80>
ServerName gruniversal.mars
DocumentRoot /home/david/workspace/websites/gruniversal.de/
</VirtualHost>
Damit wird die Domain bekannt gemacht und auf das Hauptverzeichnis verwiesen.
(Hinweis: Bei mir läuft der Apache im Home-Verzeichnis, weil ich ohnehin der einzige Nutzer bin und so die Files im home-Backup gleich mit enthalten sind. Oft wird hier auch /srv/www/ oder /var/www/ genutzt.)
Damit nun die Konfiguration auch wirksam wird, muss die Site im Apache noch aktiviert werden und die Webserver-Konfiguration neu geladen werden:
david@mars ~ $ sudo a2ensite 001-gruniversal.mars.conf Enabling site 001-gruniversal.mars. To activate the new configuration, you need to run: service apache2 reload david@mars ~ $ service apache2 reload
Nachdem dies erfolgreich war, funktioniert die Domain wie erwartet:
http://gruniversal.mars/
Im nächsten Schritt möchte ich zusätzlich auch die passende www-Subdomain einrichten und entsprechend alle Aufrufe umleiten.
In den letzten Monaten wurde der Druck sich mal wieder um meine Domain gruniversal.de zu kümmern immer größer. Mein Provider wollte den Server von Confixx auf Plesk umstellen und die PHP-Version zumindest auf 7.0 anheben.
Zudem hatte ich selbst ein paar Ideen, was man mal angehen könnte:
In der Folge habe ich Anfang Februar meinen Provider kontaktiert und im ersten Schritt einen neuen Tarif beauftragt. Der hat dann zügig die entsprechende Umgebung eingerichtet und ich konnte loslegen.
Ich werde in der nächsten Zeit meine Erkenntnisse im Rahmen der Migration hier dokumentieren und das gleich zum Anlass nehmen mal wieder einen persönlichen IT-Blog auf WordPress-Basis zu starten.
Präsentiert von WordPress & Theme erstellt von Anders Norén