Der Eintrag protocol="HTTP/1.1" in der server.xml beweist nicht, dass Tomcat ohne APR startet. In Tomcat 9.0.x kann der AprLifecycleListener mit useAprConnector="true" und verfügbarer nativer Bibliothek bei generischen Protokollnamen einen APR-Connector auswählen. Standardmäßig ist diese Option deaktiviert.
Was endet am 31. März 2027?
Für Apache Tomcat 9.0.x und Tomcat Native 1.3.x ist das Supportende am 31. März 2027 angekündigt. Die Tomcat-9-Familie soll mit Tomcat 9.1.x ohne APR-Connectors fortgeführt werden. Bestehende APR-Listener für HTTP, HTTPS und AJP brauchen vor diesem Versionswechsel einen anderen Connector, beispielsweise NIO.
Nach dem angekündigten Stichtag behebt das Apache-Projekt keine Fehler mehr, die ausschließlich Tomcat 9.0.x betreffen, und prüft Sicherheitsmeldungen nicht mehr gegen diesen Zweig. Auch nach einem weiteren Wartungsrelease von Tomcat Native 1.3.x bleibt dessen angekündigtes Supportende bestehen. Welche Listener tatsächlich APR verwenden, lässt sich an der gestarteten Instanz erkennen.
Ist dein Deployment von APR abhängig?
Für die Bestandsaufnahme zählt die $CATALINA_BASE/conf/server.xml der jeweiligen Instanz, nicht eine unbenutzte Datei im Installationsverzeichnis. Bei Container-Deployments werden die beim Start erzeugte Konfiguration und das tatsächlich gestartete Image erfasst.
- Die Klassen
org.apache.coyote.http11.Http11AprProtocolundorg.apache.coyote.ajp.AjpAprProtocolkennzeichnen ausdrücklich konfigurierte APR-Connectors - Bei
HTTP/1.1undAJP/1.3zeigen die Startprotokolle, welche Implementierung initialisiert wird - Der
AprLifecycleListener, seine Einstellungen und installiertelibtcnative*-Bibliotheken zeigen mögliche native Abhängigkeiten - Log-Einträge mit
http-aproderajp-aprbelegen initialisierte APR-Protokollhandler
Im Inventar stehen die verwendeten Versionen von Tomcat, Java, Tomcat Native und OpenSSL einschließlich der Bibliothekspfade. Die Ausgabe von openssl version allein genügt nicht: Das Kommandozeilenprogramm kann eine andere OpenSSL-Bibliothek verwenden als der Tomcat-Prozess.
Eine Meldung über geladenes Tomcat Native belegt umgekehrt noch keinen APR-Connector. Auch ein NIO-Connector kann OpenSSL über Tomcat Native verwenden; deshalb werden Netzwerk-Connector und TLS-Implementierung getrennt ausgewählt.
NIO-Connector und TLS-Implementierung auswählen
| Verwendung | APR-Ausgangsstand | NIO-Ersatz |
|---|---|---|
| HTTP und HTTPS | Http11AprProtocol | Http11NioProtocol |
| AJP | AjpAprProtocol | AjpNioProtocol |
Für HTTPS stehen mit NIO Java JSSE und OpenSSL zur Wahl. Mit Java JSSE benötigt Tomcat für TLS weder Tomcat Native noch eine separat geladene OpenSSL-Bibliothek. Für NIO mit OpenSSL ist unter Tomcat 9.1.x dagegen Tomcat Native 2.x vorgesehen.
Über sslImplementationName lässt sich die TLS-Implementierung ausdrücklich festlegen. In den folgenden XML-Beispielen stehen deshalb die NIO-Protokollklasse und beim HTTPS-Connector zusätzlich die gewählte TLS-Implementierung.
Http11AprProtocol und AjpAprProtocol ersetzen
Im ersten Beispiel ändern sich nur die Protokollklassen; Ports und AJP-Zugriffsschutz bleiben erhalten. Der AJP-Connector ist ausschließlich über die Loopback-Adresse erreichbar und setzt einen lokalen Reverse Proxy voraus. Der Platzhalter ${ajp.secret} muss beim Start aus einer bereitgestellten Java-System-Property aufgelöst werden.
<!-- Vorher: HTTP und AJP verwenden APR -->
<Connector port="8080"
protocol="org.apache.coyote.http11.Http11AprProtocol" />
<Connector port="8009"
protocol="org.apache.coyote.ajp.AjpAprProtocol"
address="127.0.0.1"
secretRequired="true"
secret="${ajp.secret}" /><!-- Nachher: dieselben Ports verwenden NIO -->
<Connector port="8080"
protocol="org.apache.coyote.http11.Http11NioProtocol" />
<Connector port="8009"
protocol="org.apache.coyote.ajp.AjpNioProtocol"
address="127.0.0.1"
secretRequired="true"
secret="${ajp.secret}" />HTTPS ausdrücklich auf Java JSSE umstellen
Der HTTPS-Connector im nächsten Beispiel liest sein Zertifikat aus einem PKCS12-Keystore. Auch der Kennwortplatzhalter setzt eine bereitgestellte Java-System-Property voraus; echte Kennwörter bleiben außerhalb des Konfigurations-Repositorys.
<Connector port="8443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
SSLEnabled="true"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation">
<SSLHostConfig>
<Certificate
certificateKeystoreFile="/etc/tomcat/tls/server.p12"
certificateKeystoreType="PKCS12"
certificateKeystorePassword="${tls.keystore.password}" />
</SSLHostConfig>
</Connector>Für OpenSSL lautet die Implementierungsklasse org.apache.tomcat.util.net.openssl.OpenSSLImplementation. Zertifikatsattribute und native Bibliotheken müssen zur gewählten Variante passen. Beim Wechsel auf Java JSSE hängen die verfügbaren TLS-Versionen und Cipher-Suites vom eingesetzten JDK und dessen Sicherheitskonfiguration ab.
APR-spezifische Poller-Parameter werden nicht in die NIO-Konfiguration übernommen. Bei Einstellungen wie useSendfile, die auch NIO unterstützt, gelten die Vorgaben des Ziel-Connectors.
Nach dem Neustart zeigen Präfixe wie http-nio, https-jsse-nio, https-openssl-nio und ajp-nio die gestarteten Protokollhandler. Diese Startnachweise werden zusammen mit dem Konfigurationsvergleich im anschließenden Testprotokoll erfasst.
Die Migration reproduzierbar testen
Mit dem k6-Executor constant-arrival-rate erhalten APR-Ausgangsstand und NIO-Kandidat dieselbe geplante Iterationsrate. Hardware und Testdaten bleiben identisch. Zum Testprotokoll gehören folgende Angaben:
- Die Aufwärmphase und die Messdauer
- Die geplante Iterationsrate und die verfügbaren virtuellen Nutzer
- Das versionierte Testskript und der verwendete Testdatenstand
- Die Versionsstände von Tomcat, Java und gegebenenfalls Tomcat Native sowie OpenSSL
- Der Konfigurations-Commit für den jeweiligen Testlauf
Die k6-Metrik dropped_iterations erfasst Iterationen, die das Lastwerkzeug nicht starten konnte. Bei solchen Ausfällen wurde die geplante Last nicht vollständig erzeugt; ein Vergleich allein anhand der konfigurierten Rate wäre irreführend.
| Prüfung | Verfahren und erwartetes Verhalten |
|---|---|
| Zertifikatskette und Servername | OpenSSL s_client validiert die Zertifikatskette gegen die vorgegebenen CA-Zertifikate und prüft den erwarteten Hostnamen; bei Validierungsfehlern wird die Verbindung abgebrochen |
| TLS-Versionen und Cipher-Suites | Die vorgesehenen Clients verbinden sich mit den freigegebenen TLS-Versionen und Cipher-Suites; gesperrte Varianten werden abgewiesen |
| Client-Zertifikate | Bei vorgeschriebenem mTLS gelingt der Zugriff mit zugelassenem Zertifikat; fehlende oder nicht vertrauenswürdige Zertifikate werden abgewiesen |
| Reverse Proxy | Die Anwendung erhält das erwartete Schema, den Hostnamen, den Port und die Client-Adresse; nicht vertrauenswürdige Absender können Forwarding-Header nicht wirksam vortäuschen |
| Uploads und Abbrüche | Uploads erreichen die vorgesehenen Größenlimits mit korrekter Prüfsumme; abgebrochene Verbindungen hinterlassen keine dauerhaft belegten Request-Threads |
| Lastvergleich | k6 erfasst Fehlerraten und Antwortzeit-Perzentile; auf dem Server werden zusätzlich die CPU-Auslastung, der residente Prozessspeicher (RSS) und die GC-Pausen gemessen |
Ein Test gegen einen lokal erreichbaren HTTPS-Connector kann beispielsweise so aussehen. Der Zertifikatsname app.example.test und der Pfad zur CA-Datei sind Platzhalter für die Testumgebung.
openssl s_client \
-connect 127.0.0.1:8443 \
-servername app.example.test \
-verify_hostname app.example.test \
-verify_return_error \
-CAfile /etc/tls/root-ca-bundle.pem < /dev/nullMit -servername sendet der Client den Namen per SNI; erst -verify_hostname aktiviert die entsprechende Namensprüfung. Die CA-Datei enthält für diesen Test nur die vertrauenswürdigen Wurzelzertifikate, damit fehlende Zwischenzertifikate in der Serverantwort auffallen.
Für die Freigabe lassen sich beispielsweise folgende Schwellen vereinbaren:
- Die p95-Antwortzeit liegt höchstens 10 % über dem APR-Ausgangswert
- Die 5xx-Fehlerrate steigt gegenüber dem APR-Ausgangsstand nicht an
- Die mittlere RSS liegt im vereinbarten Messfenster höchstens 15 % über dem APR-Ausgangswert
Die Prozentwerte sind frei gewählte Planungsbeispiele, keine Messergebnisse oder allgemeinen Tomcat-Grenzwerte. Das Team vereinbart die anwendungsspezifischen Schwellen und Messfenster vor dem Vergleich.
Bei TLS-Terminierung am Reverse Proxy werden die TLS-Verbindung zum Proxy und die Verbindung zwischen Proxy und Tomcat getrennt geprüft. Im Pilotbetrieb gelten anschließend dieselben Freigabeschwellen und Messfenster als Kriterien für einen Rollback.
Den Pilotbetrieb mit einem getesteten Rollback absichern
Für die Wiederherstellung werden die Konfiguration, die Zertifikatsspeicher und die Secret-Bereitstellung des Ausgangsstands gesichert. Dazu werden die Tomcat- und Java-Versionen sowie die nativen Bibliotheken einschließlich ihrer OpenSSL-Abhängigkeiten dokumentiert.
Vor dem Pilotbetrieb steht fest, wer bei überschrittenen Freigabeschwellen den Abbruch entscheidet und den alten Stand wiederherstellt. Beim Wiederherstellungstest startet das Team die vorherige Version mit ihrer Konfiguration und wiederholt die Funktionstests des Ausgangsstands. Die Startprotokolle und Testergebnisse werden dem zugehörigen Konfigurations-Commit zugeordnet.
Nach einer Rückkehr zu Tomcat 9.0.x gilt dessen angekündigtes Supportende unverändert. Im Pilotauftrag steht deshalb auch ein Termin für die endgültige APR-Ablösung, nicht nur für den ersten Umstiegsversuch.
Nächster Schritt: einen Listener als Pilot auswählen
Für eine Schulung zur Connector-Konfiguration oder zum Zusammenspiel mit Reverse Proxies findest du ergänzende Angebote in der Kategorie Webserver-Schulungen.
Der APR-Ausstieg gehört vor das Versionsupgrade auf Tomcat 9.1.x, weil sich Fehler im Connector oder in TLS dann noch unter dem bisherigen Tomcat-Zweig untersuchen lassen. Lege als nächsten Schritt für einen betroffenen Listener einen versionierten Pilotauftrag mit der NIO-Zielkonfiguration, den vereinbarten Freigabeschwellen und dem getesteten Rollback an.