Kernmodul Tomcat-Einrichtung

Installation und Einrichtung von Tomcat

Für das SuperX-Kernmodul 6.0 empfehlen wir Tomcat 10.1 mit Java 21. Die folgenden Beispiele beziehen sich überwiegend auf Ubuntu Linux 26.04. Bei anderen Linux-Distributionen sind die Konfigurationsschritte weitgehend identisch, die Paketnamen und Pfade können aber abweichen.

Der Umstieg von Tomcat 9 auf Tomcat 10 ist kein reines Versionsupdate. Die Java-EE-Schnittstellen wurden von javax.* nach jakarta.* umgestellt. Für Tomcat 10 wird eine dafür geeignete SuperX-Webanwendung benötigt. Weitere Hinweise dazu stehen im Abschnitt Wechsel von Tomcat 9 auf Tomcat 10.

Tomcat aus Linux Distributionen

Da die Versionsnummern des Tomcat nicht immer zu SuperX passen, können Sie einen eigenen Tomcat bzw. den im SuperX-Kernmodul mitgelieferten Tomcat nutzen. Auch wenn Sie mehrere Tomcats auf einem Server betreiben, kann es sinnvoll sein, Tomcat manuell zu installieren. Der Betrieb von Tomcat aus der jeweiligen Linux-Distribution hat jedoch den Vorteil, dass man

• benötigte Drittsoftware direkt mitinstallieren kann
• die Apache-Integration einfacher einrichten kann
• regelmäßige Sicherheitsupdates und Bugfixes über die Paketverwaltung beziehen kann
• Tomcat in der Regel bereits als systemd-Dienst erhält

Wenn eine für SuperX geeignete Tomcat-Version in der Distribution enthalten ist, empfehlen wir daher die Installation aus der Distribution.

Tomcat aus der Ubuntu-Distribution

Im Folgenden wird das Vorgehen für Ubuntu Linux 26.04 mit Java 21 und Tomcat 10.1 beschrieben. Zunächst wechseln Sie in die root-Shell mit

sudo -i

Java 21, Tomcat 10 und den Apache-Webserver installieren:

apt-get update
apt-get install -y openjdk-21-jdk tomcat10 apache2

Tomcat anschließend zunächst stoppen:

systemctl stop tomcat10.service

Die installierten Versionen können Sie prüfen mit

java -version
/usr/share/tomcat10/bin/version.sh

Das Ubuntu-Paket tomcat10 enthält Tomcat 10.1. Die tatsächlich ausgelieferte Patchversion hängt vom Paketstand ab. Die hier empfohlene Kombination mit Java 21 ist eine SuperX-Empfehlung; Tomcat 10.1 selbst benötigt mindestens Java 11.

Die Konfiguration des Distributions-Tomcat liegt üblicherweise in

/etc/tomcat10/server.xml

und die Webanwendungen in

/var/lib/tomcat10/webapps

Kopieren Sie die zu Tomcat 10 passende SuperX-Webanwendung in das webapps-Verzeichnis. Der Tomcat-Dienstbenutzer muss auf die benötigten Dateien zugreifen können; die Eigentümer- und Schreibrechte sollten auf die tatsächlich erforderlichen Verzeichnisse begrenzt werden. Beim HTTP-Connector in der server.xml setzen Sie die Zeichenkodierung auf UTF-8. Wenn Apache und Tomcat auf demselben Server laufen, empfehlen wir außerdem die Bindung an localhost:

<Connector port="8080" protocol="HTTP/1.1"
           address="127.0.0.1"
           connectionTimeout="20000"
           URIEncoding="UTF-8" />

Die weiteren Einstellungen für den Betrieb hinter Apache werden unter Apache Anbindung erläutert. Weitere Details zur server.xml siehe SuperX-Installationshandbuch.

Unter Ubuntu können Java-Optionen üblicherweise in der Datei

/etc/default/tomcat10

hinterlegt werden, z.B.:

JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
JAVA_OPTS="-Djava.awt.headless=true -DSuperX-DB-PROPERTIES-SET=true -Xmx3700M"

Der Speicherwert ist nur ein Beispiel. Prüfen Sie mit systemctl cat tomcat10, welche Konfigurationsdateien der installierte Dienst tatsächlich einliest. Die vom Paket bereitgestellte systemd-Service-Datei sollte nicht direkt bearbeitet werden; bei Bedarf verwenden Sie eine systemd-Override-Datei. Starten Sie Tomcat mit

systemctl start tomcat10.service

und prüfen Sie den Status mit

systemctl status tomcat10.service

Wenn der HTTP-Connector nur an 127.0.0.1 gebunden ist, kann der Zugriff auf demselben Server getestet werden mit

curl -I http://127.0.0.1:8080/superx/

Für den Aufruf vom Arbeitsplatzrechner wird anschließend die Apache-Anbindung eingerichtet.

Tomcat unter anderen Linux-Distributionen

Auch unter SUSE Linux und Red Hat Enterprise Linux können Sie den Tomcat aus der Distribution oder manuell installieren. Die genauen Paketnamen, Dienstnamen und Verzeichnisse sind distributionsabhängig. Entscheidend sind eine geeignete Tomcat-10.1-Version, Java 21, eine kompatible SuperX-Webanwendung und die Konfiguration des HTTP-Connectors bzw. AJP-Connectors. Ältere Verfahren mit rctomcat, chkconfig oder SuSEconfig werden hier nicht mehr beschrieben. Für die Dienstverwaltung wird systemd verwendet.

Tomcat aus der Distribution mit abweichender Userkennung oder anderem webapps-Verzeichnis

Wenn Sie Tomcat aus der Distribution nutzen, läuft der Dienst unter einer dafür eingerichteten Systemkennung. Bei Ubuntu liegt das webapps-Verzeichnis üblicherweise unter /var/lib/tomcat10/webapps.

Standardmäßig hat der Tomcat-Dienstbenutzer keine Login-Shell. Dies sollte aus Sicherheitsgründen so bleiben.

Sie können das Verzeichnis der Webanwendungen auch ändern, indem Sie in der Datei /etc/tomcat10/server.xml beim Element Host das Attribut appBase anpassen, z.B.:

<Host name="localhost" appBase="/home/superx/webserver/tomcat/webapps"
      unpackWARs="true" autoDeploy="false">

Beachten Sie, dass der Tomcat-Dienstbenutzer Lese- und Ausführungsrechte auf den gesamten benötigten Verzeichnispfad benötigt. Schreibrechte sollten nur für tatsächlich beschreibbare Verzeichnisse vergeben werden, etwa für temporäre Dateien oder SuperX-Logdateien. Auf gemeinsam verwendeten Verzeichnissen kann die Gruppenberechtigung entsprechend angepasst werden. Wenn Sie als User superx neue Dateien anlegen und eine gemeinsam verwendete Gruppe eingerichtet haben, kann eine passende umask helfen:

# Full access to user and group, none for others:
umask u=rwx,g=rwx,o=

Die konkrete Gruppenkennung und die Eigentümerschaft richten sich nach der Installation. Beachten Sie auch die Hinweise für Tomcat und Kettle.

Tomcat und Kettle

Im Homeverzeichnis des Benutzers, unter dem Tomcat läuft, sollte das Verzeichnis .kettle mit der Datei kettle.properties angelegt werden. Die Datei kann zunächst leer sein. Ermitteln Sie zuerst das Homeverzeichnis des Tomcat-Benutzers, z.B. mit

getent passwd tomcat

Liegt dieses bei Ubuntu unter /var/lib/tomcat10, können Sie als root Folgendes ausführen:

install -d -o tomcat -g tomcat /var/lib/tomcat10/.kettle
touch /var/lib/tomcat10/.kettle/kettle.properties
chown tomcat:tomcat /var/lib/tomcat10/.kettle/kettle.properties

Bei einer Distributionsaktualisierung sollte geprüft werden, ob das Homeverzeichnis des Tomcat-Benutzers weiterhin korrekt gesetzt ist.

Tomcat manuell installieren

Sie können auch spezielle Versionen von Tomcat herunterladen und installieren. Oder Sie verwenden den im SuperX-Kernmodul mitgelieferten Tomcat. Speicherort ist z.B. /home/superx/webserver/tomcat. Bei einer Neuinstallation bzw. einem Versionswechsel sollten Sie die Konfiguration der neuen Tomcat-Version als Ausgangspunkt verwenden. Kopieren Sie nicht einfach die kompletten alten Verzeichnisse bin, lib und conf darüber. Auch bisher benötigte Zusatzbibliotheken und Java-Optionen müssen auf Kompatibilität geprüft werden.

Tomcat als Dienst

Damit Tomcat beim Systemstart automatisch hochfährt und beim Herunterfahren kontrolliert gestoppt wird, kann man einen systemd-Dienst anlegen. Im Beispiel liegt SuperX unter /home/superx und Tomcat wird vom Benutzer superx gestartet. Für eine Installation aus der Linux-Distribution ist der Dienst in der Regel bereits vorhanden.

Service-Scripte

Zunächst legen wir als User superx im Verzeichnis tomcat/bin zwei Dateien an. startup_service.x:

#!/bin/bash
# Startup script for Apache Tomcat with systemd
set -e
# Load the service settings
. /home/superx/db/bin/SQL_ENV
export CATALINA_BASE=/home/superx/webserver/tomcat
export CATALINA_HOME=/home/superx/webserver/tomcat
export CATALINA_TMPDIR=/home/superx/webserver/tomcat/temp
# Start Tomcat
cd "$CATALINA_BASE" && exec "$CATALINA_HOME/bin/catalina.sh" run

und shutdown_service.x:

#!/bin/bash
# Shutdown script for Apache Tomcat with systemd
set -e
# Load the service settings
. /home/superx/db/bin/SQL_ENV
export CATALINA_BASE=/home/superx/webserver/tomcat
export CATALINA_HOME=/home/superx/webserver/tomcat
export CATALINA_TMPDIR=/home/superx/webserver/tomcat/temp
# Stop Tomcat
cd "$CATALINA_BASE" && exec "$CATALINA_HOME/bin/catalina.sh" stop

In der Datei SQL_ENV sollten die für Tomcat benötigten Umgebungsvariablen, insbesondere JAVA_HOME für Java 21 und die Java-Optionen, korrekt gesetzt bzw. exportiert werden. Der Pfad zu Java ist von der Distribution abhängig.

Dienst einrichten

Legen Sie als User root die Datei /etc/systemd/system/tomcat_superx.service an, mit dem Inhalt:

[Unit]
Description=Tomcat SuperX
After=network.target

[Service]
Type=simple
User=superx
Group=users
WorkingDirectory=/home/superx/webserver/tomcat/bin
ExecStart=/bin/bash /home/superx/webserver/tomcat/bin/startup_service.x
ExecStop=/bin/bash /home/superx/webserver/tomcat/bin/shutdown_service.x

[Install]
WantedBy=multi-user.target

Die Gruppe users ist hier nur ein Beispiel und muss gegebenenfalls angepasst werden. Der Eintrag EnvironmentFile=/home/superx/db/bin/SQL_ENV wird nicht benötigt, da die Skripte die SQL_ENV bereits als Bash-Skript einlesen. systemd kann unter EnvironmentFile keine beliebigen Bash-Befehle ausführen. Den Dienst aktivieren und starten Sie mit

systemctl daemon-reload
systemctl enable tomcat_superx
systemctl start tomcat_superx

Den Status und die Logmeldungen können Sie prüfen mit

systemctl status tomcat_superx
journalctl -u tomcat_superx -e

Wenn Sie die Service-Datei ändern, müssen Sie danach systemctl daemon-reload ausführen. Den Dienst deaktivieren Sie mit

systemctl disable tomcat_superx

Ein Fallstrick: Wenn die SQL_ENV komplexe Bash-Kommandos enthält oder für einen systemd-Dienst ungeeignete Einstellungen setzt, kann der Dienststart scheitern. In diesem Fall kann eine separate, vereinfachte TOMCAT_ENV sinnvoll sein, die von den Startskripten eingelesen wird.

Für mögliche SELinux-Probleme bei Shell-Skripten in systemd-Diensten siehe SELinux im SuperX-Installationshandbuch.

Tomcat Logging

Tomcat Logging mit systemd

Je nach Installationsart erscheinen Tomcat-Meldungen im systemd-Journal oder in Dateien unter $CATALINA_BASE/logs. Bei einem manuell installierten Tomcat kann z.B. die Datei catalina.out vorhanden sein. Bei der Ubuntu-Distributionsinstallation sollte auch das systemd-Journal geprüft werden. Alle Journalmeldungen anzeigen:

journalctl

Die Meldungen eines bestimmten Tomcat-Dienstes anzeigen, z.B.:

journalctl -u tomcat10 -e
journalctl -u tomcat_superx -e

Die Meldungen live verfolgen:

journalctl -u tomcat10 -f

Ab SuperX 5.1 bzw. HISinOne-BI 2023.12 werden SuperX-spezifische Logmeldungen in der Datei $CATALINA_BASE/logs/superx.log ausgegeben. Je nach Fehlerbild sind sowohl diese Datei als auch die Tomcat-/systemd-Meldungen relevant.

Apache Anbindung

In Systemumgebungen, in denen bereits ein Webserver wie Apache läuft, bietet es sich an, den SuperX-Tomcat mit dem Webserver zu verbinden. Der Webserver kann so konfiguriert werden, dass Aufrufe zu https://superx.example.de/superx/ an Tomcat weitergeleitet werden. Dadurch müssen die internen Tomcat-Ports nicht nach außen freigegeben werden. Die HTTPS-Verschlüsselung und die Zertifikatsverwaltung können vom Apache übernommen werden. Wir empfehlen daher generell die Anbindung von Tomcat an Apache für einen Produktivbetrieb. Für die Verbindung zwischen Apache und Tomcat gibt es verschiedene Möglichkeiten:

• HTTP über Port 8080 mit ProxyPass (empfohlen)
• AJP über Port 8009 mit ProxyPass (Alternative)
• Mod-JK für bestehende Installationen

Wenn Apache und Tomcat auf demselben Server laufen, sollten die internen Connectoren nur an 127.0.0.1 gebunden werden. Bei getrennten Servern muss die Verbindung über ein vertrauenswürdiges und entsprechend geschütztes Netzwerk erfolgen.

ProxyPass über HTTP (Port 8080)

Wir empfehlen die HTTP-Anbindung über mod_proxy und mod_proxy_http. Sie ist einfach zu konfigurieren, verwendet das übliche HTTP-Protokoll und benötigt keinen AJP-Connector. AJP bietet zusätzliche Zugriffsmöglichkeiten auf Tomcat-interne Informationen und benötigt deshalb besondere Absicherung. HTTP über localhost ist damit bei gleicher Zugangsbeschränkung die einfacher zu betreibende Variante. Der interne HTTP-Verkehr ist dabei nicht verschlüsselt; dieses Beispiel gilt deshalb für Apache und Tomcat auf demselben Server. Unter Ubuntu aktivieren Sie die benötigten Apache-Module mit

a2enmod proxy proxy_http ssl

Tomcat konfigurieren

In der server.xml (bei Ubuntu /etc/tomcat10/server.xml) richten Sie den HTTP-Connector ein:

<Connector port="8080" protocol="HTTP/1.1"
           address="127.0.0.1"
           connectionTimeout="20000"
           URIEncoding="UTF-8"
           proxyName="superx.example.de"
           proxyPort="443"
           scheme="https"
           secure="true" />

Der Wert proxyName muss dem öffentlich verwendeten Hostnamen entsprechen. Die Angaben proxyPort="443", scheme="https" und secure="true" teilen Tomcat mit, dass die Anwender die Webanwendung über HTTPS am Apache aufrufen. Diese Konfiguration ist für eine ausschließlich über HTTPS erreichbare SuperX-Anwendung mit einem festen öffentlichen Hostnamen gedacht.

Apache konfigurieren

Im Apache-VirtualHost für HTTPS (unter Ubuntu z.B. in /etc/apache2/sites-available/superx.conf) ergänzen Sie die Weiterleitung:

<VirtualHost *:443>
    ServerName superx.example.de
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/superx.crt
    SSLCertificateKeyFile /etc/ssl/private/superx.key
    ProxyRequests Off
    ProxyPass "/superx" "http://127.0.0.1:8080/superx"
    ProxyPassReverse "/superx" "http://127.0.0.1:8080/superx"
</VirtualHost>

Die Zertifikatspfade sind Beispiele. Bestehende VirtualHosts werden entsprechend ergänzt; die SSL-Konfiguration muss nicht doppelt angelegt werden. ProxyPass leitet die Anfragen an Tomcat weiter, ProxyPassReverse passt bestimmte vom Backend gelieferte HTTP-Weiterleitungen an. URLs, die eine Webanwendung direkt in HTML erzeugt, werden dadurch nicht automatisch korrigiert. Nach den Änderungen prüfen Sie die Konfiguration und starten die Dienste neu:

apache2ctl configtest
systemctl restart tomcat10
systemctl reload apache2

Der Dienstname muss gegebenenfalls an die eigene Installation angepasst werden.

Falsche localhost-Adressen in DBForms bzw. HTML-Ausgaben

Wenn die öffentliche SuperX-Adresse über HTTPS aufgerufen wird, Tomcat intern aber nur den HTTP-Aufruf über localhost:8080 erkennt, können Webanwendungen fehlerhafte absolute URLs erzeugen. Das kann z.B. bei DBForms zu einem solchen HTML-Eintrag führen:

<base href="http://localhost:8080/superx/" />

Der Browser des Anwenders versucht dann, Ressourcen von seinem eigenen Rechner (localhost) zu laden. Bilder, Skripte oder Verweise funktionieren deshalb gegebenenfalls nicht. Mit den oben beschriebenen Connector-Attributen proxyName, proxyPort, scheme und secure kann Tomcat den korrekten öffentlichen Servernamen und das HTTPS-Schema an die Webanwendung melden.

{{{1}}}

Wenn mehrere öffentliche Hostnamen oder unterschiedliche Zugriffsschemata benötigt werden, reicht ein fest eingetragener proxyName gegebenenfalls nicht aus. Dann kann eine Konfiguration mit vertrauenswürdigen Proxy-Headern und der Tomcat-RemoteIpValve sinnvoll sein. Der Proxy muss solche Header kontrolliert setzen; unkontrolliert vom Client übernommene Header sind aus Sicherheitsgründen ungeeignet.

ProxyPass über AJP (Port 8009)

Alternativ kann die Verbindung über das AJP-Protokoll erfolgen. Dafür benötigen Sie beim Apache das Modul mod_proxy_ajp und auf Tomcat-Seite einen AJP-Connector. AJP ist weiterhin unterstützt, sollte aber nur in einem vertrauenswürdigen Netzwerk oder lokal verwendet werden. Das Secret schützt vor unberechtigten AJP-Verbindungen, verschlüsselt die Übertragung jedoch nicht. Unter Ubuntu aktivieren Sie das Modul mit

a2enmod proxy proxy_ajp

In der Tomcat-server.xml:

<Connector protocol="AJP/1.3"
           address="127.0.0.1"
           port="8009"
           secretRequired="true"
           secret="HIER_EIN_LANGES_ZUFAELLIGES_SECRET_EINTRAGEN"
           URIEncoding="UTF-8" />

Im Apache-VirtualHost wird anstelle der HTTP-Weiterleitung die AJP-Weiterleitung verwendet:

ProxyPass "/superx" "ajp://127.0.0.1:8009/superx" secret=HIER_EIN_LANGES_ZUFAELLIGES_SECRET_EINTRAGEN

Beide Secrets müssen übereinstimmen und dürfen nicht als öffentliche Beispielwerte übernommen werden. Der Parameter secret bei ProxyPass ist ab Apache 2.4.42 verfügbar. Auf beiden Seiten sollte die Konfiguration vor unberechtigtem Zugriff geschützt werden. Eine parallele HTTP- und AJP-Weiterleitung für denselben Pfad ist nicht erforderlich. Wenn Apache auf einem separaten Server läuft, muss statt 127.0.0.1 die geeignete interne IP-Adresse des Tomcat-Servers verwendet werden. Zusätzlich müssen Firewall und Netzabsicherung passend konfiguriert werden. Weitere Details siehe Tomcat AJP Connector.

Mod-JK

Das Apache-Modul mod_jk wird weiterhin für bestehende AJP-Installationen unterstützt. Für neue SuperX-Installationen empfehlen wir jedoch die oben beschriebene Anbindung über ProxyPass. Unter Ubuntu können Sie Mod-JK bei Bedarf installieren und aktivieren mit

apt-get install -y libapache2-mod-jk
a2enmod jk

Der AJP-Connector in Tomcat benötigt dieselben Sicherheitsvorgaben wie bei mod_proxy_ajp. In der workers.properties wird der Worker z.B. so eingerichtet:

worker.list=superx_tomcat
worker.superx_tomcat.type=ajp13
worker.superx_tomcat.host=127.0.0.1
worker.superx_tomcat.port=8009
worker.superx_tomcat.secret=HIER_EIN_LANGES_ZUFAELLIGES_SECRET_EINTRAGEN

Die Weiterleitung kann in der Apache-Konfiguration so erfolgen:

JkMount /superx/* superx_tomcat
JkMount /superx superx_tomcat

Falls bereits eine Mod-JK-Konfiguration aus dem SuperX-Kernmodul verwendet wird, können Sie diese weiter pflegen. Alte Beispielkonfigurationen mit einem ungeschützten AJP-Port oder unnötigen Apache-Dateisystem-Aliases sollten jedoch nicht unverändert übernommen werden.

Apache und Tomcat Sicherheit

Für den Produktivbetrieb empfehlen wir folgende Grundeinstellungen:

• HTTPS wird nach außen am Apache bereitgestellt. Die internen Ports 8080 bzw. 8009 werden nicht über die öffentliche Firewall freigegeben.
• Bei Betrieb auf demselben Server werden die Tomcat-Connectoren an 127.0.0.1 gebunden.
• Nicht benötigte Connectoren werden in der server.xml deaktiviert.
• Bei AJP wird ein eigenes, langes Secret verwendet; AJP sollte nicht über ungeschützte Netze betrieben werden.
• Der Tomcat-Dienst läuft ohne Root-Rechte. Konfigurationsdateien und die Webanwendung erhalten nur die benötigten Dateirechte.
• Apache, Tomcat und Java werden regelmäßig mit Sicherheitsupdates versorgt.
• Bei SELinux-bedingten Verbindungsproblemen oder Problemen mit systemd-Shell-Skripten siehe SELinux (Security-Enhanced Linux) im SuperX-Installationshandbuch.

Weitere Tipps zur Tomcat-Sicherheit siehe Tomcat Security How-To.

Einrichtung SSL

SSL Varianten

Sie können SSL/TLS direkt in Tomcat einrichten, normalerweise wird die Verschlüsselung aber im Webserver konfiguriert. Bei einer Apache-Tomcat-Anbindung empfehlen wir, HTTPS beim Apache zu beenden und den internen Tomcat-Connector nur lokal erreichbar zu machen.

SSL im Webserver

Unter Ubuntu benötigen Sie das Apache-Modul ssl. Es kann aktiviert werden mit

a2enmod ssl

Im HTTPS-VirtualHost wird das Zertifikat eingebunden, z.B.:

<VirtualHost *:443>
    ServerName superx.example.de
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/superx.crt
    SSLCertificateKeyFile /etc/ssl/private/superx.key
    # Weitere Einstellungen, z.B. die ProxyPass-Anbindung, siehe oben.
</VirtualHost>

Zertifikat und Schlüssel müssen zum öffentlichen Hostnamen passen. Die Datei mit dem privaten Schlüssel darf nur von berechtigten Systembenutzern gelesen werden. Die tatsächlich verwendeten Pfade richten sich nach der Zertifikatsverwaltung vor Ort. Wenn zusätzlich Zugriffe auf Port 80 auf HTTPS umgeleitet werden sollen, kann ein eigener VirtualHost verwendet werden:

<VirtualHost *:80>
    ServerName superx.example.de
    Redirect permanent / https://superx.example.de/
</VirtualHost>

Die Apache-Konfiguration prüfen und neu laden:

apache2ctl configtest
systemctl reload apache2

Zertifikate mit Let's Encrypt

Wenn der Server die Voraussetzungen für eine öffentliche ACME-Zertifikatsprüfung erfüllt, können Sie z.B. Let's Encrypt in Verbindung mit Certbot verwenden. Unter Ubuntu stehen dafür passende Pakete bereit:

apt-get install -y certbot python3-certbot-apache

Die konkrete Ausstellung, Einrichtung und automatische Verlängerung hängen davon ab, ob der Webserver öffentlich erreichbar ist und welche Zertifikatsverwaltung die Hochschule einsetzt. Weitere Informationen siehe Certbot und Let's Encrypt.

SSL im Tomcat

Falls kein vorgeschalteter Apache-Webserver vorhanden ist, kann Tomcat HTTPS auch direkt bereitstellen. In Tomcat 10.1 wird die TLS-Konfiguration über SSLHostConfig und Certificate vorgenommen. Beispiel mit vorhandenem PKCS12-Keystore:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true">
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="/home/superx/tomcat-keystore.p12"
                     certificateKeystoreType="PKCS12"
                     certificateKeystorePassword="HIER_DAS_KEYSTORE_PASSWORT" />
    </SSLHostConfig>
</Connector>

Der Keystore muss ein zum öffentlichen Hostnamen passendes Zertifikat und den privaten Schlüssel enthalten. Das Passwort im Beispiel muss durch einen eigenen sicheren Wert ersetzt und entsprechend geschützt werden. Bei direkt von außen erreichbarem Tomcat muss außerdem Port 8443 entsprechend abgesichert werden. Eine ausführliche Anleitung zum Erzeugen bzw. Einbinden von Zertifikaten steht in der offiziellen Tomcat-10.1-Dokumentation.

Wechsel von Tomcat 9 auf Tomcat 10

Mit Tomcat 10 wurden die Java-EE-Schnittstellen auf Jakarta EE umgestellt. Insbesondere wurden viele Paketnamen von javax.* nach jakarta.* geändert. Eine für Tomcat 9 bereitgestellte Webanwendung kann deshalb nicht ohne Weiteres mit Tomcat 10 verwendet werden. Für das SuperX-Kernmodul 6.0 empfehlen wir Tomcat 10.1 und Java 21. Für den Versionswechsel muss insbesondere geprüft werden, ob die SuperX-Webanwendung und zusätzlich eingesetzte Bibliotheken für Tomcat 10 geeignet sind. Die Konfiguration der neuen Tomcat-Version sollte als Grundlage verwendet werden; die bisherigen Konfigurationsdateien sollten nicht vollständig übernommen werden. Auch bestehende Java-Optionen sowie die Apache-Anbindung müssen geprüft werden.

Der Wechsel von Tomcat 9 auf Tomcat 10 wird wegen der umfangreicheren Umstellung in einem separaten Migrationsleitfaden behandelt. Bis dahin siehe offizielle Tomcat-Migrationshinweise.