SSL La autenticación mutua falla

Question

SSL La autenticación mutua falla

#1 de Tom Leek (5 votos)

4

Cuando intento establecer una autenticación mutua entre el servidor y el cliente, obtengo los siguientes errores.

El tiempo entre el servidor y el cliente es exactamente igual y también los certificados son correctos en el servidor y el cliente. ¿Cuál es la causa de este error y cuáles son las posibles formas de que ocurra este error?

  Thread-10, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01                                  ......
*** Finished
verify_data:  { 130, 243, 38, 76, 253, 223, 88, 181, 223, 28, 110, 123 }
***
[write] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C 82 F3 26 4C   FD DF 58 B5 DF 1C 6E 7B  ......&L..X...n.
Padded plaintext before ENCRYPTION:  len = 48
0000: 14 00 00 0C 82 F3 26 4C   FD DF 58 B5 DF 1C 6E 7B  ......&L..X...n.
0010: F5 44 95 0D 5A D0 8E 6F   40 89 10 2D 00 5F BB CF  [email protected]._..
0020: 30 D1 C6 06 0B 0B 0B 0B   0B 0B 0B 0B 0B 0B 0B 0B  0...............
Thread-8, WRITE: TLSv1 Handshake, length = 48
Thread-8, waiting for close_notify or alert: state 1
[Raw read]: length = 5
0000: 15 03 01 00 02                                     .....
[Raw read]: length = 2
0000: 02 2E                                              ..
Thread-8, READ: TLSv1 Alert, length = 2
Thread-8, RECV TLSv1 ALERT:  fatal, certificate_unknown
%% Invalidated:  [Session-4, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
Thread-8, called closeSocket()
Thread-8, Exception while waiting for close javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
Thread-8, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
Thread-8, called close()
Thread-8, called closeInternal(true)

Tu ayuda es muy apreciada.

authentication tls openssl

pregunta user45475 21.06.2014 - 19:03

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication tls openssl

Explotación de XSS con window.name sin iFrame Semilla aleatoria confiable para RNG

score 5 · Answer 1

Bueno, tú dices:

los certificados son adecuados en el servidor y el cliente

Pero al menos uno de los sistemas no está de acuerdo:

Received fatal alert: certificate_unknown

Este mensaje significa que una parte (no dice si está mostrando los registros del lado del cliente o del servidor) recibió un mensaje de alerta explícito del servidor, de clase "fatal" y valor 46 (0x2E, también conocido como " certificate_unknown "). Como se especifica en el estándar TLS 1.0 :

certificate_unknown
    Some other (unspecified) issue arose in processing the
    certificate, rendering it unacceptable.

El "otro" significa que no es un problema de caducidad o revocación del certificado, o el uso de un algoritmo criptográfico no compatible. Puede haber muchas causas para que un certificado recibido sea "inaceptable", la principal de las cuales es la imposibilidad de construir una cadena válida desde una CA raíz raíz de confianza conocida a priori hasta el propio certificado (normalmente, los sistemas deberían envíe una alerta "unknown_ca" en ese caso, pero muchos no tienen tanta precisión en informar errores con certificados).

Para seguir investigando el problema, debes:

Active el registro completo tanto en el cliente como en el servidor. Muestra los registros del sistema que recibió el mensaje de alerta; debería echar un vistazo a los registros del otro sistema, que envió el mensaje de alerta;
Verifique la configuración de ambos sistemas, en particular, para el que envió el mensaje de alerta (es decir, no el que lanzó la excepción de "alerta fatal recibida", sino el otro) qué ancla de confianza está usando para validar el certificado del par;
Verifique qué cadenas de certificados están enviando realmente los sistemas. Dado que esto ocurre antes de que se active el cifrado, los certificados deberían ser visibles para alguna herramienta de monitoreo de red à la Wireshark . En particular, verifique el orden : en SSL / TLS, el certificado de entidad final es primero, luego la CA que lo emitió, luego la CA que emitió esa CA, y así sucesivamente.

Recuerde también que los certificados de cliente solo tienen sentido como autenticación , no como autorización . Incluso si el cliente envía un certificado que el servidor puede validar con respecto a una raíz confiable, esto solo le dice al servidor quién está en el otro extremo de la línea. Todavía depende del servidor decidir si se debe permitir que ese cliente específico continúe o no. Esto normalmente implica asignar el certificado del cliente a una identidad o un rol, por ejemplo, mediante la extracción de algún campo específico del certificado. Este proceso está completamente fuera del alcance de TLS en sí mismo, pero aún debe ocurrir, por lo que hay algún software y, de manera crucial, algo de configuración en el lado del servidor que probablemente desee verificar.

En la otra dirección (validación del certificado del servidor por el cliente), las reglas se especifican en RFC 2818 , al menos en el contexto de HTTPS: el nombre del servidor deseado (extraído de la URL de destino) debe aparecer en el certificado del servidor. Fuera de HTTPS, depende de cada aplicación cliente decidir si el certificado que obtuvieron del servidor es el correcto, es decir, que el certificado es válido (emitido correctamente por una CA de confianza, etc.) , pero también que el servidor identificado es de hecho con el que el cliente debería estar hablando. Ahí otra vez, la configuración.