it-swarm.com.de

cURL SSL-Verbindungsfehler 35 mit NSS-Fehler -5961

Ich habe einen Remote-Windows 7-Server, auf den nur über HTTPS an Port 768 zugegriffen werden kann. Der Server verwendet ein signiertes Zertifikat einer Zertifizierungsstelle, die im lokalen CentOS-Server aufgeführt ist.

Wenn ich versuche, über cURL mit dem folgenden Befehl auf den Remote-Server zuzugreifen, wird Folgendes ausgegeben:

[[email protected] certs]# curl -3 -v https://1.1.1.1:768/user/login
* About to connect() to 1.1.1.1 port 768 (#0)
*   Trying 1.1.1.1... connected
* Connected to 1.1.1.1 (1.1.1.1) port 768 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -5961
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

(Beachten Sie, dass die IP-Adresse aus Sicherheitsgründen verborgen wurde.).

Ich verwende die folgende Version von cURL:

curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2

Es ist erwähnenswert, dass dies auf zwei anderen Remote-Servern funktioniert, auf denen Windows XP statt Windows 7 ausgeführt wird.

Ich habe versucht, cURL zu zwingen, SSLv3 (mit dem Flag -3 und dem Flag -SSLv3) ohne Erfolg zu verwenden.


Ich habe gerade den gleichen CURL-Befehl auf einem Raspberry Pi mit Raspbian getestet und konnte mich erfolgreich verbinden. Ich glaube daher, dass es ein Problem mit der auf dem CentOS-Server verwendeten Version von cURL sein kann. Auf dem Raspberry Pi wird folgende Version ausgeführt:

curl 7.26.0 (arm-unknown-linux-gnueabihf) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps Gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
17
euantorano

curl mit NSS liest die Root-CA-Zertifikate standardmäßig aus "/etc/pki/tls/certs/ca-bundle.crt" im PEM-Format.

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt

Sie können ein anderes (Ihr) CA-Zertifikat (oder ein Paket in der NSS Shared DB ) über die Option curl der Option --cacert mit der PEM-Datei angeben, die die CA-Zertifikate enthält.

Wenn Sie das Zertifikat nicht manuell mit der Option --cacert angeben, versucht NSS, das richtige Zertifikat aus der NSS-Datenbank (unter /etc/pki/nssdb) automatisch auszuwählen. Sie können den Kurznamen mit der Option --cert von curl angeben. Dies sollte ausreichen, wenn der Schlüssel in das cert eingebettet ist. Andernfalls können Sie die PEM-Datei mit dem Zertifikatsschlüssel mithilfe von --key angeben. Wenn der Schlüssel durch eine Passphrase geschützt ist, können Sie ihn mit der Option --pass von curl angeben, sodass Sie Ihr Zertifikat mithilfe der nss-tools (yum install nss-tools) in die gemeinsam genutzte NSS-Datenbank importieren können.

Hinzufügen eines Zertifikats (allgemeine Befehlszeile)

certutil -d sql:/etc/pki/nssdb -A -t <TRUSTARGS> -n <certificate nickname> -i <certificate filename>

Über TRUSTARGS

Geben Sie die Vertrauensattribute an, die in einem vorhandenen Zertifikat geändert oder auf ein Zertifikat angewendet werden sollen, wenn Sie es erstellen oder einer Datenbank hinzufügen.

Für jedes Zertifikat stehen drei Vertrauenskategorien zur Verfügung: In dieser Reihenfolge ausgedrückt: "SSL, E-Mail, Objektsignierung". In jedem Kategoriepositionen verwenden null oder mehr der folgenden Attributcodes:

  • p verboten (ausdrücklich misstraut)
  • P Vertrauenswürdiger Peer
  • c Gültige Zertifizierungsstelle
  • T Vertrauenswürdige Zertifizierungsstelle für die Ausstellung von Client-Zertifikaten (impliziert c)
  • C Vertrauenswürdige Zertifizierungsstelle für die Ausstellung von Serverzertifikaten (nur SSL) (impliziert c)
  • u Das Zertifikat kann zur Authentifizierung oder zum Signieren verwendet werden
  • w Warnung senden (in Verbindung mit anderen Attributen eine Warnung einschließen, wenn das Zertifikat in diesem Kontext verwendet wird)

Die Attributcodes für die Kategorien werden durch Kommas getrennt und der gesamte Satz von Attributen in Anführungszeichen. Zum Beispiel:

-t "TCu, Cu, Tuw"

Ein Stamm-CA-Zertifikat für die Ausstellung von SSL-Serverzertifikaten als vertrauen

certutil -d sql:/etc/pki/nssdb -A -t "C,," -n <certificate nickname> -i <certificate filename> 

Zwischenzertifizierungsstellen-Zertifikat importieren

certutil -d sql:/etc/pki/nssdb -A -t ",," -n <certificate nickname> -i <certificate filename>

Einem selbstsignierten Serverzertifikat vertrauen

certutil -d sql:/etc/pki/nssdb -A -t "P,," -n <certificate nickname> -i <certificate filename> 

Hinzufügen eines persönlichen Zertifikats und eines privaten Schlüssels für die SSL-Clientauthentifizierung

pk12util -d sql:/etc/pki/nssdb -i PKCS12_file_with_your_cert.p12

Auflistung aller in NSS DB gespeicherten Zertifikate

certutil -d sql:/etc/pki/nssdb -L

Auflistungsdetails eines Zertifikats

certutil -d sql:/etc/pki/nssdb -L -n <certificate nickname>

Zertifikat löschen

certutil -d sql:/etc/pki/nssdb -D -n <certificate nickname>

Hoffe das hilft.

16
vzamanillo

Ich habe vor kurzem dieselbe Ausgabe in einer CentOS 6-Box gefunden. Es stellte sich heraus, dass der Server längere Zeit nicht aktualisiert wurde und die NSS-Version zu alt war. Fixiert durch Aktualisieren von curl und NSS:

yum update -y nss curl libcurl
9
qingbo

Dieser Fehler wird auch ausgegeben, wenn das SSL-Protokoll nicht vom Server unterstützt wird. Versuchen Sie, alle Varianten/Protokolle in der Datei server.xml anzugeben.

1
user4737628

Was ist los

Es hört sich an, als ob bei der Verbindung zum Windows 7-Server ein Timeout-Problem auftritt.

Mögliche Lösungen

Ein mögliches answer weist darauf hin, dass der Grund für den Fehler 5961 ein Netzwerk-MTU-Einstellungsproblem war. Es ist nicht klar, ob Sie Zugriff auf den Windows 7-Server oder die vollständigen Komponenten der Umgebung haben, um die genaue Ursache des Zeitlimits zu ermitteln, durch das die Verbindung fehlschlägt. Ich würde die MTU des Windows 7 Servers überprüfen und die MTU-Einstellung mit der der anderen Server vergleichen. Wenn Sie feststellen, dass Sie die Einstellungen ändern müssen, können Sie dieser Prozedur folgen. 

1
Tommie C.

Dies geschieht auch, wenn die Chiffren zwischen Client und Server nicht überlappen.

Zum Beispiel akzeptieren Server nur ECHDE-Chiffrierung, aber der Client (einige ältere Versionen, die mit nss erstellt wurden) hatte diese Chiffre nicht.

in diesem Fall sendet der Server ein TCP -RST an den Client, um den SSL-Verbindungsversuch zu beenden, wenn festgestellt wurde, dass sich keine Chiffre überlappt (der Client unterstützt die unterstützte Chiffre in 'Client Hello'). 

0
hgfeaon