¿Por qué mi cadena de certificados está incompleta? Cómo corregir intermedios ausentes

El sitio abre en un navegador, pero curl, un servicio Java o una aplicación móvil dicen que no pueden construir la cadena de confianza. Volver a emitir el certificado suele ser la primera reacción, y rara vez es la que resuelve el problema. El servidor puede estar omitiendo un intermedio, o puede estar entregando una cadena distinta de la que creías haber desplegado.

Un certificado no es un archivo aislado. El cliente debe ir desde el certificado hoja del sitio, pasando por una o más CA intermedias, hasta una raíz de su almacén de confianza. Un eslabón ausente, un certificado caducado dentro de la cadena o una CA privada en el extremo público pueden romper ese recorrido. Empieza por el handshake público, no por el PEM que ves en disco.

Usa el comprobador de SSL con el hostname, puerto y SNI reales. Separa si el servidor envió la cadena completa de si un cliente público puede confiar en ella. Son resultados relacionados, pero no equivalentes.

Qué significa realmente que la cadena esté incompleta

En una cadena HTTPS pública típica, el certificado del sitio lo emite una CA intermedia y esa intermedia está firmada por una CA raíz de confianza. La raíz suele existir ya en el almacén de confianza del sistema o del navegador. Por eso el servidor normalmente entrega el certificado hoja y los intermedios necesarios, no la raíz.

Una cadena incompleta suele significar que el servidor no entregó un intermedio que el cliente necesita para construir el camino. No se puede deducir de forma fiable el camino completo solo desde la hoja. Un entorno puede tener ese intermedio en caché o disponible, y otro no. Esa es una razón frecuente por la que el mismo sitio funciona en un dispositivo y falla en otro.

Separa “no se envió” de “no es confiable”

Los dos fallos se parecen, pero el diagnóstico es distinto:

Por tanto, desplegar fullchain no es una cura universal. Resuelve un intermedio ausente, pero no vuelve pública una CA privada ni arregla un certificado ya caducado dentro de la cadena.

No sustituyas el handshake público por el archivo del disco

Ver el fullchain.pem correcto en el servidor de aplicación no demuestra que sea el que reciben los visitantes. TLS puede terminar en un CDN, balanceador, Ingress, proxy inverso o plataforma gestionada. Puedes actualizar el backend y dejar intacto el borde público.

Anota del resultado en vivo el número de serie o la huella SHA-256 de la hoja, los intermedios devueltos, la IP resuelta y el SNI usado. Pega la cadena exportada en el decodificador de certificados y revisa subject, issuer, validez y huellas certificado por certificado. El issuer de uno y el subject del siguiente deben encajar; eso es una pista del camino, mientras que la decisión final de confianza corresponde al cliente o al comprobador.

Si la huella de la hoja pública ya es distinta, no sigas investigando intermedios. Probablemente estás mirando otro extremo o aún recibe tráfico un nodo antiguo.

Por qué el navegador funciona y curl, Java o la app fallan

Que un navegador cargue la página no demuestra que el despliegue sea correcto. Algunos entornos de navegador pueden tener en caché el intermedio necesario o completarlo según sus propias políticas; un cliente de línea de comandos, un runtime, un dispositivo integrado o una app pueden no hacerlo. También difieren sus almacenes de raíces, cómo construyen cadenas y sus restricciones de red.

No cierres el caso con «en mi portátil funciona». Repite con el cliente que falló, contra el mismo hostname público, y conserva el error completo. Si sucede solo en una red corporativa, Wi‑Fi de hotel o un equipo con software de seguridad, descarta un proxy de inspección HTTPS que presente su propio certificado.

Qué debe llevar un despliegue fullchain

Las plataformas lo llaman certificate chain, bundle o full certificate chain, pero el principio no cambia: entrega al componente que termina TLS el certificado del sitio y los intermedios necesarios para llegar a una raíz pública.

• Un fullchain suele colocar primero el certificado hoja y después uno o más intermedios.
• Configura la clave privada por separado. No la añadas a la cadena ni la pegues en ningún servicio en línea; diagnosticar una cadena solo necesita los certificados, y el decodificador de este sitio funciona en tu navegador.
• Normalmente no hace falta que el servidor envíe la raíz pública. Añadirla a ciegas no sustituye un intermedio ausente.
• No reemplaces un intermedio por otro solo porque parezca de la misma CA. La cadena emitida y los identificadores de clave deben corresponderse.

Tras desplegar, recarga el terminador TLS real y vuelve a probar desde el exterior. Comprobar solo un puerto local o un archivo de configuración puede ocultar un proxy anterior u otro nodo.

Arreglos que parecen lógicos pero retrasan el diagnóstico

Añadir la raíz al final, volver a emitir la hoja una y otra vez o probar solo en el navegador son desvíos habituales. Una raíz no sustituye un intermedio omitido; una reemisión no actualiza un CDN o balanceador antiguo; y el navegador puede funcionar porque su estado local es más permisivo.

También es un error concatenar variantes intermedias con firma cruzada al azar. Una cadena más larga no es una cadena mejor. Usa la cadena que la CA o la plataforma de certificados suministra para esa hoja, y valídala con el handshake público en lugar de adivinar por los nombres de archivo.

Si falla de forma intermitente, revisa cada punto de entrada

Cuando el error aparece solo en algunas peticiones, sospecha de la topología antes que de la suerte del cliente. IPv4 e IPv6 pueden llegar a servicios distintos, un nodo pudo quedar sin actualizar, un borde de CDN puede conservar configuración antigua o una comprobación de salud puede omitir el SNI previsto.

La dirección de una comprobación es solo una observación. Enumera todos los registros A y AAAA del hostname con DNS Lookup y repite para cada combinación de dirección, puerto y hostname; si tu entorno lo permite, compara conexiones con y sin el SNI previsto. Todo extremo que siga devolviendo la cadena antigua debe corregirse o retirarse del tráfico.

Un orden corto y completo para investigar

1. Comprueba el hostname público con el comprobador de SSL, indicando el puerto y SNI reales.
2. Anota por separado «¿se envió la cadena completa?» y «¿es confiable la cadena?». No llames intermedio ausente a todo resultado fallido.
3. Exporta la cadena pública y revisa hoja, emisor, fechas y huellas en el decodificador de certificados.
4. Encuentra el terminador TLS real, despliega allí el fullchain proporcionado por la CA y recarga el servicio.
5. Comprueba IPv4, IPv6, bordes CDN y cada nodo balanceado para que todos devuelvan la cadena esperada.
6. Repite con el cliente que falló primero. Si la cadena está completa pero no es confiable, investiga una CA privada, un certificado de la cadena caducado o inspección HTTPS local.

Si la cadena pasa pero el navegador informa de un nombre incorrecto, no sigas cambiando intermedios. La siguiente capa es SAN, SNI o enrutamiento: consulta ¿Por qué mi certificado SSL no coincide con mi dominio?. Para el mapa completo, vuelve a ¿Por qué mi certificado SSL no es válido?.