El navegador rechaza el certificado, pero openssl s_client funciona

Question

El navegador rechaza el certificado, pero openssl s_client funciona

#1 de Steffen Ullrich (2 votos)
#2 de gowenfawr (1 votos)

2

Estoy migrando un sitio web seguro. Instalé el mismo certificado en el nuevo host y apunté el nombre de dominio a la nueva dirección IP (a través de mi archivo de hosts). Sin embargo, cuando intento acceder a ese servidor con un navegador web, aparece un error de verificación del certificado.

Para complicar las cosas, el nuevo host es un servicio que utiliza SNI. Por lo tanto, el mensaje de error que se muestra, que el nombre de dominio no coincide con el certificado, se refiere al certificado anterior SNI. Dudo que SNI esté configurado incorrectamente ya que todas las demás conexiones funcionan.

Para intentar diagnosticar el problema, usé openssl s_client . Para mi consternación, openssl no tiene problemas para conectarse, y no veo errores al emitir una solicitud HTTP:

openssl s_client -connect <ipaddress>:443 -servername <domainname> -showcerts -debug

¿Existen otras herramientas para diagnosticar por qué los navegadores web (que he probado con Chrome, Firefox e IE) rechazan un certificado a pesar de que openssl s_client no no ?

Esta es la salida abreviada de openssl en caso de que pueda detectar el problema:

CONNECTED(00000003)
Certificate chain
 0 s:<subject details>
   i:<issuer details>
 <certificate>
 1 s:<subject details>
   i:<issuer details>
 <certificate>
 2 s:<subject>
   i:<issuer, same as subject>
 <certificate>
---
Server certificate
[certificate information]
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4392 bytes and written 408 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: <session id>
    Session-ID-ctx:
    Master-Key: <master key>
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    <hex output>
    Start Time: 1434382473
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

Actualizar :

Chrome informa que "el certificado del servidor no coincide con la URL", pero como dije, esto se debe al uso de SNI; se queja de que el certificado utilizado para conectarse inicialmente no coincide con la URL. openssl hace bien la cosa de SNI, así que creo que el navegador está rechazando el certificado que acepta openssl .

error de Firefox:

utiliza un certificado de seguridad no válido. El certificado solo es válido para los siguientes nombres: (Código de error: ssl_error_bad_cert_domain)

error de IE:

El certificado de seguridad presentado por este sitio web se emitió para una dirección de sitio web diferente.

RESOLUCIÓN :

Gracias a todos por su ayuda. Los detalles son difíciles de proporcionar en mi caso para una variedad de problemas. Encontré el problema sin embargo. El certificado fue correctamente instalado y aceptado. Lo que no noté es que el sitio realizó una redirección a un dominio para el cual el certificado no se instaló correctamente (www.thedomainname.com). Ojalá me hubiera dado cuenta antes.

tls openssl

pregunta Jacob 15.06.2015 - 17:41

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls openssl

¿Las implicaciones de seguridad de proporcionar subdominios a los usuarios en mi dominio? SSL cert vs autenticación de clave pública

score 2 · Answer 1

... a pesar de que openssl s_client no lo hace?

OpenSSL nunca compara el nombre de host con el certificado, pero los navegadores sí lo hacen.

... openssl s_client -connect: 443 ...

Veo que estás usando s_client con la dirección IP y no con el nombre de host. Ya que afirma que la asignación correcta entre el nombre de una dirección IP en su archivo de hosts con el nombre de host también debería funcionar. Si no es así, es posible que ya haya encontrado la causa del problema, es decir, la asignación incorrecta. Por supuesto, también debe usar el nombre de host dentro del navegador, porque (supongo que) el certificado es para el nombre de host y no para la dirección IP.

Asegúrese también de no haber configurado un proxy con los navegadores porque entonces el proxy resuelve el nombre de host, es decir, no utiliza el archivo hosts en su máquina local.

Si funciona con s_client y el nombre de host pero no con el navegador y el nombre de host, verifique exactamente el nombre común y la sección de nombres alternativos del sujeto del certificado. Debe coincidir con el nombre de host dado en la URL exactamente o según las reglas para la coincidencia de comodines si tiene un certificado de comodines. Un comodín coincide solo con una etiqueta, es decir, *.example.com no coincide con foo.bar.example.com . Y example.com es diferente de www.example.com . Tenga en cuenta también que si tiene nombres alternativos, el nombre común podría ignorarse (dependiendo del navegador).

Si todavía tiene problemas, agregue más detalles, especialmente - La URL exacta que usas. Tenga en cuenta que hay una diferencia si usa www.example.com vs. example.com . - El certificado que ve en el navegador, especialmente el nombre común y la parte del nombre alternativo del sujeto. Y compare esto con el certificado que obtiene de s_client y que considera correcto.

score 1 · Answer 2

No ha proporcionado suficientes detalles para que podamos responder la pregunta.

El texto exacto del error del navegador podría ayudar a indicar lo que el navegador realmente piensa que es el problema
Los detalles del certificado que están actualmente en proceso de redacción podrían arrojar luz
La salida de s_client redactiva no nos dice nada , excepto que se negoció TLS, lo que supimos por el hecho de que su navegador le dio un error de verificación de certificado

Usted cree que SNI es el problema. Su próximo paso debería ser para realizar capturas de paquetes de la conexión a través de openssl y un navegador, y luego compararlos. Deberá prestar mucha atención al valor de la extensión server_name para el client_hello y al certificado que devuelve el servidor . Esos son los dos detalles que le dirán cómo funciona SNI en ambos casos. Si server_name y el certificado del servidor son los mismos para ambos clientes, entonces ignore lo feliz que parece openssl y descubra por qué su navegador no está contento. Si difieren, averigua por qué.

(Tenga en cuenta que no es necesario descifrar la captura del paquete, los detalles que le interesan no están encriptados y son visibles durante la negociación. Wireshark hace que sea muy fácil navegar por la estructura de los paquetes de intercambio y ver qué hay allí).

Simpatizo con que no quieras arrastrar tus dominios aquí, pero limita la cantidad de ayuda que puedes obtener.