El protocolo de enlace SSL falla con un certificado de cadena verisign que contiene dos certificados firmados por CA y un certificado autofirmado

Question

Tengo un problema e intento depurarlo. Compramos un certificado de Verisign. Cuando usamos:

openssl> s_client -connect myweb.com:443 -showcerts 

SSL Handshake nunca se completa y al final vemos error:

Verify return code: 19 (self signed certificate in certificate chain) 

Se muestra 3 ---BEGIN/END CERTIFICATE--- etiquetas. Dos certificados en cadena están firmados por Verisign, pero uno está auto firmado.

1. Si alguien puede explicar cómo aparece este certificado autofirmado en un certificado firmado CA?

2. ¿Este error es 19 (self signed certificate in certificate chain) benigno? Si no, ¿qué podría estar causando eso?

3. El cliente tiene el certificado de CA en la tienda de confianza, pero no hay nada para el certificado autofirmado. ¿Crees que eso podría estar causando problemas? En caso afirmativo, ¿cómo puedo:

   1. ¿Cómo puedo deshacerme del certificado autofirmado del certificado de cadena dejando solo 2 certificados CA firmados en cadena?
   2. ¿Agregar este certificado autofirmado en la tienda de confianza del cliente?

Answer 1

Suena como el certificado intermedio no se encuentra. A partir de abril de 2006, todos los certificados SSL emitidos por VeriSign requieren la instalación de un certificado de CA intermedio.

Puede ser que no tenga toda la cadena de certificados cargada en su servidor. Algunas empresas no permiten que sus computadoras descarguen certificados adicionales, lo que provoca que no se complete el protocolo de enlace SSL.

Aquí hay alguna información sobre las cadenas intermedias:
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD146

Intermediate CA Certificates

Answer 2

certificados raíz emitidos por las CA son sólo certificados con firma (que pueden a su vez ser utilizados para emitir certificados de CA intermedios) No tienen mucho especial acerca de ellos, excepto que han logrado ser importados por defecto en muchos navegadores o anclajes de confianza del sistema operativo.

Mientras que los navegadores y algunas herramientas están configurados para buscar los certificados de CA confiables (algunos de los cuales pueden estar auto-firmados) en la ubicación de forma predeterminada, hasta donde yo sé, el comando openssl no lo está.

Como tal, cualquier servidor que presente la cadena completa de certificados, desde su certificado de entidad final (el certificado del servidor) hasta el certificado de CA raíz (posiblemente con certificados CA intermedios) tendrá un certificado autofirmado en la cadena : la CA raíz

openssl s_client -connect myweb.com:443 -showcerts no tiene ninguna razón particular para confiar en el certificado CA raíz de Verisign, y porque es autofirmado que obtendrá "certificado firmado auto en cadena de certificados".

Si el sistema dispone de un lugar con un conjunto de certificados de confianza por defecto (creo /etc/pki/tls/certs en RedHat/Fedora y /etc/ssl/certs en Ubuntu/Debian), puede configurar OpenSSL para utilizarlos como anclas de confianza, por ejemplo, así:

openssl s_client -connect myweb.com:443 -showcerts -CApath /etc/ssl/certs 

Answer 3

Aquí hay un enlace a SSL certificado de instalación del inspector de VeriSign: https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR1130

Ingrese su dirección URL, haga clic en "Prueba de esta web Server" y que le dirá si hay problemas con su autoridad de certificación intermedia.

Answer 4

Cuando vea "Verify return code: 19 (self signed certificate in certificate chain)", entonces, o bien los servidores están realmente tratando de usar un certificado autofirmado (que un cliente nunca podrá verificar), o OpenSSL no tiene acceso a la necesaria root, pero el servidor intenta proporcionarlo él mismo (lo que no debería hacer porque no tiene sentido; un cliente nunca puede confiar en que un servidor proporcione la raíz correspondiente al certificado del servidor).

Nuevamente, agregar -showcerts lo ayudará a diagnosticar cuál.

Answer 5

Sobre el servidor puede ofrecer a los clientes el CERT de la raíz o no, extraído de la RFC-5246 'El Transport Layer Security (TLS) Protocolo Versión 1.2' doc dice:

certificate_list
This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to validate it in any case.

Sobre el término 'puede', extraído de la RFC-2119 "mejor práctica actual", dice:

5.MAY
This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)

en conclusión, la raíz puede estar en la ruta de certificación entregada por el servidor en el apretón de manos.

Un uso práctico.
Considere, no en términos de usuario del navegador, sino en una herramienta de transferencia en un servidor en una zona militarizada con acceso limitado a Internet.
El servidor, desempeñando el rol de cliente en la transferencia, recibe todas las rutas de certificación del servidor.
Todos los certs de la cadena se deben verificar para que sean de confianza, incluidos los root.
La única forma de comprobar esto es incluir la raíz en la ruta de certs en el tiempo de transferencia, coincidiendo con una copia local previamente declarada como 'confiable'.