HTTPS

Erklärtes Ziel war es, die Anwendungen unter der Domain athanassiou.me sicher über HTTPS bereitzustellen, und auf den Zusatz 8080 verzichten zu können. Denn das tat bisher einfach nicht … aus gutem Grund. Irgendwie kam ich mit den selbst erworbenen Zertifikaten und der plesk installation nicht zurecht, egal was ich in die server.xml geschrieben habe.

Der Unterschied zwischen HTTP und HTTPS

Der grundlegende Unterschied zwischen HTTP und HTTPS liegt in der Sicherheit der Datenübertragung. Während HTTP Daten unverschlüsselt überträgt, fügt HTTPS eine zusätzliche Sicherheitsebene hinzu:
Weitere wichtige Unterschiede zwischen HTTP und HTTPS sind:

Einrichtung von HTTPS und Reverse Proxy für Tomcat unter STRATO-Plesk

Eigentlich ist das Einrichten von https eine "Commodity" - jede KI kann eine detaillierte Anleitung ausspucken.Um HTTPS für den Tomcat zu aktivieren, sind folgende Schritte erforderlich:
  1. SSL-Zertifikat beschaffen: SSL-Zertifikat kaufen oder ein kostenloses Angebot wie Let's Encrypt nutzen.
  2. SSL-Zertifikat installieren: Zertifikat auf dem Server gemäß den Anweisungen des Hosting-Anbieters installieren.
  3. Konfiguration des Tomcat: server.xml für HTTPS-Verbindungen über Port 443 mit Zertifikaten einrichten.
  4. Weiterleitung einrichten: Permanente 301-Weiterleitung von HTTP auf HTTPS einrichten.
Leider hat das nicht funktioniert ... und ich hatte keine Ahnung warum, aber irgendwie schien das mit plesk zusammenzuhängen. Das Rätsel löste sich 2 Jahre später auf, als ich nochmal einen Anlauf nahm.

Ausgangssituation - Was war da los?

Der Server wird bei STRATO betrieben und nutzt die dort vorinstallierte Plesk-Weboberfläche. Die Java-Webanwendungen laufen in einem Apache Tomcat auf Port 8080. Tomcat lief sauber auf Port 8080 mit HTTP, aber alle HTTPS-Zugriffe auf die Domain gingen zuerst an Plesk. Der erste Ansatz, SSL „direkt“ im Tomcat einzurichten, scheiterte aus genau diesem Grund: Port 443 war bereits durch den Plesk-eigenen nginx/Apache-Stack belegt. Tomcat konnte diesen Port weder übernehmen noch parallel nutzen. Da plesk die Ports 80 und 443 vollständig belegt, war also eine direkte HTTPS-Nutzung von Tomcat nicht möglich.

TLS-Management durch Plesk oder I’m the Boss

If you can't beat them - join them.

Damit war klar, dass der Weg über plesk gehen muss. Inkusive der Zertifikate. Über den Menüpunkt "SSL/TLS Certificates" kann ein Let's-Encrypt-Zertifikat zugewiesen werden, das Plesk automatisch erneuert und in nginx/Apache einbindet. Anstelle einer SSL-Konfiguration direkt im Tomcat übernimmt nun Plesk vollständig die TLS-Terminierung. Zertifikate werden über die integrierte Let's-Encrypt-Unterstützung erzeugt und automatisch erneuert.Damit lassen sich automatisch gültige TLS-Zertifikate für die Domain erstellen, erneuern und verwalten – ganz ohne manuelle CSRs, KeyStores oder PKCS#12-Erzeugung.

Das Verfahren hat einige Vorteile:

Tomcat benötigt daher keine eigenen Zertifikate oder SSL-Connectoren. Das spart einem einiges an Gefuddel in der tomcat Konfiguration.

Architektur der Lösung

nginx fungiert als erste Instanz für HTTPS-Verbindungen, übernimmt TLS und leitet Anfragen an Apache weiter. Apache führt die Reverse-Proxy-Regeln aus und leitet Requests intern an Tomcat weiter. Tomcat selbst läuft ausschließlich als HTTP-Backend auf Port 8080.

Reverse-Proxy-Konfiguration in Apache

Der entscheidende Schritt bestand darin, in den „Apache Additional Directives“ in Plesk (Websites & Domains → Apache & nginx Settings → Additional Apache directives ) folgendes Snippet zu hinterlegen: 

<IfModule mod_proxy.c>
    ProxyPreserveHost On
    ProxyRequests Off
    ProxyPass        / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
</IfModule>

Damit wird jede Anfrage an die Domain über Apache zu Tomcat weitergeleitet. Tomcat erhält den korrekten Hostnamen und weiß über den Header X-Forwarded-Proto: https, dass die ursprüngliche Verbindung verschlüsselt war.

Auch die permanente Umleitung aller HTTP-Anfragen automatisch auf HTTPS wird in plesk per anklicken eingerichtet.

All that ends ends good

Die Anwendungen sind jetzt stabil und sicher unter: 

https://athanassiou.me
zu erreichen, und die Browser können sich die Passworte auch merken.

Im Ergebnis hat die Lösung jetzt folgende Eigenschaften:

Hat ja auch nur 2 Jahre gedauert, und die Lösung kann Spuren von KI (ChatGPT) enthalten - auf dem klassischen Weg war das nicht herzuleiten.

Exkurs: Was genau macht nginx in diesem Setup?

Unter Plesk arbeitet nginx als vorgeschaltete Instanz vor Apache. Es übernimmt:

nginx selbst wird nicht für eigene Location-Blöcke genutzt, da diese von Plesk verwaltet werden. Der Reverse Proxy erfolgt ausschließlich in Apache, was im Plesk-Web Admin Edition der unterstützte Weg ist.