¿Qué es la cadena de confianza de los certificados?

El estándar de seguridad de Internet SSL/TLS se basa en un modelo de relación de confianza, también llamado "cadena de confianza del certificado".

Los certificados digitales x.509 validan la identidad de un sitio web, organización o servidor y proporcionan una plataforma de confianza para que el usuario se conecte y comparta información de forma segura.

SSL/TLS La Infraestructura de Clave Pública (PKI) basada en Internet permite a los usuarios intercambiar datos utilizando pares de claves públicas y privadas, obtenidas e intercambiadas por una autoridad de certificación (CA) de confianza. Esta entidad de confianza se encarga de emitir, conservar y revocar certificados de clave pública a través de redes inseguras.

Cuando visita un sitio web a través de una conexión segura, el sitio envía un certificado digital a su navegador. Su navegador de Internet compara el emisor con una lista de Autoridades de Certificación(CA Raíz) de confianza. Si no se encuentra ninguna coincidencia, el navegador del cliente comprueba si una CA raíz de confianza firma el certificado de la CA emisora. El motor de encadenamiento del navegador continúa verificando el emisor de cada certificado hasta que encuentra una raíz de confianza o al llegar al final de la cadena de confianza.

La certificación de la cadena de confianza tiene por objeto demostrar que un determinado certificado procede de una fuente de confianza.

Si el certificado es legítimo y enlaza con una CA raíz en el almacén de confianza del navegador del cliente, el usuario sabrá que el sitio web es seguro basándose en los indicadores de confianza de la interfaz, como se muestra a continuación.

Indicadores de confianza de los navegadores web

Sin embargo, supongamos que la cadena de confianza falla en la verificación. En ese caso, un certificado no puede demostrar su validez por sí solo, y el navegador advertirá al usuario de un posible riesgo para la seguridad, como se muestra a continuación.

Aviso de navegador web no seguro

Sin embargo, los principales sistemas operativos, navegadores web o aplicaciones no confían globalmente en los certificados PKI privados. Aunque pueden emitir certificados X.509 internamente, sólo los certificados de una CA de confianza pública pueden evitar que el navegador envíe mensajes de advertencia.

Existen tres tipos básicos de entidades que componen una cadena de confianza válida: Entidad raíz, intermedia y final. Veamos cada uno de ellos con más detalle en la siguiente sección.

Un certificado raíz es un certificado autofirmado que sigue las normas del certificado X.509. Una cadena de confianza jerárquica de varios niveles permite a los clientes y aplicaciones web verificar que una fuente de confianza ha validado la identidad de la entidad final.

Si la clave privada del anclaje de confianza se ve comprometida, todos los certificados firmados bajo esa clave privada se verán comprometidos, y todos los certificados emitidos por esa CA se verán afectados. Esto llevará a la reemisión de nuevos certificados por parte de la CA a cada CA intermedia y entidad final de la cadena de certificados.

Como resultado, la CA raíz debe vigilar de cerca su clave privada y rara vez firma certificados de entidad final directamente. En su lugar, la autoridad raíz creará y firmará una o más CA intermedias para emitir certificados y vincularlos de nuevo a la CA raíz.

Casi siempre habrá al menos un certificado intermedio en una cadena de certificadosSSL . Proporcionan un vínculo vital que permite a la CA raíz extender su reputación de confianza a entidades finales que, de otro modo, no serían de confianza.

La CA emisora funciona como intermediaria entre el certificado raíz seguro y el certificado del servidor. Esto permite que la CA raíz permanezca almacenada de forma segura fuera de línea, lo que proporciona un nivel adicional de seguridad.

La confianza en la CA raíz es siempre explícita. Todos los sistemas operativos, navegadores web de terceros y aplicaciones personalizadas incluyen más de 100 certificados de CA raíz de confianza preinstalados. En cambio, los certificados que no son raíz son de confianza implícita y no es necesario que vengan con un sistema operativo, un navegador web o una aplicación compatible con certificados.

Los certificados de servidor proporcionan seguridad, escalabilidad y conformidad con las normas de las CA. Sin embargo, los certificados no garantizan que el sujeto sea digno de confianza, reputado en sus tratos comerciales, que cumpla cualquier ley o que sea seguro hacer negocios con él.

La entidad final proporciona información crítica a la CA emisora a través de un formulario de solicitud de firma de certificado. A continuación, una CA de confianza firma y emite el certificado, dando fe de que la información facilitada era correcta en el momento de su emisión. La conexión SSL a un servidor fallará si el certificado no ha sido verificado y firmado.

Los suscriptores de certificados de servidor no siempre son la parte del certificado; el uso de los casos varía en función de los requisitos del entorno del certificado. El certificado emitido a una organización para sus empleados sólo verifica que la CA ha autenticado la información solicitada de un representante de dicha organización, no de cada empleado.

Por ejemplo, una CA raíz puede emitir certificados que identifiquen una función específica que desempeña el suscriptor en lugar de un individuo concreto (por ejemplo, el "Director de Información" es un individuo único, mientras que el "Miembro del personal de TI" no lo es). Este tipo de certificado basado en funciones se utiliza cuando se desea el no repudio.

La CA Raíz también puede emitir un certificado de grupo cuando varios suscriptores comparten un certificado de Clave Privada.

Si varias entidades actúan como una sola, la AC debe mantener una lista de los abonados que tienen acceso a la clave privada y contabilizar el periodo durante el cual cada abonado tiene el control de la clave.

Las autoridades de certificación pueden desempeñar funciones relacionadas tanto con los servicios PKI privados como con las operaciones de clave pública, incluida la recepción de solicitudes de certificados aplicables, la emisión, revocación y renovación de certificados digitales.

Puede que se haya dado cuenta de que las CA intermedias son funcionalmente similares a las CA raíz. Sin embargo, suelen tener menos funciones de uso de claves habilitadas. Un certificado X.509 válido de un emisor de confianza sólo es válido para el uso especificado en las políticas de certificados. Los certificados que cumplen estas normas de política de cadena pueden seguir siendo inválidos para otros usos con funciones como Seguridad / MIME (SMIME), Authenticode o Secure Sockets Layer (SSL). Puede ser necesario un procesamiento adicional para determinar si el certificado es válido para una política específica.

El certificado intermedio contiene extensiones de uso de clave que definen los posibles usos o propósitos del certificado.

El propósito del certificado puede ser uno de los cuatro ajustes de uso de claves y campos de uso de claves ampliados identificados en el certificado:

• Cifrado: Las claves criptográficas de cifrado y descifrado se incluirán en un certificado a tal efecto.
• Firma: El certificado para este fin contendrá claves criptográficas únicamente para la firma de datos.
• Firma y cifrado: Un certificado para este fin deberá cubrir todos los usos primarios de la clave criptográfica del certificado, incluyendo el cifrado de datos, el descifrado de datos, el inicio de sesión inicial o la firma digital.
• Inicio de sesión con firma y con tarjeta inteligente: El certificado para este fin permite el inicio de sesión inicial de la tarjeta inteligente y la firma digital de los datos; no puede utilizarse para el cifrado de datos.

Habrá una CA raíz y una o más CA subordinadas. Las CA subordinadas proporcionan redundancia y equilibrio de carga, mientras que la CA raíz suele estar desconectada. En este caso, incluso si la CA subordinada se ve comprometida, la CA raíz puede revocar la CA subordinada, proporcionando así redundancia.

También se denomina modelo de certificación cruzada. Las CA forman aquí una relación de igual a igual. Este modelo es difícil de gestionar a medida que aumenta el número de CA. Este tipo de relación de confianza puede darse cuando distintas divisiones de la empresa tienen distintas CA y necesitan trabajar juntas.

Bridge CA supera la complejidad del modelo Web of Trust. En este caso, la CA puente actúa como punto central de coordinación. Todas las demás CA (denominadas principales) deben confiar únicamente en la CA puente.

El certificado de CA raíz se localiza reconstruyendo la ruta de certificación. Cuando un ordenador encuentra varias rutas de certificación de confianza durante el proceso de validación de certificados, el motor de cadenas de certificados busca la mejor ruta de certificación calculando la puntuación de cada cadena. La puntuación se calcula en función de la calidad y la cantidad de información que puede proporcionar la ruta del certificado. Si las puntuaciones de varias rutas de certificación son iguales, se seleccionará la cadena más corta.

El sistema operativo Windows permite los cuatro métodos siguientes para recuperar certificados de cadenas de certificados:

1. A través de la tienda local de certificados;
2. Utilice un contenedor PKCS#7 con una cadena completa o parcial;
3. Utilice la extensión del Acceso a la Información de Autoridades (AIA);
4. Crypt32.dll y el sitio web de Microsoft Update.

Veamos más detenidamente cada uno de estos métodos.

CryptoAPI utiliza la búsqueda en el almacén de certificados local para obtener el certificado necesario, lo que reduce el tiempo de creación de la cadena de certificados. Sin embargo, esto sólo se aplica a los certificados CA que ya han sido instalados por un proveedor de aplicaciones (por ejemplo, un SO o un proveedor de navegadores). Si el almacén de certificados local no contiene los certificados necesarios, se intentarán otros métodos de recuperación de certificados.

El método de recuperación de certificados PKCS#7 es frecuente en Internet. Un mensaje PKCS#7 puede almacenar varios certificados y actuar como contenedor de certificados. Este método permite a las aplicaciones de servidor simplificar la construcción de una cadena de certificados mediante la entrega de un certificado completo o parcial de la cadena de certificados. Los principales servidores web, Apache y Microsoft IIS, envían todos los certificados por defecto, y no se requiere ninguna configuración adicional para soportar PKCS#7.

Se puede observar un comportamiento similar al explorar las firmas de Authenticode. Al firmar un archivo binario, se puede incluir una cadena de certificados en la firma, y estos certificados se utilizarán para construir una cadena validando cada firma. Aunque este método es beneficioso, no siempre está disponible para las aplicaciones. Por ejemplo, cuando se conecta a la VPN SSTP, el servidor VPN no envía certificados intermedios al cliente.

Si su ordenador está conectado a Internet, Certificate Chain Engine comprobará el sitio web de Microsoft Update. Y si lo encuentra (como en el ejemplo anterior), lo descargará e instalará en el almacén de certificados. Si el equipo no está conectado a Internet, CCE extraerá el contenido del certificado de la biblioteca crypt32.dll e instalará el certificado en el contenedor de CA raíz de confianza.