Viele Anwendungen im Geschäftsumfeld setzen einen Tomcat Webserver voraus. Aus Sicherheitsgründen gehen viele IT-Administratoren dazu über, diesen nicht direkt ins Netz zu hängen, sondern einen anderen Server, beispielsweise einen IIS (Internet Information Services) als Reverse-Proxy vor dem Tomcat zu setzen. In dieser Anleitung möchte ich zeigen, wie genau das funktioniert.
Inhaltsverzeichnis
IIS als Reverse-Proxy
Der IIS soll als Reverse-Proxy vor dem Tomcat geschaltet werden. Der Tomcat ist im Netzwerk dann nicht mehr erreichbar und Anfragen an den Tomcat gehen über den IIS, welcher wiederum die Anfragen an den Tomcat weiterleitet. Der Tomcat ist nur noch für den IIS erreichbar, nicht aber für Anfragen aus dem Netzwerk.

Ausgangsbasis und Zielsetzung
Als Testumgebung habe ich einen nackten Windows Server 2022 installiert. Es befindet sich lediglich ein nicht konfigurierter Apache Tomcat auf dem Server, der auf Port 8080 (HTTP) lauscht und über http://localhost:8080 erreichbar ist. Der IIS soll später mit einem Zertifikat ausgestattet sein und auf Port 80 (HTTP) und 443 (HTTPS) lauschen und die Anfragen entsprechend an den Tomcat weiterleiten. Eine automatische Weiterleitung von HTTP auf HTTPS soll der IIS auch vornehmen. Wenn man so will, spielt der IIS "Übersetzer" zwischen Client und Tomcat, der die eigentliche Webanwendung hostet.

IIS installieren
Die Grundinstallation des IIS ist denkbar einfach. Der eigentliche IIS kann über den Server-Manager installiert werden. Es ist lediglich die Rolle "Webserver (IIS)" anzuhaken. Die Nachfrage, ob Verwaltungstools installiert werden sollen, bestätige ich. Alle anderen Schritte während der Installation belasse ich im Standard.

Installation Zusatzmodule
Für den IIS werden noch zwei Module benötigt, die installiert werden müssen:
Ich verwende diese Downloadlinks, weil diese auch ohne den Microsoft Web Platform Installer funktionieren, dessen Support dieses Jahr endet:
- Application Request Routing: https://go.microsoft.com/fwlink/?LinkID=615136
- URL Rewrite: https://download.microsoft.com/download/1/2/8/128E2E22-C1B9-44A4-BE2A-5859ED1D4592/rewrite_amd64_de-DE.msi
Bei der Installation beider Module ist nichts zu beachten. Der Installer kann einfach durchgeklickt werden.
Der IIS kann jetzt über den Server-Manager -> Tools -> Internetinformationsdienste (IIS)-Manager gestartet werden.
IIS konfigurieren
Im linken Baum wird der Webserver und die verschiedenen Sites angezeigt. Zunächst lösche ich die Site "Default Web Site", da ich es gerne aufgeräumt habe und ich nachher ohnehin eine neue Site für den Reverse-Proxy einrichte. Außerdem belegt die Standardsite Port 80, der später für den Reverse Proxy benötigt wird.

Nachdem die Standardsite gelöscht ist, erstelle ich direkt eine neue Site. Das geht per Rechtsklick auf den Punk "Sites" und "Website hinzufügen...". Es ist mindestens ein aussagekräftiger Name und ein physischer Pfad im Dateisystem anzugeben. Die anderen Einstellungen belasse ich erstmal im Standard:

Zertifikat erstellen
Da der IIS über HTTPS erreichbar sein soll, muss ein entsprechendes Zertifikat erstellt werden. Hier gibt es mehrere Vorgehensweisen. Man könnte entweder ein selbstsigniertes Zertifikat erstellen (nicht empfohlen) oder ein Domänenzertifikat, wenn man über eine Active Directory mit Zertifikatsdiensten (CA) verfügt. Beide Möglichkeiten erklären ich im Artikel HTTPS für IIS konfigurieren. An dieser Stelle werde ich daher nicht näher auf die Erstellung des Zertifikats eingehen.
Bindungen im IIS konfigurieren
Wenn ein Zertifikat vorhanden ist, können im IIS die Bindungen konfiguriert werden. Die Bindungen geben an, auf welche Ports und unter welchen DNS-Namen oder IP-Adressen der IIS erreichbar sein soll. Es ist dafür mit der rechten Maustaste auf die neue Site und auf "Bindungen bearbeiten..." zu klicken:

Eine Zeile sollte bereits vorhanden sein: HTTP Port 80. Ich erstelle eine zweite Bindung per Klick auf "Hinzufügen...":

Als Typ ist "https" anzugeben. Den Port belasse ich im Standard. Unter ist schließlich noch das SSL-Zertifikat auszuwählen, was wir im Schritt zuvor in Windows installiert haben. IP-Adresse und Hostname lasse ich frei, da der IIS auf alle Anfragen zu diesem Port reagieren soll.
An dieser Stelle lässt sich der IIS bereits per HTTP und HTTPS aufrufen. Allerdings erscheint noch eine 403-Fehlermeldung, die an dieser Stelle aber erstmal egal ist.

Application Request Routing konfigurieren
Als nächstes muss der Application Request Routing Proxy aktiviert werden. Dazu ist im IIS aus den Server und auf "Application Request Routing" doppelt zu klicken:

Auf der rechten Seite ist der Punkt "Server Proxy Settings..." zu sehen. Dieser muss angeklickt werden:

Es öffnen sich die Proxy Settings. Der Proxy ist im Standard deaktiviert und muss aktiviert werden. Mehr als das Häkchen zu setzen, ist in den meisten Fällen nicht erforderlich. Anschließend sind die Änderungen noch zu übernehmen:

Die Konfiguration für das Modul "Application Request Routing" sind damit abgeschlossen.
URL Rewrite konfigurieren
Die eigentliche Konfiguration für den Reverse-Proxy wird über das Modul "URL Rewrite" vorgenommen. Dazu ist in der linken Hälfte auf die neue Site für den Reverse-Proxy (nicht auf den Eintrag für den Server) und anschließend doppelt auf "URL Rewrite" zu klicken:

Auf der rechten Seite befindet sich jetzt die Option "Regel(n) hinzufügen...":

Wir benötigen für unser Setup zwei Regeln:
- Weiterleitung von HTTP auf HTTPS
- Weiterleitung von HTTPS auf Tomcat Port 8080
Die erste Regel sorgt dafür, dass alle HTTP-Anfragen, die an den IIS ankommen, einfach auf HTTPS umgeleitet werden. Mehr macht der IIS nicht mit HTTP-Anfragen. Die zweite Regel sorgt dafür, dass die HTTPS-Anfragen an den Tomcat weitergeleitet werden.
Weiterleitung von HTTP auf HTTPS
Erstellen wir jetzt die erste Regel, die die Weiterleitung von HTTP auf HTTPS vornimmt. Nach einem Klick auf "Regel(n) hinzufügen...", ist eine leere Regel zu erstellen:

Zunächst vergebe ich einen aussagekräftigen Namen wie "HTTP zu HTTPS" und gebe das Muster (.*) an. (.*) trifft hierbei auf alle möglichen Anfragen zu.

Weiter unten muss noch eine Bedingung und eine Aktion angegeben werden. Die Bedingung soll aussagen "Wenn HTTPS deaktiviert ist...". Die Aktion sagt aus, dass die angefragte Adresse auf HTTPS umgeleitet wird.
Bedingung
Eingabe: {HTTPS}
Muster: ^OFF$
Aktion
Aktionstyp: Umleiten
URL umleiten: https://{HTTP_HOST}{REQUEST_URI}

Nach einem Klick auf "Übernehmen" oben rechts sollte die automatische Weiterleitung von HTTP und HTTPS bereits funktionieren. Wenn nicht, versuche einmal den Test in einem privaten Browserfenster zu wiederholen.
Weiterleitung von HTTPS auf Tomcat
Im nächsten Schritt wird die zweite Regel erstellt: Die Weiterleitung der Anfragen an den Tomcat. Dazu ist im Bereich "URL Rewrite" wieder eine neue Regel zu erstellen:

Dieses Mal wähle ich aber die Regelvorlage "Reverseproxy" aus:

Es ist ganz oben die Ziel-URL anzugeben, unter der der Tomcat erreichbar ist. Außerdem lasse ich den Haken "SSL-Abladung aktivieren" aktiviert, weil der Tomcat in meinem Beispiel nicht für HTTPS konfiguriert ist.

Nach einem Klick auf "OK" ist die Regel erstellt. Sie braucht aber noch etwas Feintuning. Als erstes benenne ich die Regel einmal um. Dazu wähle ich sie aus und klicke rechts auf "Umbenennen".

Um die Regel weiter zu bearbeiten, wähle ich wie Regel aus und klicke rechts im Menü unter "Eingehende Regeln" auf "Bearbeiten...". Dort belasse ich den oberen Teil wie er ist. Als Muster ist wie auch schon bei der ersten Regel (.*) angegeben. Ich bearbeite die Bedingungen wie folgt:
Bedingung
Eingabe: {HTTPS}
Muster: ^ON$
Bei der Aktion muss ich nichts anpassen, da diese bereits automatisch korrekt konfiguriert wurde:
Aktionstyp: Umschreiben
URL umschreiben: http://localhost:8080/{R:1}

Nach einem Klick auf "Übernehmen" oben rechts sollte die Regel sofort funktionieren und der Tomcat antwortet auf Anfragen an den IIS:

Die Konfiguration am IIS ist somit erfolgreich abgeschlossen.
Tomcat konfigurieren
Der Tomcat hat eine Eigenheit, die dazu führen kann, dass eine Tomcat-Anwendung hinter einem Reverse Proxy nicht korrekt funktioniert. Konkret kommt es immer dann zu Fehlern, wenn eine Tomcat-Anwendung die Funktionen request.getServerName() oder request.getServerPort() aufruft. Denn dann bekommt die Anwendung nur die Adresse des Tomcats, in unserem Fall also localhost:8080 zurück, die aber im Netz nicht erreichbar ist. Wir müssen dem Tomcat daher sagen, dass er hinter einem Proxy läuft. Das geht in der server.xml mit den folgenden Parametern:
proxyName="PROXY-DNS" proxyPort="443"
Einen weiteren Parameter möchte ich der Konfiguration hinzufügen:
scheme="https"
Tomcat-Anwendungen können mit der Funktion request.getScheme() das Protokoll, also HTTP oder HTTPS abfragen. Da der IIS aber über HTTPS und der Tomcat über HTTP erreichbar ist, müssen wir dem Tomcat noch sagen, dass HTTPS verwendet werden soll.
Die gesamte Konfiguration sieht jetzt wie folgt aus:
proxyName="websrv01" proxyPort="443" scheme="https"
Diese Parameter müssen in der server.xml Konfigurationsdatei des Tomcats dem HTTP-Connector hinzugefügt werden. Die server.xml Konfigurationsdatei befindet sich im Verzeichnis "conf" im Installationsverzeichnis.

Eine Änderung an der Konfigurationsdatei des Tomcats wirkt sich erst nach einem Neustart des Tomcats aus.
Weitere Sicherheitsaspekte
Zum Schluss sollte noch ein Blick auf die Windows Firewall geworfen werden, um sicherzugehen, dass der Tomcat nicht doch noch im Netzwerk erreichbar ist und Anfragen an den IIS Reverse-Proxy vorbeigeschleust werden könnten. Am besten ist es, eine eingehende Firewallregel für Port 8080 zu erstellen und die Verbindung zu blockieren.
Ein weiterer Aspekt gilt den Standardfehlerseiten des Tomcats. Wer beispielsweise eine nicht existierende URL versucht aufzurufen, erhält den bekannten 404-Fehler. Dieser wird aber natürlich vom Tomcat zurückgegeben und enthält die Versionsnummer und die Info, dass überhaupt ein Tomcat hinter dem IIS läuft. Es kann sich also hier anbieten, die Standardfehlerseiten des Tomcats zu unterdrücken. Dazu einfach in der Datei conf/web.xml folgenden Text innerhalb des web-app-Tags hinzufügen:
<error-page>
<error-code>403</error-code>
<location>/403.html</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>/404.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/500.html</location>
</error-page>
Herzlichen Glückwunsch, die Konfiguration von einem IIS Reverse-Proxy vor einem Tomcat ist damit erfolgreich abgeschlossen.
Weiterführende Links
https://www.ionos.de/digitalguide/server/knowhow/was-ist-ein-reverse-proxy/
Quellen
https://www.namecheap.com/support/knowledgebase/article.aspx/9953/38/iis-redirect-http-to-https/
https://tomcat.apache.org/tomcat-10.0-doc/proxy-howto.html
https://tomcat.apache.org/tomcat-10.0-doc/config/http.html
https://tomcat.apache.org/tomcat-10.0-doc/config/http.html#Proxy_Support
4 Antworten auf „IIS als Reverse-Proxy vor Tomcat einsetzen“
Hallo und herzlichen Dank für deine tollen Beiträge.
Was ich hier nicht ganz verstehe - vor was schützt nun diese Konstellation? Alle Aufrufe / Requests werden doch nun 1:1 an den Tomcat weitergeleitet?!
Viele Grüße
Hallo Lixe,
ein Szenario könnte sein, dass manche Anwendungen ihren eigenen integrierten Tomcat mitbringen, der aber nicht regelmäßig aktualisiert werden kann. Um jetzt keine offenen Sicherheitslücken im Netz zu haben, schaltet man einen anderen Webserver davor, den man besser patchen oder generell verwalten kann. So ist der verwundbare Tomcat nicht mehr direkt erreichbar.
LG Rafael
Hallo,
vielen Dank für die ausführliche Anleitung für die Einrichtung eines IIS-Reverse-Proxy.
Wir haben uns allerdings damit ein Problem eingehandelt, das uns mehrere Tage Fehlersuche gekostet hat.
Windows-Server verwenden intern gerne IPv6, selbst wenn der Server selber gar keine IPv6-Adresse bekommen hat. Daher wird "localhost" vom IIS lokal anscheinend erstmal zu ::1 aufgelöst (wie bei 'Ping localhost'), was zu einem Timeout von einer Sekunde führt, da der Tomcat (hier) nur auf IPv4 lauscht.
Erst danach probiert der IIS die 127.0.0.1, was dann endlich zum Erfolg führt. Eine Verzögerung von einer Sekunde bei jedem(!) Request via localhost sorgt aber für einen Performanceeinbruch ohne Gleichen.
Eine Änderung der Reverse-Proxy-Eingangsregel von Zielhost = 'localhost:8080' zu '127.0.0.1:8080' zwingt den IIS dazu, gleich IPv4 zu nutzen und die eine Sekunde Timeout wegzulassen. Und siehe da: die Anwender sind wieder glücklich!
Wir haben auf Einstellungsänderungen in Richtung "Prefer IPv4" verzichtet, da die Zukunft ja doch eher bei IPv6 liegt.
Vielleicht hilft diese Info dem einen oder anderen.
Ich wünsche allen noch einen schönen Tag
(Ich schreibe hier unter meiner privaten Emailadresse, daher keine Infos zur Firma.)
Hallo Bert,
cool, dass du das herausgefunden hast und mit uns teilst 🙂
LG Rafael