solucion - la aplicacion sufrio un error interno al cargar las bibliotecas ssl
Solución de error de handshake de alerta sslv3 cuando se intenta utilizar un certificado de cliente (2)
Estoy intentando conectarme a un servicio que requiere un certificado para autorización. El proceso es que envío el servicio un archivo CSR. El servicio firma el CSR y me envía un certificado que uso para la conexión.
Genere el CSR por la siguiente línea de comando:
openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr
Tomé el contenido del cert.csr y se lo envié. Generan el certificado del cliente y recibí un archivo PEM.
Ahora trato de conectarme usando su archivo de certificado en SSLCERT para curl () y proporcionando la clave privada de cert.key como CURLOPT_SSLKEY - (que obtuve en el paso 1).
Error con:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
¿Qué estoy haciendo mal en este proceso?
Funciona cuando intento con un certificado de prueba recibido que incluye una clave privada del servicio (certificado autofirmado). Pero cuando uso un certificado que generaron de mi CSR y luego uso mi clave privada como clave, se produce un error al fallar el saludo.
Así que sé que no tiene nada que ver con que openssl / curl no admita v3 / TLS, etc. que otros al buscar una solución descubrieron que su problema era.
Esto es lo que corro:
curl -i -v --request POST https://service.com/ --cert clientcert.pem --key private_key.pem --cert-type pem --tlsv1.1 --insecure
* Connected to service.com (1xx.xxx.xxx.xx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS handshake, CERT verify (15):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
* Closing connection 0
Ejecución de las siguientes versiones: curl 7.35.0 (x86_64-pc-linux-gnu) libcurl / 7.35.0 OpenSSL / 1.0.1f zlib / 1.2.8 libidn / 1.28 librtmp / 2.3
No es una respuesta definitiva, pero demasiado para encajar en los comentarios:
Presumo que le dieron un certificado de que tiene un emisor incorrecto (aunque su servidor podría usar un código de alerta más específico para eso) o un tema incorrecto. Sabemos que el certificado coincide con su clave privada, ya que tanto el curl
como el openssl client
emparejaron sin quejarse sobre una discrepancia; pero en realidad no sabemos que coincida con su (s) CA (s) deseado (s) porque su curl usa openssl y el cliente SSL de openssl NO exige que un certificado de cliente configurado coincida con certreq.CAs.
Haga openssl x509 <clientcert.pem -noout -subject -issuer
y lo mismo en el certificado de la prueba P12 que funciona. Haga openssl s_client
(o marque el que hizo) y busque en Acceptable client certificate CA names
; el nombre allí o uno de ellos debe coincidir (¡exactamente!) con el (los) emisor (es) de sus certs. Si no es así, es muy probable que sea su problema y necesita verificar que envió su CSR al lugar correcto y de la manera correcta. Tal vez tienen diferentes regímenes en diferentes regiones, o líneas de negocio, o prueba vs prod, o activos vs pendientes, etc.
Si el emisor de su certificado coincide con las AC deseadas, compare su tema con el trabajo (test-P12): ¿están en un formato similar? ¿hay algún componente en el trabajo que no esté presente en el tuyo? Si lo permiten, intente generar y enviar un nuevo CSR con un nombre exactamente igual que el test-P12, o lo más cerca que pueda, y vea si eso produce un certificado que funciona mejor. (No tiene que generar una nueva clave para hacer esto, pero si lo desea, lleve un registro de los certificados que coincidan con las claves para que no los confunda). Si eso no ayuda, consulte el certificado. extensiones con openssl x509 <cert -noout -text
para cualquier diferencia que pueda relacionarse razonablemente con la autorización del tema, como KeyUsage, ExtendedKeyUsage, quizás Policy, quizás Constraints, quizás incluso algo no estándar.
Si todo lo demás falla, pregúntele a los operadores del servidor qué dicen sus registros sobre el problema, o si tiene acceso, mire los registros usted mismo.
¿Qué clave privada SSL debe enviarse junto con el certificado del cliente?
Ninguno de ellos :)
Una de las cosas más atractivas de los certificados de cliente es que no hace tonterías, como transmitir un secreto (como una contraseña) en el texto sin formato a un servidor (HTTP basic_auth
). La contraseña todavía se usa para desbloquear la clave del certificado del cliente, simplemente no se usa directamente durante el intercambio o para autenticar al cliente.
En cambio, el cliente elige una clave temporal aleatoria para esa sesión. Luego, el cliente firma la clave temporal aleatoria con su certificado y la envía al servidor (algunos renuncian a mano). Si un chico malo intercepta algo, es aleatorio, por lo que no se puede usar en el futuro. Ni siquiera se puede usar para una segunda ejecución del protocolo con el servidor porque el servidor también seleccionará un nuevo valor aleatorio.
Error con: error: 14094410: rutinas SSL: SSL3_READ_BYTES: falla de protocolo de alerta sslv3
Use TLS 1.0 y superior; y use la Indicación del nombre del servidor .
No ha proporcionado ningún código, por lo que no está claro para mí cómo decirle qué hacer. En cambio, aquí está la línea de comando de OpenSSL para probarlo:
openssl s_client -connect www.example.com:443 -tls1 -servername www.example.com /
-cert mycert.pem -key mykey.pem -CAfile <certificate-authority-for-service>.pem
También puede usar -CAfile
para evitar el "error de verificación: num = 20" . Consulte, por ejemplo, "verificar error: num = 20" al conectarse a gateway.sandbox.push.apple.com .