HTTPS — Reverse Proxy für Tomcat

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.

HTTP vs 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:

• Verschlüsselung: HTTPS verschlüsselt die Daten zwischen Browser und Webserver, sodass sie für Dritte nicht lesbar sind.
• Authentifizierung: HTTPS verwendet SSL/TLS-Zertifikate zur Verifizierung der Identität der Website.

Weitere wichtige Unterschiede zwischen HTTP und HTTPS sind:

• Port: HTTP verwendet standardmäßig Port 80, HTTPS hingegen Port 443.
• URL-Präfix: HTTP-URLs beginnen mit "http://", HTTPS-URLs mit "https://".
• Sicherheitsanzeige im Browser: HTTPS-Verbindungen werden in modernen Browsern durch ein Schloss-Symbol in der Adressleiste gekennzeichnet.

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 — I'm the Boss

If you can't beat them — join them.

Damit war klar, dass der Weg über Plesk gehen muss. Inklusive 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:

• Automatische Zertifikatserstellung und -erneuerung
• Keine SSL-Konfiguration im Tomcat notwendig
• Keine Port-Konflikte
• Reduzierter Wartungsaufwand

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 Passwörter auch merken.

Im Ergebnis hat die Lösung jetzt folgende Eigenschaften:

• HTTPS funktioniert über Plesk-Zertifikate
• Tomcat läuft als interner HTTP-Dienst
• Kein Port 8080 in der externen URL sichtbar
• Keine SSL-Konfiguration im Tomcat notwendig
• http:// wird intern auf https:// geschwenkt
• Sauber getrennte Rollen: Plesk Apache als Frontend, Tomcat als Backend

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:

• TLS-Terminierung: nginx verarbeitet den HTTPS-Handshake und präsentiert das Zertifikat.
• Protokolloptimierung: Unterstützung für HTTP/2 und moderne Ciphers.
• Sicherheitsfilter: nginx blockiert ungültige Verbindungen und fehlerhafte Anfragen.
• Routing: nginx leitet Anfragen intern an Apache weiter.
• Leistung: nginx entlastet Apache durch effizientes Request-Handling.

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.