solve sec_error_unknown_issuer how failure error curl ssl windows-7 centos

sec_error_unknown_issuer - cURL Error de conexión SSL 35 con error NSS-5961



nss error 12286 (5)

Tengo un servidor remoto de Windows 7 al que solo se puede acceder a través de HTTPS en el puerto 768. El servidor está utilizando un certificado firmado de una CA que figura en el servidor local de CentOS.

Cuando trato de acceder al servidor remoto a través de cURL usando el siguiente comando, se produce un error de la siguiente manera:

[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

(Tenga en cuenta que la dirección IP se ha ocultado por razones de seguridad).

Estoy ejecutando la siguiente versión 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

Vale la pena señalar que esto está funcionando en otros dos servidores remotos que ejecutan Windows XP en lugar de Windows 7.

He intentado forzar a cURL a usar SSLv3 (usando la bandera -3 y la bandera -SSLv3) sin éxito.

Acabo de probar el mismo comando CURL en una Raspberry Pi que ejecuta Raspbian y he podido conectar con éxito. Por lo tanto, creo que puede ser un problema con la versión de cURL en uso en el servidor CentOS. La pi frambuesa está ejecutando la siguiente versión:

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

Este error también se emite cuando el servidor no admite el protocolo ssl. Intente especificar todas las variantes / protocolos en el archivo server.xml.

Esto también sucederá cuando los cifrados entre el cliente y el servidor no se superpongan.

Por ejemplo, el servidor solo acepta el cifrado ECHDE pero el cliente (alguna versión anterior enrollada con nss) no tenía este cifrado.

en este caso, el servidor enviará un TCP RST al cliente para finalizar el intento de conexión SSL cuando detecte que no se superpuso ningún cifrado (el cliente incluirá el cifrado admitido en el ''cliente hola'').

Recientemente me encontré con el mismo problema en una caja de CentOS 6. Resultó que el servidor no se había actualizado durante bastante tiempo y que la versión NSS era demasiado antigua. Se corrigió actualizando tanto el curl como el NSS:

yum update -y nss curl libcurl

curl with NSS lee los certificados de Root CA por defecto en "/etc/pki/tls/certs/ca-bundle.crt" en el formato PEM.

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

Puede especificar otro (su) certificado de CA (o un paquete en la base de datos compartida de NSS ) mediante la opción de --cacert con el archivo PEM que contiene el (los) certificado (s) de CA.

Si no especifica el certificado manualmente con la opción --cacert , NSS intenta seleccionar el correcto de la base de datos de NSS (ubicada en /etc/pki/nssdb ) automáticamente. Puede especificar su apodo por la opción de --cert , esto debería ser suficiente si la clave está incrustada en el certificado; si no, puede especificar el archivo PEM con la clave de certificado usando la --key . Si la clave está protegida por una frase de paso, puede asignarla mediante la opción de enrollamiento --pass para que pueda importar su certificado a la base de datos compartida NSS usando las nss-tools ( yum install nss-tools )

Añadiendo un certificado (línea de comando común)

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

Acerca de TRUSTARGS

Especifique los atributos de confianza para modificar en un certificado existente o para aplicar a un certificado al crearlo o agregarlo a una base de datos.

Hay tres categorías de confianza disponibles para cada certificado, expresadas en este orden: "SSL, correo electrónico, firma de objetos". En cada posición de categoría, utilice cero o más de los siguientes códigos de atributo:

  • p prohibido (explícitamente desconfiado)
  • P compañero de confianza
  • c valida CA
  • T CA confiable para emitir certificados de cliente (implica c)
  • C CA confiable para emitir certificados de servidor (solo SSL) (implica c)
  • u Certificado puede ser utilizado para la autenticación o firma
  • w Enviar advertencia (usar con otros atributos para incluir una advertencia cuando el certificado se usa en ese contexto)

Los códigos de atributo para las categorías están separados por comas, y todo el conjunto de atributos entre comillas. Por ejemplo:

-t "TCu, Cu, Tuw"

Confiar en un certificado de CA raíz para emitir certificados de servidor SSL

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

Importar un certificado de CA intermedio

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

Confiando en un certificado de servidor autofirmado

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

Agregar un certificado personal y una clave privada para la autenticación de cliente SSL

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

Listado de todos los certificados almacenados en NSS DB

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

Listado de detalles de un certificado

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

Borrando un certificado

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

Espero que esto ayude.

Qué esta pasando

Parece que está experimentando un problema de tiempo de espera al conectarse al servidor de Windows 7.

Soluciones posibles

Una posible answer indica que la causa raíz del error 5961 resultó ser un problema de configuración de MTU de red. No está claro si tiene acceso al servidor de Windows 7 o los componentes completos del entorno para identificar la causa exacta del tiempo de espera que está causando que la conexión falle. Revisaría la MTU del servidor de Windows 7 y compararía la configuración de la MTU con la de los otros servidores. Si encuentra que necesita modificar la configuración, puede seguir este procedure .