erreur de connexion SSL cURL 35 avec l'erreur NSS -5961
J'ai un serveur Windows 7 distant accessible uniquement via HTTPS sur le port 768. Le serveur utilise un certificat signé par une autorité de certification répertoriée dans le serveur CentOS local.
Chaque fois que j'essaie d'accéder au serveur distant via cURL à l'aide de la commande suivante, le message d'erreur suivant s'affiche:
[usr@serv 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
(Notez que l'adresse IP a été masquée pour des raisons de sécurité).
J'utilise la version suivante de 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
Il est à noter que cela fonctionne sur deux autres serveurs distants qui exécutent tous deux Windows XP plutôt que Windows 7.
J'ai essayé de forcer cURL à utiliser SSLv3 (à l'aide de l'indicateur -3 et de l'indicateur -SSLv3) sans succès.
Je viens de tester la même commande CURL sur un Raspberry Pi qui exécute Raspbian et j'ai réussi à me connecter. Je pense donc que cela pourrait être un problème avec la version de cURL utilisée sur le serveur CentOS. Le Raspberry Pi exécute la version suivante:
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
curl avec NSS lit les certificats de l'autorité de certification racine par défaut à partir de "/etc/pki/tls/certs/ca-bundle.crt" au format PEM.
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
Vous pouvez spécifier un autre (votre) certificat d'autorité de certification (ou un ensemble sur la NSS Shared DB ) en sélectionnant l'option --cacert de curl avec le fichier PEM contenant le ou les certificats d'autorité de certification.
Si vous ne spécifiez pas le certificat manuellement avec l'option --cacert, NSS essaie de sélectionner automatiquement celui qui convient dans la base de données NSS (située à /etc/pki/nssdb). Vous pouvez spécifier son surnom à l'aide de l'option --cert de curl. Cela devrait suffire si la clé est incorporée dans le certificat. Sinon, vous pouvez spécifier le fichier PEM avec la clé de certificat à l'aide du --key. Si la clé est protégée par une phrase secrète, vous pouvez l'indiquer avec l'option --pass de curl afin de pouvoir importer votre certificat dans la base de données partagée NSS à l'aide de nss-tools (yum install nss-tools).
Ajout d'un certificat (ligne de commande commune)
certutil -d sql:/etc/pki/nssdb -A -t <TRUSTARGS> -n <certificate nickname> -i <certificate filename>
À propos de TRUSTARGS
Spécifiez les attributs de confiance à modifier dans un certificat existant ou à appliquer à un certificat lors de sa création ou de son ajout à une base de données.
Il existe trois catégories de confiance disponibles pour chaque certificat, exprimé dans cet ordre: "SSL, email, signature d'objet". Dans chaque position de la catégorie utilisez zéro ou plus des codes d'attribut suivants:
- p interdit (explicitement méfiant)
- P peer de confiance
- c CA valide
- T Une AC de confiance émet des certificats clients (implique c)
- C Une autorité de certification de confiance émet des certificats de serveur (SSL uniquement) (implique c)
- u Le certificat peut être utilisé pour l’authentification ou la signature
- w Envoyer un avertissement (à utiliser avec d'autres attributs pour inclure un avertissement lorsque le certificat est utilisé dans ce contexte)
Les codes d'attribut pour les catégories sont séparés par des virgules et l'ensemble des attributs entre guillemets. Par exemple:
-t "TCu, Cu, Tuw"
Approbation d'un certificat d'autorité de certification racine pour l'émission de certificats de serveur SSL
certutil -d sql:/etc/pki/nssdb -A -t "C,," -n <certificate nickname> -i <certificate filename>
Importation d'un certificat de CA intermédiaire
certutil -d sql:/etc/pki/nssdb -A -t ",," -n <certificate nickname> -i <certificate filename>
Faire confiance à un certificat de serveur auto-signé
certutil -d sql:/etc/pki/nssdb -A -t "P,," -n <certificate nickname> -i <certificate filename>
Ajout d'un certificat personnel et d'une clé privée pour l'authentification du client SSL
pk12util -d sql:/etc/pki/nssdb -i PKCS12_file_with_your_cert.p12
Liste de tous les certificats stockés dans la base de données NSS
certutil -d sql:/etc/pki/nssdb -L
Détails de la liste d'un certificat
certutil -d sql:/etc/pki/nssdb -L -n <certificate nickname>
Suppression d'un certificat
certutil -d sql:/etc/pki/nssdb -D -n <certificate nickname>
J'espère que cela t'aides.
J'ai récemment rencontré le même problème dans une boîte CentOS 6. Il s'est avéré que le serveur n'avait pas été mis à jour depuis un certain temps et que la version NSS était trop ancienne. Fixé en mettant à jour Curl et NSS:
yum update -y nss curl libcurl
Cette erreur est également générée lorsque le serveur ne prend pas en charge le protocole SSL. Essayez de spécifier toutes les variantes/protocoles dans le fichier server.xml.
Que ce passe-t-il
Il semble que vous rencontriez un problème de délai d'attente lors de la connexion au serveur Windows 7.
Solutions possibles
Une possibilité réponse indique que la cause première de l'erreur 5961 s'est révélée être un problème de configuration du MTU du réseau. Il n'est pas clair si vous avez accès au serveur Windows 7 ou aux composants complets de l'environnement pour identifier la cause exacte du délai d'expiration à l'origine de l'échec de la connexion. Je voudrais vérifier le MTU de Windows 7 Server et comparer le paramètre MTU avec celui des autres serveurs. Si vous trouvez que vous devez modifier les paramètres, vous pouvez suivre cette procédure .
Cela se produira également lorsque les chiffrements entre le client et le serveur ne se chevauchent pas.
Par exemple, le serveur accepte uniquement le chiffrement ECHDE mais le client (une ancienne version curl construite avec nss) ne possédait pas ce chiffrement.
dans ce cas, le serveur enverra un RST TCP au client afin de mettre fin à la tentative de connexion SSL s'il a constaté qu'aucun chiffrement ne se chevauchait (le client inclura le chiffrement pris en charge dans le message "bonjour client").