NetScaler NSHELP-44985: Absturz bei Backend-TLS 1.3, behoben in 14.1-73.58

In den Release Notes zu NetScaler 14.1-73.58 steht unter den behobenen Fehlern NSHELP-44985 (zusammen mit NSHELP-45088). Laut Citrix kann die packet engine abstürzen, wenn eine Verbindung zum Backend mit TLS 1.3 geschlossen wird. Betroffen sind Backend-SSL-Services und Secure Monitors. Für 13.1 führt Citrix denselben Fehler in den Release Notes zu 13.1-64.39 als Known Issue, mit einem Workaround.

Ich habe versucht, den Absturz an meiner Testinstanz auf einem älteren 14.1-Build auszulösen, und danach auf 73.58 gegengeprüft. Unten stehen die Befehle, mit denen du feststellst, ob deine Konfiguration in Frage kommt und ob es schon Abstürze gab.

Steckbrief

Kennung	NSHELP-44985, NSHELP-45088
Modul	SSL
Fehler	die packet engine (nsppe) kann abstürzen, wenn Backend-SSL-Services oder Secure Monitors mit TLS 1.3 eine Verbindung zum Backend schließen
Behoben in	14.1-73.58 (Release Notes, Abschnitt Fixed issues)
13.1	in 13.1-64.39 als Known issue geführt, mit Workaround
Workaround (Citrix, 13.1)	set ssl profile <backend_prof> -sendCloseNotify NO
Betroffene Builds	nennen die Release Notes nicht

14.1-73.58 ist auch der Build, den Citrix für 14.1 zum Sicherheitsbulletin CTX697305 zum Download anbietet. Wer wegen CVE-2026-120868 aktualisiert, bekommt diesen Fix mit.

Was dahintersteckt

nsppe ist die packet engine des NetScaler, der Prozess, der den gesamten Datenverkehr verarbeitet. Ein Absturz unterbricht deshalb den Verkehr über die Appliance.

Backend-TLS heißt: Der NetScaler baut selbst eine verschlüsselte Verbindung zum Server hinter ihm auf, etwa bei einem Service vom Typ SSL. Ein Secure Monitor ist eine Zustandsprüfung, die den Server ebenfalls über TLS abfragt (-secure YES).

Beim geordneten Schließen einer TLS-Verbindung schickt jede Seite eine Warnmeldung close_notify. Der Workaround von Citrix schaltet genau das ab: Mit -sendCloseNotify NO schickt der NetScaler beim Schließen der Backend-Verbindung kein close_notify mehr. Das legt nahe, dass der Fehler in diesem Schritt liegt. Citrix beschreibt die Ursache in den Release Notes aber nicht genauer.

TLS 1.3 zum Backend ist auf einem Service ohne SSL-Profil nicht der Standard. An meiner Testinstanz steht es erst nach set ssl service … -tls13 ENABLED in der Konfiguration. Auch das mitgelieferte Backend-Profil ns_default_ssl_profile_backend hat dort TLSv1.3: DISABLED. Wer TLS 1.3 zum Backend nutzt, hat es also bewusst eingeschaltet.

NSHELP-44985: wie du prüfst, ob du betroffen bist

NetScaler-CLI, alle Befehle nur lesend. Sie liefen am 13.11.2026 an meiner Testinstanz.

1. Build:

show ns version

Im Zweig 14.1 bringt 73.58 den Fix. Die Ausgabe lautet dort NetScaler NS14.1: Build 73.58.nc, Date: Nov 9 2026, 16:02:20 (64-bit).

2. Backend-Services und Profile mit TLS 1.3:

show ns runningConfig | grep -i "tls13 ENABLED"

Ein Treffer sieht so aus:

set ssl service cvetest_v1 -tls13 ENABLED -dtls1 DISABLED

Die Suche kann auch Zeilen für vServer liefern. Relevant sind set ssl service, set ssl serviceGroup und Profile vom Typ BackEnd. Ein Profil prüfst du einzeln mit:

show ssl profile <name>

Dort stehen TLSv1.3: ENABLED oder DISABLED und die Zeile Send Close-Notify.

3. Secure Monitors:

show ns runningConfig | grep -i "secure YES"

add lb monitor https-ecv-test HTTP-ECV -send "GET /" -recv Online.html -LRTM DISABLED -secure YES -sslProfile ns_default_ssl_profile_backend

Steht in der Zeile ein -sslProfile, zeigt show ssl profile <name>, ob TLS 1.3 in diesem Profil eingeschaltet ist.

4. Wird Backend-TLS 1.3 tatsächlich genutzt?

stat ssl -detail

Im Abschnitt Back End zählt die Zeile TLSv1.3 sessions die Sitzungen zum Backend. Steht dort dauerhaft 0, verhandelt die Appliance zum Backend kein TLS 1.3.

5. Gab es schon Abstürze?

shell ls -lR /var/core
shell grep -i -e nsppe -e pitboss /var/log/messages
shell ps -ax -o pid,lstart,command -c

• Unter /var/core legt der NetScaler bei einem Absturz eine Speicherabbilddatei ab. Für die packet engine heißt sie NSPPE-00-…gz. Das Verzeichnis enthält Unterordner, deshalb -lR.
• pitboss ist der Prozesswächter des NetScaler. Meldungen von ihm und von nsppe in /var/log/messages zeigen, wann es Probleme mit der packet engine gab.
• In der Prozessliste steht bei NSPPE-00 der Startzeitpunkt. Liegt er deutlich nach dem letzten Neustart der Appliance, wurde die packet engine zwischendurch neu gestartet.

Ob ein Core von genau diesem Fehler stammt, lässt sich mit diesen Befehlen nicht sagen. Dafür braucht es eine Analyse durch den Citrix-Support.

Was an meiner Testinstanz passiert ist

Ich habe meine Testinstanz (VPX auf Hyper-V) von 14.1-73.58 auf 14.1-72.61 zurückgesetzt. Die Release Notes zu 72.61 führen NSHELP-44985 nicht. Dann habe ich gut zwei Stunden lang Verkehr über Backend-TLS 1.3 erzeugt:

• zwei Backends: ein IIS und ein Caddy-Reverse-Proxy
• TLS 1.3 einmal direkt am Service eingestellt, einmal über ein eigenes Backend-Profil
• Secure Monitors alle zwei bis drei Sekunden
• Verbindungsabbau von beiden Seiten: durch den NetScaler nach kurzem Server-Timeout (-svrTimeout 2) und durch das Backend, das auf eine ungültige Anfrage mit HTTP 400 antwortet und die Verbindung schließt

Das ergab 17.707 Backend-TLS-1.3-Sitzungen laut stat ssl -detail. Die packet engine lief die ganze Zeit mit derselben Prozess-ID durch, unter /var/core kam nichts hinzu. Den Absturz konnte ich auf meiner Testinstanz nicht auslösen. Die Bedingungen, unter denen er auftritt, sind also enger als „TLS 1.3 zum Backend“. Welche das sind, steht nicht in den Release Notes.

Danach habe ich auf 14.1-73.58 aktualisiert und denselben Aufbau wiederholt: 8.260 Backend-TLS-1.3-Sitzungen, 431 Kontrollabfragen ohne Fehler, kein Neustart der packet engine.

Wie du es löst

Update auf 14.1-73.58. Das ist der Weg für 14.1. Für 14.1 nennt Citrix in den Release Notes zu 73.58 keinen Workaround. In einem HA-Paar beide Knoten.

Workaround für 13.1: Laut Release Notes zu 13.1-64.39 setzt du im Backend-SSL-Profil:

set ssl profile <backend_prof> -sendCloseNotify NO

Dafür muss der Service ein Backend-Profil haben. An meiner Testinstanz (14.1-73.58) ging das auch, ohne die Appliance auf SSL-Profile umzustellen (Default profile: DISABLED in show ssl parameter):

add ssl profile be_tls13 -sslProfileType BackEnd
set ssl profile be_tls13 -sendCloseNotify NO
set ssl service <service> -sslProfile be_tls13

Zwei Dinge sind dabei zu beachten:

• Mit gebundenem Profil gelten die SSL-Einstellungen des Profils, nicht mehr die des Services. show ssl service zeigt danach nur noch den Profilnamen. Protokolle wie TLS 1.3 stellst du dann am Profil ein (-tls13 ENABLED).
• set ssl service <service> -sendCloseNotify NO direkt am Service quittierte die CLI mit gebundenem Profil mit der Warnung Operation not permitted. Use set ssl profile for setting these parameters. Der Weg führt also über das Profil.

Den Workaround habe ich auf 13.1 nicht getestet. Die Befehle oben liefen an der Testinstanz unter 14.1.

TLS 1.3 zum Backend abschalten wäre ein weiterer Behelf. Er kostet die Vorteile von TLS 1.3 auf der Backend-Strecke, und Citrix nennt ihn nicht. Ich würde ihn nur nehmen, wenn weder Update noch Workaround in Frage kommen.

Was du dir merkst

NSHELP-44985 betrifft Appliances, die zum Backend TLS 1.3 sprechen, über Services oder Secure Monitors. 14.1-73.58 behebt den Fehler, für 13.1 nennt Citrix in 64.39 den Workaround -sendCloseNotify NO im Backend-Profil.

Ob deine Konfiguration in Frage kommt, zeigt show ns runningConfig | grep -i "tls13 ENABLED". Ob es schon Abstürze gab, zeigen /var/core und die Startzeit von NSPPE-00.

Quellen

• Release Notes NetScaler 14.1-73.58, Citrix, Fixed issues, NSHELP-44985 und NSHELP-45088
• Release Notes NetScaler 13.1-64.39, Citrix, Known issues, NSHELP-44985 mit Workaround

---

Stand dieses Beitrags: 13.11.2026. Neue Builds oder Hinweise von Citrix trage ich datiert am Kopf des betroffenen Abschnitts nach, statt den Text still zu korrigieren.