Verbindung abgelehnt heißt falscher Port, nicht Zertifikat

Ein Skript fragt die NetScaler über ihre REST-Schnittstelle NITRO ab, und statt einer Antwort kommt „Verbindung abgelehnt“, englisch „Connection refused“. Weil am Management gerade erst ein neues Zertifikat eingespielt wurde, liegt der Verdacht beim Zertifikat. Diese Meldung entsteht aber eine Schicht tiefer: Sie kommt aus TCP, bevor überhaupt ein Zertifikat übertragen wurde. Dieser Beitrag trennt die Fehlerbilder Ablehnung, Zeitüberschreitung, abgebrochener TLS-Handshake und Zertifikatsfehler und zeigt für jedes einen Prüfbefehl, gemessen an meiner Testinstanz.

Vier Fehlerbilder aus zwei Schichten

Eine HTTPS-Verbindung entsteht in zwei Schritten. Zuerst baut der Client eine TCP-Verbindung zum Port auf. Erst wenn sie steht, beginnt der TLS-Handshake, und erst darin schickt der Server sein Zertifikat. Jede Meldung lässt sich genau einem dieser Schritte zuordnen.

Meldung	Schicht	Was passiert ist	Dauer auf meiner Testinstanz
Verbindung abgelehnt, ConnectionRefused, curl-Fehler 7	TCP	Das Ziel antwortet mit einem Reset: Auf diesem Port nimmt kein Dienst an	rund 2 Sekunden
Zeitüberschreitung, curl-Fehler 28	TCP	Es kommt gar keine Antwort: Filter, Route oder Gerät nicht erreichbar	so lange wie die eingestellte Wartezeit
Vom Remotehost geschlossen, „SSL connection could not be established“	TLS	Der Port ist offen, spricht aber kein TLS, etwa HTTPS auf Port 80	sofort
Zertifikat ungültig, SEC_E_WRONG_PRINCIPAL, verify error	TLS	Die Verbindung steht, die Prüfung des Zertifikats schlägt fehl	sofort

Ein Zertifikatsfehler setzt also eine bestehende TCP-Verbindung voraus. Bei „Verbindung abgelehnt“ ist diese Verbindung nie zustande gekommen, das Zertifikat war noch nicht beteiligt.

Warum „Verbindung abgelehnt“ beim NetScaler fast immer der Port ist

Der NetScaler lehnt eine TCP-Verbindung ab, wenn an der angesprochenen Adresse auf diesem Port nichts angenommen wird. Für das Management heißt das: Das Skript spricht einen Port an, auf dem die NSIP, die Verwaltungsadresse der NetScaler, keinen Zugang anbietet.

In Produktivumgebungen ist der Verwaltungszugang häufig nur über HTTPS auf Port 443 erlaubt. Auf der NSIP stellt das zum Beispiel set ns ip <NSIP> -gui SECUREONLY ein. An meiner Testinstanz hat die NSIP danach Verbindungen auf Port 80 sofort abgelehnt, HTTPS lief weiter.

Ein Skript, das http:// verwendet oder Port 80 fest eingetragen hat, bekommt dort die Ablehnung, während Browser und Konsole über HTTPS problemlos arbeiten. Im Normalbetrieb beantwortet meine Testinstanz beide Ports. Die Beispiele unten zeigen die Ablehnung deshalb an Port 81, auf dem kein Dienst läuft.

Zwei Varianten sehen zunächst wie ein TLS-Problem aus und sind doch eine Frage des Ports:

• HTTPS auf einen HTTP-Port. Der Port ist offen, der Client schickt einen TLS-Handshake, der Dienst dahinter versteht ihn nicht und schließt die Verbindung. PowerShell 7 meldet dann „The SSL connection could not be established“. Die Ursache ist dieselbe wie bei der Ablehnung: der falsche Port.
• HTTP auf Port 443. Auch hier wird die Verbindung zurückgesetzt, nachdem die Anfrage gesendet wurde.

Wie du die Schicht bestimmst

TCP: abgelehnt oder keine Antwort

Test-NetConnection beantwortet die Frage, ob eine TCP-Verbindung zustande kommt:

Test-NetConnection -ComputerName netscaler.example.com -Port 443

Für die Unterscheidung zwischen Ablehnung und Zeitüberschreitung reicht das Ergebnis allerdings nicht. In beiden Fällen steht TcpTestSucceeded : False mit derselben Warnung TCP connect to (… : 81) failed. Der einzige Unterschied auf meiner Testinstanz war die Laufzeit: gut 2 Sekunden bei der Ablehnung, knapp 35 Sekunden bei einem Ziel ohne Antwort, weil Test-NetConnection danach noch einen Ping versucht. Dass auch die Ablehnung rund 2 Sekunden dauert, obwohl der Reset sofort zurückkommt, liegt an Windows: Es wiederholt den Verbindungsaufbau nach einem Reset mehrmals, bevor es aufgibt.

Eindeutig wird es mit dem Fehlercode des Sockets. Diese kleine Funktion liefert ihn direkt und läuft unverändert in Windows PowerShell 5.1 und PowerShell 7:

function Test-TcpPort {
    param([string]$Ziel, [int]$Port, [int]$TimeoutMs = 5000)
    $tcp = New-Object System.Net.Sockets.TcpClient
    try {
        if ($tcp.ConnectAsync($Ziel, $Port).Wait($TimeoutMs)) { 'offen' }
        else { 'Timeout: keine Antwort' }
    }
    catch {
        $e = $_.Exception
        while ($e.InnerException) { $e = $e.InnerException }
        if ($e -is [System.Net.Sockets.SocketException]) { [string]$e.SocketErrorCode } else { $e.Message }
    }
    finally { $tcp.Dispose() }
}

foreach ($port in 443, 80, 81) {
    'netscaler.example.com:{0,-4} {1}' -f $port, (Test-TcpPort -Ziel 'netscaler.example.com' -Port $port)
}
'192.0.2.10:443               {0}' -f (Test-TcpPort -Ziel '192.0.2.10' -Port 443)

Ausgabe gegen meine Testinstanz, die Adresse 192.0.2.10 stammt aus einem Dokumentationsbereich und antwortet nie:

netscaler.example.com:443  offen
netscaler.example.com:80   offen
netscaler.example.com:81   ConnectionRefused
192.0.2.10:443               Timeout: keine Antwort

ConnectionRefused zeigt auf den Port. Timeout zeigt auf den Weg dorthin: Firewall, Routing oder ein Gerät, das nicht antwortet.

Auch der NetScaler selbst kann einen Timeout erzeugen. Eine ACL mit DENY verwirft die Pakete, statt die Verbindung abzulehnen. An meiner Testinstanz lief HTTP auf Port 80 hinter einer solchen Regel in den Timeout, HTTPS vom erlaubten Rechner antwortete weiter. Wie diese ACLs für das Management aussehen, steht im Beitrag NetScaler und PHP CVE-2026-109618: Management-Zugriff jetzt absichern.

TLS: curl.exe zeigt, wie weit die Verbindung kam

curl ist seit Windows 10 mitgeliefert. In Windows PowerShell 5.1 ist curl allerdings ein Alias für Invoke-WebRequest, deshalb dort immer curl.exe schreiben. Mit -v zeigt curl jeden Schritt:

curl.exe -v https://netscaler.example.com:81/

*   Trying 192.0.2.20:81...
* connect to 192.0.2.20 port 81 from 0.0.0.0 port 60662 failed: Connection refused
curl: (7) Failed to connect to netscaler.example.com:81 after 2009 ms: Could not connect to server

TLS kommt in der Ausgabe nicht vor, die Verbindung kam nicht zustande. Anders sieht es aus, wenn die NSIP per IP-Adresse statt per Namen angesprochen wird:

curl.exe -v https://192.0.2.20/nitro/v1/config/nsversion

* schannel: using IP address, SNI is not supported by OS.
* schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) - Der Zielprinzipalname ist falsch.
curl: (60) schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) - Der Zielprinzipalname ist falsch.

Hier stand die TCP-Verbindung, das Zertifikat wurde geprüft und passt nicht zur IP-Adresse. Das ist ein echter Zertifikatsfehler. Und HTTPS auf Port 80 endet so:

* Recv failure: Connection was reset
* schannel: failed to receive handshake, SSL/TLS connection failed

TLS im Detail: openssl s_client

openssl gehört nicht zum Lieferumfang von Windows, wird aber zum Beispiel mit Git für Windows installiert, dort ohne Eintrag im Suchpfad. s_client zeigt das Zertifikat und das Ergebnis der Prüfung. Zwei Schalter sind dabei wichtig: -verify_hostname prüft den Namen, und -verify_return_error bricht bei einem Prüffehler ab. Ohne ihn meldet s_client den Fehler, baut die Verbindung aber trotzdem auf und schreibt CONNECTION ESTABLISHED.

$openssl = 'C:\Program Files\Git\usr\bin\openssl.exe'
$name    = 'netscaler.example.com'
'' | & $openssl s_client -connect "${name}:443" -servername $name -verify_hostname $name -verify_return_error -brief

Bei einer vollständigen Kette und passendem Namen endet die Ausgabe mit Verification: OK. Windows PowerShell 5.1 stellt die Zeilen, die openssl auf den Fehlerkanal schreibt, zusätzlich als rote NativeCommandError dar; der Inhalt ist derselbe. Gegen die IP-Adresse statt den Namen kommt verify error:num=62:hostname mismatch. Ein zweiter Befund, den diese Prüfung sichtbar macht (gekürzt):

verify error:num=20:unable to get local issuer certificate
SSL routines:tls_post_process_server_certificate:certificate verify failed

Das heißt: Der Server schickt nur sein eigenes Zertifikat, nicht das Intermediate der Zertifizierungsstelle. Warum der Client das Intermediate braucht, steht im Beitrag Cross-Zertifikate in der Zertifikatskette. Auf meiner Testinstanz war genau das der Fall. Windows hat die Verbindung trotzdem aufgebaut, curl.exe und PowerShell meldeten keinen Fehler, openssl dagegen schon. Die Lösung liegt auf dem NetScaler: das Intermediate installieren und mit dem Serverzertifikat verknüpfen, beschrieben in der Citrix-Dokumentation Install, link, and update certificates.

PowerShell: die innerste Ausnahme lesen

Invoke-RestMethod verpackt den eigentlichen Fehler in mehrere Ausnahmen. Die äußere Meldung ist oft wenig aussagekräftig, die innerste benennt die Schicht:

function Get-InnersteMeldung {
    param($Fehler)
    $e = $Fehler.Exception
    while ($e.InnerException) { $e = $e.InnerException }
    '{0}: {1}' -f $e.GetType().Name, $e.Message
}

$ziele = 'https://netscaler.example.com:81/nitro/v1/config/nsversion',  # kein Dienst
         'https://netscaler.example.com:80/nitro/v1/config/nsversion',  # TLS auf HTTP-Port
         'https://192.0.2.20/nitro/v1/config/nsversion'                   # NSIP statt Name

foreach ($uri in $ziele) {
    try   { $null = Invoke-RestMethod -Uri $uri -TimeoutSec 10 }
    catch { Get-InnersteMeldung $_ }
}

Ausgabe in PowerShell 7:

SocketException: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
SocketException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen.
AuthenticationException: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch

Windows PowerShell 5.1 liefert dieselben drei Typen; beim Zertifikat fehlt dort nur der Zusatz RemoteCertificateNameMismatch. Eine SocketException zeigt auf Port, Protokoll oder Netzwerkweg, eine AuthenticationException auf das Zertifikat.

Wie du es löst

Befund	Lösung
ConnectionRefused	Port und Protokoll prüfen: https:// und Port 443, oder der Port, den die Umgebung für das Management vorsieht
Verbindung nach dem Senden zurückgesetzt	Protokoll passt nicht zum Port: HTTPS gehört auf 443, nicht auf 80
Timeout	Netzwerkweg prüfen: Firewall, ACLs auf dem NetScaler, Routing, Erreichbarkeit der NSIP aus diesem Netz
Name passt nicht zum Zertifikat	Über den vollständigen Namen verbinden, der im Zertifikat steht
Intermediate fehlt	Intermediate auf dem NetScaler installieren und verknüpfen

Für den Namen hilft die Rückwärtsauflösung der NSIP. Liefert sie mehrere Namen, ist der richtige der, mit dem die Zertifikatsprüfung durchläuft:

$nsip  = '192.0.2.20'
$namen = (Resolve-DnsName -Name $nsip -Type PTR).NameHost

foreach ($name in $namen) {
    try {
        $null = Invoke-WebRequest -UseBasicParsing -Uri "https://$name/nitro/v1/config/nsversion" -TimeoutSec 10
        '{0}: TLS in Ordnung' -f $name
    }
    catch {
        if ($_.Exception.Response) { '{0}: TLS in Ordnung (HTTP {1})' -f $name, [int]$_.Exception.Response.StatusCode }
        else {
            $e = $_.Exception; while ($e.InnerException) { $e = $e.InnerException }
            '{0}: {1}' -f $name, $e.Message
        }
    }
}

Meine Testinstanz hat zwei Rückwärtseinträge, nur einer steht im Zertifikat:

netscaler.example.com: TLS in Ordnung (HTTP 401)
netscaler.example.local: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch

HTTP 401 ist hier das gewünschte Ergebnis: TLS steht, und NITRO verlangt eine Anmeldung.

Bei Zertifikatsfehlern bleibt die Prüfung eingeschaltet. Eine abgeschaltete Prüfung beseitigt die Meldung, nicht die Ursache, und im Skript bleibt sie meist dauerhaft stehen. Der Weg über den FQDN mit regulärer Prüfung funktioniert genauso und ist sicher. So arbeitet auch das Prüfskript im Beitrag NetScaler CVE-2026-88771 bis 88778: Betroffenheit prüfen, und es ist der empfohlene Weg, wenn der Zugriff über den ADM-Proxy nicht in Frage kommt.

Was du dir merkst

Erst die Schicht bestimmen, dann die Ursache suchen.

ConnectionRefused und eine zurückgesetzte Verbindung betreffen Port und Protokoll. Ein Timeout betrifft den Netzwerkweg. Nur eine AuthenticationException oder ein verify error betrifft das Zertifikat, und die Lösung dafür ist der richtige Name oder die vollständige Kette, nicht das Abschalten der Prüfung.

Quellen

• Test-NetConnection, Microsoft-Dokumentation
• openssl-s_client, OpenSSL-Dokumentation: -verify_hostname, -verify_return_error
• SSL certificate verification, curl-Dokumentation
• Install, link, and update certificates, NetScaler-Dokumentation: Intermediate verknüpfen