Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
Un solo certificado nunca es suficiente. La confianza en internet se construye a través de cadenas, secuencias enlazadas de certificados que conectan el de tu servidor hasta una raíz que tu navegador ya confía.
Cuando su navegador se conecta a un sitio web mediante HTTPS, no acepta simplemente el certificado digital del servidor tal como es. En su lugar, sigue una cadena de firmas, desde el certificado en el servidor, pasando por uno o más certificados intermedios, hasta un certificado raíz que ya está incrustado en el almacén de confianza del navegador. Si cada enlace de esa cadena es válido, la conexión es confiable. Si algún enlace está roto, la conexión falla.
Este mecanismo, la cadena de certificados (o cadena de confianza), es lo que hace PKI escalable. Un puñado de CAs raíz pueden avalar a miles de CAs intermedios, que a su vez pueden emitir millones de certificados de entidad final. Ninguna autoridad única necesita firmar cada certificado del mundo. La confianza se delega, se estratifica y es verificable en cada paso.
Entender cómo funcionan las cadenas no es solo académico. Las cadenas mal configuradas son una de las causas más comunes de errores TLS, interrupciones relacionadas con certificados, y integraciones fallidas. Si alguna vez has visto una advertencia del navegador que dice "el certificado no es de confianza" (aunque el propio certificado sea válido), el problema casi con certeza era una cadena rota.
Una cadena de certificados es una secuencia ordenada de certificados, cada uno firmando al siguiente, desde el ancla de confianza hasta el certificado presentado por el servidor o dispositivo. Normalmente hay tres niveles:
En la parte superior de la cadena se encuentra la raíz Autoridad de Certificación. El certificado de la CA raíz's es autofirmado: está firmado con su propia clave privada, porque no hay una autoridad superior que lo respalde. En su lugar, la confianza en una CA raíz proviene de su inclusión en almacenes de confianza mantenidos por los proveedores de sistemas operativos y navegadores. Las CAs raíz se mantienen offline, sus claves almacenadas en HSMs, y se utilizan solo para firmar certificados de CA intermedios.
Los CA intermedios (también llamados CA subordinados) están firmados por el CA raíz. Se sitúan en el medio de la cadena y realizan el trabajo real de emitir certificados de entidad final. Esta capa existe por seguridad: si un CA intermedio se ve comprometido, la raíz puede revocar su certificado sin destruir todo el PKI. Puede haber uno o varios niveles intermedios, aunque la mayoría de los PKI públicos usan uno o dos.
Este es el certificado instalado en el servidor, dispositivo o aplicación. Está firmado por una CA intermedia. El certificado de entidad final contiene la clave pública del servidor, su nombre de dominio (en los campos Subject o SAN), y la información del emisor que apunta a la CA intermedia. No puede firmar otros certificados; es la "hoja" de la cadena.
Cuando un servidor presenta su certificado durante un apretón de manos TLS, también envía el(los) certificado(s) intermedio(s). El cliente luego construye la cadena ascendente: hoja a intermedio a raíz. Si la raíz está en el almacén de confianza del client's y cada firma en la cadena es válida, se establece la confianza.
Cuando un cliente (navegador, aplicación o sistema operativo) recibe un certificado, realiza una serie de comprobaciones para validar la cadena. Aquí se desglosa el proceso:
El cliente ensambla la cadena de certificados coincidiendo cada certificado's Issuer campo con el Subject campo del siguiente certificado. Comienza con el certificado de entidad final y avanza hacia arriba hasta alcanzar una raíz autofirmada.
Para cada certificado en la cadena, el cliente utiliza la clave del emisor clave pública para verificar la firma digital. Si la firma del certificado de entidad final puede verificarse con la clave pública de la CA intermedia, y la firma de la intermedia puede verificarse con la clave pública de la raíz, la cadena es criptográficamente sólida.
Cada certificado en la cadena debe estar dentro de su período de validez (entre sus "Not Before" y "Not After" fechas). Si algún certificado ha expirado o aún no es válido, la validación de la cadena falla, incluso si el certificado hoja está actual.
El cliente verifica que las extensiones de cada certificado's permitan su función. Por ejemplo, el basicConstraints extensión en un intermedio debe tener CA:TRUE. La keyUsage extensión debe incluir keyCertSign para certificados que firman otros certificados. Obtenga más información en el X.509 standard capítulo.
Finalmente, el cliente verifica que el certificado raíz en la parte superior de la cadena esté presente en su almacén de confianza. Si lo está, toda la cadena es confiable. Si no lo está (por ejemplo, porque la raíz pertenece a una CA privada que el cliente no ha sido configurado para confiar), la validación falla y el usuario ve una advertencia de certificado.
Un almacén de confianza es una colección de certificados raíz de CA que un sistema considera confiables. Cada navegador, sistema operativo y muchas aplicaciones mantienen su propio almacén de confianza. Cuando se valida una cadena de certificados, la verificación final es si el certificado raíz de CA en la parte superior de la cadena existe en el almacén de confianza que se está utilizando.
Firefox utiliza su propio almacén de confianza (gestionado por el Mozilla's Programa Raíz). Chrome y Edge dependen del almacén de confianza del sistema operativo's en la mayoría de las plataformas, aunque Chrome está migrando a su propio Chrome Root Store. Safari utiliza el almacén de confianza de Apple. Cada programa tiene sus propios criterios de inclusión y requisitos de auditoría.
Windows mantiene su almacén de Autoridades de Certificación Raíz de Confianza, macOS usa el Llavero del Sistema, y las distribuciones de Linux típicamente usan un paquete CA compartido (p. ej., /etc/ssl/certs). Las aplicaciones que no incluyen su propio almacén de confianza heredan la confianza del OS.
Los CAs raíz públicos deben pasar auditorías rigurosas (WebTrust para CAs, ETSI EN 319 411) y cumplir con los Requisitos Básicos del Foro CA/Navegador. El proceso de solicitud puede tardar más de un año. Una vez aceptado, la raíz se distribuye a miles de millones de dispositivos mediante actualizaciones del sistema operativo y del navegador.
Para privado PKI, las organizaciones distribuyen su propio certificado raíz de CA a los dispositivos gestionados mediante Directiva de Grupo de Active Directory, perfiles MDM, gestión de configuración (Ansible, Puppet) o instalación manual. Así es como los servicios internos son confiados sin depender de CAs públicos.
En una jerarquía PKI sencilla, la confianza fluye en una sola dirección: de la raíz al intermedio y al extremo. Pero las implementaciones del mundo real a veces necesitan conectar jerarquías PKI separadas para que los certificados de una jerarquía sean confiados por los sistemas de otra. Existen dos enfoques principales.
Certificación cruzada ocurre cuando dos AC emiten certificados entre sí. Si CA-A firma un certificado para CA-B, entonces los sistemas que confían en CA-A también confiarán en los certificados emitidos por CA-B, y viceversa, si CA-B firma un certificado para CA-A. Esto crea confianza mutua sin requerir una raíz compartida. Se utiliza comúnmente cuando dos organizaciones se fusionan, cuando un gobierno necesita interoperar con una AC comercial, o al pasar de raíces CA antiguas a nuevas.
CAs de puente Amplíe este concepto. Una CA de puente actúa como un centro de confianza central que se certifica cruzadamente con múltiples CAs independientes. En lugar de que cada CA se certifique cruzadamente con todas las demás CAs (lo que crece cuadráticamente), cada CA solo necesita certificarse cruzadamente con el puente. La Autoridad Federal de Certificación de Puente de EE. UU. (FBCA) es un ejemplo bien conocido, que conecta numerosas PKI de agencias federales en un único marco de confianza interoperable.
Ambos mecanismos añaden complejidad a la construcción y validación de la cadena. Un solo certificado ahora puede tener múltiples cadenas válidas: una a través de la jerarquía directa y otra a través de una ruta de certificado cruzado. Las bibliotecas TLS modernas manejan esto automáticamente, pero es importante comprenderlo al solucionar comportamientos de confianza inesperados.
Los problemas de la cadena de certificados están entre las causas más frecuentes de errores TLS y interrupciones. Aquí están los problemas que es más probable que encuentre:
Este es el problema de cadena más común. Un servidor presenta su certificado leaf pero no incluye el(los) certificado(s) intermedio(s) de la CA. Sin el intermedio, el cliente no puede construir una ruta hasta la raíz, y la conexión falla. Algunos navegadores solucionan esto almacenando en caché los intermedios de conexiones anteriores (un proceso llamado obtención AIA), pero no todos los clientes lo admiten. La solución es sencilla: configure su servidor para enviar la cadena completa.
Los certificados de CA raíz normalmente tienen períodos de validez muy largos (20-30 años), y los intermedios duran de 5 a 10 años. Pero expiran. Cuando una raíz o un intermedio expira, cada certificado bajo ella en la cadena se vuelve no confiable, incluso si los certificados finales todavía están dentro de su período de validez. La expiración del DST Root CA X3 de IdenTrust en 2021, que afectó a millones de dispositivos más antiguos, es un ejemplo bien conocido.
La especificación TLS requiere que los certificados se envíen en orden: primero la hoja, luego los intermedios, con la raíz opcionalmente incluida al final. Algunos servidores envían certificados en el orden incorrecto. Aunque la mayoría de las bibliotecas TLS modernas pueden reordenar la cadena automáticamente, implementaciones más antiguas o más estrictas pueden rechazar una cadena desordenada. El orden correcto elimina la ambigüedad.
Si la CA raíz en la parte superior de la cadena no está en el almacén de confianza del cliente, toda la cadena no es confiable. Esto ocurre comúnmente cuando la raíz de una CA privada no se ha distribuido a todos los puntos finales, cuando se elimina una raíz de un programa de almacén de confianza, o cuando una aplicación cliente usa un almacén de confianza diferente al esperado (p. ej., una aplicación Java que usa su propio cacerts keystore).
La mayoría de los problemas de cadena son evitables con una configuración y monitoreo adecuados. El desafío aumenta con la escala: cuando gestionas miles de certificados en cientos de servidores, una sola cadena mal configurada puede pasar desapercibida hasta que cause un incidente de producción.
Detectar cadenas rotas automáticamente: Evertrust CLM supervisa continuamente sus certificados implementados y señala los problemas de cadena (intermedios faltantes, CAs expirados y configuraciones incorrectas) antes de que causen interrupciones.
Mapea toda la jerarquía de CA: Visualiza las relaciones entre CAs raíz, CAs intermedios y certificados de entidad final en toda tu infraestructura. Observa qué certificados dependen de qué CAs y recibe alertas tempranas cuando cualquier certificado de CA se acerque a su vencimiento.
Valida cadenas a gran escala: Evertrust CLM realiza la validación de cadenas en todo tu inventario de certificados, identificando problemas de confianza que sería imposible detectar manualmente al gestionar miles de certificados.
Prevenir interrupciones proactivamente: Alertas en tiempo real sobre anomalías en la cadena, intermedios que expiran y cambios en el almacén de confianza garantizan que su equipo pueda actuar antes de que los usuarios se vean afectados.
