¿Qué es una cadena de certificados SSL? Cómo funciona

¿Qué es una cadena de certificados SSL?

Una cadena de certificados SSL (también llamada cadena de confianza o ruta de certificación) es la lista ordenada de certificados digitales que conecta el certificado SSL/TLS de tu sitio web con una autoridad de certificación (CA) raíz de confianza. Cada certificado de la cadena está firmado digitalmente por el de arriba, lo que crea una ruta de confianza verificable desde tu servidor hasta una CA raíz en la que los navegadores ya confían.

Piénsalo como una cadena de avales. El certificado de tu servidor dice «Soy example.com». La CA intermedia dice «Respondo por el certificado de example.com». La CA raíz dice «Respondo por esa intermedia». Tu navegador ya confía en la CA raíz, así que al seguir la cadena de firmas también confía en tu servidor.

Cuando visitas un sitio HTTPS, tu navegador recorre esta cadena en milisegundos. Si cada eslabón es correcto, la página carga sin ninguna advertencia. Si falta un eslabón, ha expirado o no es de confianza, recibes en su lugar una advertencia de seguridad como NET::ERR_CERT_AUTHORITY_INVALID.

Los tres tipos de certificado de una cadena

Toda cadena tiene tres tipos de certificado, aunque un servidor puede enviar más de un intermedio:

Certificado raíz

El certificado raíz es el ancla de confianza en lo alto de la cadena. Está autofirmado, es decir, la autoridad de certificación firmó su propio certificado. Los certificados raíz vienen preinstalados en tu navegador y sistema operativo; esta colección se llama almacén de confianza (trust store).

La lista de raíces propia de Chrome contiene unas 100 (Chrome Root Store); Mozilla, Apple y Microsoft mantienen las suyas. Organizaciones como DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign y Google Trust Services operan raíces. Como las claves raíz valen tanto, las CA las guardan sin conexión en módulos de seguridad de hardware y solo las usan para firmar intermedios.

Certificado intermedio

Los certificados intermedios se sitúan entre la raíz y el certificado de tu servidor. La CA raíz firma el certificado intermedio, y la CA intermedia firma después los certificados de entidad final (servidor). La mayoría de las CA usan uno o dos intermedios.

Tu servidor web debe enviar los certificados intermedios junto con tu certificado leaf durante el handshake TLS. Chrome puede descargar un intermedio que falte y Firefox los trae precargados, pero las aplicaciones, los clientes de API y los Android antiguos no tienen ninguna de las dos cosas, así que para ellos la cadena se rompe.

Certificado leaf (certificado del servidor)

El certificado leaf (también llamado certificado de entidad final o certificado del servidor) es el certificado instalado en tu servidor web. Contiene el nombre de tu dominio, tu clave pública, el período de validez e información sobre el emisor (la CA intermedia que lo firmó).

Este es el primer certificado que tu navegador recibe durante el handshake TLS. El navegador luego sube por la cadena, verificando cada firma hasta alcanzar una raíz de confianza.

Cómo funciona la cadena de confianza

Cuando tu navegador se conecta a un sitio web a través de HTTPS, el handshake TLS activa un proceso de verificación de cadena que ocurre en milisegundos:

• El servidor envía sus certificados — el leaf y luego los intermedios.
• El navegador construye una ruta — desde el leaf hasta una raíz de su propia lista. Si falta un intermedio, Chrome lo descarga de la dirección escrita en el certificado (AIA), y Firefox usa su propio conjunto precargado; muchos otros clientes simplemente fallan.
• Se comprueban las firmas — cada certificado debe estar firmado con la clave del de arriba.
• Se comprueba la raíz — la ruta debe terminar en una raíz de la lista del navegador. Una raíz desconocida falla.
• Se comprueba la validez — cada certificado debe estar dentro de sus fechas y no estar revocado, y el leaf debe cubrir el nombre de la barra de direcciones.

Cadenas reales: lo que envían 12 sitios grandes

Pedimos sus cadenas a 12 de los sitios más grandes el 27 de octubre de 2026 (openssl s_client -showcerts, desde dos ubicaciones). Ninguno envió solo un leaf, y varios enviaron certificados adicionales con firma cruzada para que los dispositivos antiguos aún lleguen a una raíz que conocen. Lo que envía un servidor puede cambiar según tu versión de TLS, si tu cliente admite ECDSA y qué ubicación de CDN responde: facebook.com, por ejemplo, envió 3 certificados con TLS 1.2.

Qué sucede después de la verificación

Si todas las comprobaciones pasan, la conexión sigue adelante. Si una sola falla, incluso en un intermedio, el navegador muestra una advertencia como «Tu conexión no es privada» con un código como NET::ERR_CERT_AUTHORITY_INVALID. (Los fallos previos a examinar cualquier certificado, durante el propio handshake TLS, muestran otros códigos: ERR_SSL_PROTOCOL_ERROR o ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

Por eso importa toda la cadena, no solo el certificado leaf. Un intermedio expirado rompe HTTPS igual que un certificado de servidor expirado, a menos que el cliente pueda construir otra ruta que lo evite.

Por qué existen los certificados intermedios

Las CAs raíz podrían teóricamente firmar cada certificado de servidor directamente, omitiendo los intermedios por completo. Pero hay tres razones críticas por las que no lo hacen:

• Aislamiento de seguridad — Las claves privadas de la CA raíz se mantienen offline en HSMs dentro de bóvedas físicamente seguras. Se usan solo para firmar intermedios, no millones de certificados de servidor individuales. Esto reduce drásticamente el riesgo de que la clave raíz sea comprometida.
• Contención de daños — Si una CA intermedia es comprometida, solo los certificados de esa intermedia se ven afectados. La CA raíz puede revocar la intermedia comprometida y emitir una nueva — sin invalidar todos los certificados que ha emitido.
• Flexibilidad operativa — Las CAs usan diferentes intermedios para diferentes propósitos: uno para certificados DV, otro para EV, separados para diferentes regiones o algoritmos de clave (RSA vs ECDSA).

Cómo verificar tu cadena de certificados SSL

Hay tres maneras de inspeccionar la cadena de certificados de un sitio web, desde herramientas de línea de comandos hasta verificaciones basadas en navegador.

Método 1: OpenSSL (línea de comandos)

El comando openssl es la forma más detallada de inspeccionar una cadena de certificados. Ejecuta esto en tu terminal:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Método 2: visor de certificados del navegador

Todos los navegadores principales muestran la cadena que construyeron (puede diferir de la que envió el servidor, si ellos mismos descargaron un intermedio faltante):

• Chrome: haz clic en el icono a la izquierda de la dirección → La conexión es segura → El certificado es válido, y luego abre la pestaña Detalles para ver la jerarquía de certificados
• Edge: haz clic en el candado → «Connection is secure» → el icono de certificado en la parte superior del panel
• Firefox: haz clic en el candado → «Connection secure» → «More information» → «View Certificate»; cada certificado de la cadena tiene su propia pestaña
• Safari (18.4 y posteriores): elige Safari > Detalles sobre la seguridad de la conexión en la barra de menús (Apple); en iPhone, toca la parte izquierda del campo de dirección → «Privacy & Security» → «Connection Security Details»

Método 3: Verificador SSL de DNS Robot

La forma más rápida de comprobarlo desde fuera de tu red es nuestro Verificador SSL: muestra la cadena que envía el servidor, si las listas de raíces de Mozilla, Chrome, Apple y Microsoft confían cada una en ella, una advertencia cuando la cadena está incompleta y las fechas de cada certificado. Para los sitios detrás de Cloudflare lee el certificado de los registros CT públicos, así que ahí no se comprueba la cadena que envía el servidor.

Errores comunes de cadena de certificados y cómo corregirlos

Los problemas de cadena de certificados son una de las causas más frecuentes de errores HTTPS. Aquí están los errores que probablemente encontrarás y cómo resolver cada uno.

Certificado intermedio faltante

Mensaje de error: «unable to get local issuer certificate» (curl, Python, PHP), «unable to verify the first certificate» (Node.js) o «incomplete certificate chain»

Causa: el servidor envía solo el certificado leaf. Chrome suele repararlo descargando él mismo el intermedio (el verificador de Apple también), así que el sitio puede verse bien en un navegador mientras curl en Linux, Python, Java, las devoluciones de llamada de pagos y muchas aplicaciones fallan.

Solución: envía los intermedios junto con el leaf. Con Let's Encrypt, apunta tu servidor a fullchain.pem, no a cert.pem; con otra CA, descarga su intermedio y ponlo después de tu certificado en un solo archivo:

cat your-domain.crt intermediate.crt > fullchain.crt

Certificado autofirmado en la cadena

Mensaje de error: «self-signed certificate in certificate chain» (error 19 de OpenSSL)

Causa: la cadena termina en una raíz en la que el cliente no confía: una CA privada o de empresa, o un proxy o antivirus que vuelve a firmar el tráfico con su propia raíz. Enviar una raíz en la que el cliente sí confía es inofensivo, solo innecesario.

Solución: usa un certificado de una CA pública para los sitios públicos, o instala la raíz privada en los clientes que la necesiten. Dejar la raíz fuera de la cadena del servidor es más limpio, pero no corrige este error.

Orden incorrecto de certificados

Mensaje de error: la verificación de la cadena falla en algunos clientes, o estos informan de que el certificado no es de confianza.

Causa: los certificados del archivo de cadena están en el orden incorrecto. TLS 1.3 exige el certificado del propio servidor primero y pide el resto en orden, aunque indica a los clientes que toleren otros órdenes (RFC 8446 §4.4.2); los clientes más antiguos o estrictos pueden no hacerlo.

Solución: pon primero el certificado leaf y después cada intermedio, empezando por el que firmó tu leaf.

Certificado expirado en la cadena

Mensaje de error: «certificate has expired» — pero la fecha de expiración de tu certificado leaf parece correcta.

Causa: ha expirado un certificado más arriba en la cadena. El caso más conocido: DST Root CA X3 de IdenTrust, que había firmado de forma cruzada la raíz de Let's Encrypt, expiró el 30 de septiembre de 2021, y los dispositivos que no confiaban en ISRG Root X1 (y los clientes con OpenSSL 1.0.x) empezaron a fallar en los sitios con Let's Encrypt.

Solución: descarga el certificado intermedio actual de tu CA y reemplaza el antiguo. Luego usa nuestro Verificador SSL para comprobar la cadena actualizada.

Mejores prácticas para cadenas de certificados

• Envía siempre los intermedios — no cuentes con que los navegadores reparen la cadena; las aplicaciones y los clientes de API no lo harán.
• La raíz es opcional — los clientes usan su propia copia, así que enviar una raíz en la que ya confían solo añade bytes; una raíz con firma cruzada para dispositivos antiguos es una excepción deliberada.
• Mantén el orden — primero el leaf, luego los intermedios desde el que firmó tu leaf hacia arriba.
• Automatiza la renovación — los certificados emitidos desde marzo de 2026 duran como máximo 200 días, y bajarán a 100 en marzo de 2027; Let's Encrypt pasa a certificados de 64 días en febrero de 2027.
• Comprueba después de cada renovación o migración — una CA puede cambiar de intermedio entre renovaciones. Pasa el sitio por el Verificador SSL después.
• Vigila cada nombre — www, el dominio sin prefijo y cada subdominio pueden servirse con certificados y cadenas distintos. El Buscador de subdominios lista los nombres que han cubierto tus certificados, a partir de los registros públicos de certificados.