TLSv1: Motivo por el cual el cliente no envía el certificado del cliente

Question

TLSv1: Motivo por el cual el cliente no envía el certificado del cliente

#1 de Thomas Pornin (1 votos)

1

Nuestra instalación de BizTalk consta de dos nodos de carga equilibrada B1 ( 10.137.10.1 ) y B2 ( 10.137.10.2 ) que procesan y enrutan los mensajes SOAP entrantes.

El procesamiento no es más que:

enviar el mensaje de solicitud SOAP a un servicio web externo ( WS ) (fuera de nuestro control),
espera la respuesta
y enruta la respuesta de vuelta al llamante original.

Al frente del servicio web hay un proxy inverso nginx ( RP , WS / RP: 145.21.186.179 ).

La conexión entre los nodos de BizTalk (B1, B2) y el WS (o en realidad RP) será HTTPS (TLSv1) con autenticación mutua / bidireccional.

B1 funciona

Todo va bien cuando los mensajes son enrutados por el nodo B1. Se realiza un protocolo de enlace TLSv1 adecuado y, finalmente, se intercambian los datos de la aplicación (el mensaje de solicitud y respuesta). Vea la captura de pantalla a continuación.

Tiburón de alambre en el nodo B1. (todo va bien)

RP solicita el certificado en el paquete 63. (a la marca de 459 segundos)
B1 responde en el paquete 69. (También a 459 segundos).

B2sequedaensilencio

LosmensajesprocesadosporelnodoB2fallan.NovemosuncorrectoapretóndemanosTLSv1.Unavezqueelservidorsolicitaelcertificadodelcliente,sesilencia.

TiburóndealambreenelnodoB2.(elclientesequedaensilenciodespuésdelasolicituddecertificadodelservidor)

ElRPsolicitaelcertificadoenelpaquete27.(enlamarcade96segundos)
B2noresponde.
RPagotaeltiempo(?)ycierralaconexiónenpaket31.(enlamarcade155segundos)

Pregunta

¿Podríanustedesyniñaspensarenunarazónporlaqueestopodríasuceder?VerificamoslaconfiguraciónenB1yB2ynovemosdesviaciones.

TambiénlapruebadelaconexiónconOpenSSLdesdeelnodoB2funcionaperfectamente.Elcomandofueeste:

openssl.exes_client-connectRPHOSTNAMEHERE:443-state-tls1-debug-certclient_ssl.pem-keyclient_ssl.pem

¿PodríaserestounproblemaconSChannel?¿Cuálseríaunarazónparanoenviarelcertificadodelclienteasolicituddelservidor?

Tambiénlosregistrosdeeventosnonosdanningunapista.

Actualización#1compartiendoretransmisionesespuriasdelacapturadepantallaB2

authentication tls certificates openssl

pregunta Martijn B 14.06.2016 - 16:07

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication tls certificates openssl

Error al ejecutar NodeFuzz [cerrado] Autentificación basada en clave pública de servidor multiusuario

score 1 · Accepted Answer

Desde la traza de Wireshark en B2, vemos que el cliente simplemente no responde en absoluto; después de un minuto, el servidor se impacienta y cierra la conexión.

Probablemente, este no sea un problema de la disponibilidad de certificados en B2: si SChannel simplemente creyera que no tenía un certificado apropiado, entonces enviaría un mensaje vacío de Certificate handshake. En ese punto, B2 sabe perfectamente que es su turno de hablar, por lo que si no lo hace, entonces eso significa que está ocupado en otro lugar.

Puede ocurrir uno de los siguientes:

Hay varios certificados coincidentes en B2, y el software en B2 se considera "interactivo"; por lo tanto, muestra una ventana emergente de selección de certificado y espera a que el usuario elija el certificado. He visto casos en los que el software que se ejecuta como una cuenta de servicio "muestra" una ventana emergente en un escritorio oculto (no el del usuario que ha iniciado sesión actualmente).
La clave privada está protegida por acceso. Es posible habilitar el control de acceso basado en contraseña en claves privadas en Windows CryptoAPI (básicamente, la clave privada se almacena con cifrado basado en contraseña). En ese caso, cualquier acceso activará una ventana emergente solicitando la entrada de la contraseña. Para sistemas no interactivos, esto no irá bien ... (ver más arriba). Tenga en cuenta que la clave privada es necesaria para el mensaje CertificateVerify del cliente, después de los mensajes Certificate y ClientKeyExchange , pero como estos tres mensajes son todos "apretón de manos", SChannel los agrupará en un solo registro, por lo que esa situación sería normal no ver los mensajes Certificate y ClientKeyExchange .
El cliente está ocupado validando el certificado del servidor. Dicha validación puede implicar hablar con muchos otros sistemas, para recopilar CA intermedias adicionales y obtener respuestas CRL u OCSP. Estas son solicitudes salientes , por lo que su instalación de red podría bloquearlas. Intente realizar un seguimiento de Wireshark que incluya todo el tráfico, no solo la conexión TCP / SSL específica; en particular, se deben investigar las solicitudes de DNS que no obtienen respuesta.

Una prueba rápida sería intentar conectarse desde B2 al servidor de destino WS con Internet Explorer. IE utilizará SChannel (a diferencia de openssl.exe). Ejecute IE con una cuenta que tenga acceso al certificado y la clave del cliente esperado. Esto le mostrará cualquier característica "interactiva".