☰

CentOS PHP cURL NSS-Fehler 5938

tag-icon • tag-icon centos ssl curl nss
CentOS PHP cURL NSS-Fehler 5938

Ich habe ein seltsames Problem mit cURL und PHP auf einigen CentOS-Boxen.

Lokal verwende ich CentOS 6.3. Remote ist CentOS 5.9

Lokal empfängt die Box eine Anfrage, sendet per SCP eine Datei an den Remote-Server und führt dann eine cURL-Anfrage über PHP an den Remote-Server aus, um einige Informationen zu senden. Die Anfrage schlägt immer beim ersten Versuch des Tages fehl. Nachfolgende Anfragen funktionieren einwandfrei. Remote verfügt über ein gültiges SSL-Zertifikat – das Deaktivieren der Zertifikats- und Hostüberprüfung behebt das Problem jedoch nicht.

Die Protokollierung war nicht sehr hilfreich. Wenn man die Ausführlichkeit auf 11 stellt, sind die aussagekräftigsten Einträge folgende:

* About to connect() to www.example.com port 443 (#0)
*   Trying 203.0.113.10... * connected
* Connected to www.example.com (203.0.113.10) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -5938
* Closing connection #0
* SSL connect error

Auch das Googeln des Fehlers hilft nicht viel. Es sieht so aus, als hätte Twitter ein ähnliches Problem (https://dev.twitter.com/discussions/1549), das sie anscheinend behoben haben, aber nicht näher darauf eingegangen sind, wie es behoben wurde.

Ich bin für alle Ideen dankbar, wo man suchen bzw. was man tun kann, um das Problem einzudämmen.

Antwort1

Dies ist ein allgemeines Problem für mit NSS kompiliertes Curl (nur ohne NSS kompilierte Curl-Pakete für Redhat-Linux, Debian und Suse). Sie müssen Curl aus Quellen ohne NSS-Bibliothek kompilieren.

also, ich habe keine Lösung, wie https-Verbindungen mit nss-curl funktionieren.

curl --version curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.14.3.0zlib/1.2.7 libidn/1.26 libssh2/1.4.3 Protokolle: dict Datei ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Funktionen: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

curl --version curl 7.25.0 (x86_64-suse-linux-gnu) libcurl/7.25.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.0 Protokolle: dict Datei ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Funktionen: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

Antwort2

Ich habe einen ähnlichen „NSS-Fehler -5938“ festgestellt, als ich ein veraltetes CentOS 6.x-System zur Verbindung mit einem eingebetteten Gerät verwendete, das TLS 1.0 nicht mehr akzeptierte und nur TLS 1.1 und höher zuließ. Die Lösung für mich bestand darin, Folgendes zu tun yum update. Ich habe gesehen, dass diese Updates aufgetreten sind:

---> Package curl.x86_64 0:7.19.7-46.el6 will be updated
---> Package curl.x86_64 0:7.19.7-52.el6 will be an update
...
---> Package nss.x86_64 0:3.21.0-0.3.el6_7 will be updated
---> Package nss.x86_64 0:3.21.3-2.el6_8 will be an update

Ich denke, dass diese Änderung möglicherweise geholfen hat:

$ rpm -q --changelog curl
[...]
* Mon Jan 11 2016 Kamil Dudka <[email protected]> 7.19.7-50
- use the default min/max TLS version provided by NSS (#1289205)

Antwort3

Die NSS-Fehlermeldung 5938 bedeutet normalerweise, dass der Server Ihre Verbindung unterbrochen hat. Sie sollten die serverseitigen Protokolle des Curl-Ziels überprüfen, um herauszufinden, warum Ihre Verbindung unterbrochen wurde.

Es könnte etwas so Einfaches sein wie „Es konnte kein Reverse-DNS-Hostname für X ermittelt werden“.

verwandte Informationen