Falta el certificado intermedio: por qué tu web falla en algunos móviles

Respuesta corta: Si tu web abre bien en el ordenador pero da error de certificado en algunos móviles, en apps o en integraciones, lo más probable es que el servidor envíe solo tu certificado y no el certificado intermedio que lo une con la autoridad raíz. Algunos navegadores lo completan por su cuenta y otros no. Compruébalo con openssl s_client -showcerts y arréglalo instalando la cadena completa (en certbot, fullchain.pem).

Qué es el certificado intermedio

Las autoridades de certificación (mira, por ejemplo, la cadena de confianza de Let’s Encrypt) no firman tu certificado con su certificado raíz, el que viene instalado en los sistemas operativos y navegadores. Lo firman con un certificado intermedio, que a su vez está firmado por la raíz. La cadena completa queda así:

1. Tu certificado (tudominio.com), firmado por el intermedio.
2. El certificado intermedio (por ejemplo, uno de los de Let’s Encrypt o de Sectigo), firmado por la raíz.
3. El certificado raíz, que ya está en el dispositivo del visitante.

El dispositivo tiene la raíz, pero no tiene por qué tener el intermedio. Por eso el servidor debe enviar tu certificado y el intermedio en cada conexión. Si solo envía el tuyo, el dispositivo no puede construir la cadena hasta una raíz de confianza y la conexión falla.

Por qué falla en unos sitios sí y en otros no

Es lo que hace este error tan desconcertante. Algunos clientes compensan la falta del intermedio:

• Varios navegadores de escritorio descargan el intermedio que falta usando la dirección que viene dentro de tu propio certificado (la extensión AIA) o lo tienen en una caché porque lo han visto en otras webs. Firefox, por ejemplo, lleva incorporada una lista de intermedios conocidos.
• Muchos otros clientes no lo hacen: apps de Android, algunos navegadores móviles, curl, PHP, Python, Java, la mayoría de integraciones entre servidores (pasarelas de pago, webhooks, CRM), y los rastreadores de algunas herramientas.

El resultado típico: tú lo pruebas en tu ordenador y funciona, el cliente lo prueba en su móvil y no, y la pasarela de pago deja de notificar los pedidos. En Firefox puede salir SEC_ERROR_UNKNOWN_ISSUER si ese intermedio no está en su lista; en Chrome, NET::ERR_CERT_AUTHORITY_INVALID.

Cómo saber si te pasa

Con openssl

openssl s_client -connect tudominio.com:443 -servername tudominio.com -showcerts </dev/null 2>/dev/null | grep -E '^ *[0-9]+ s:|^ *i:|Verify return code'

Con la cadena bien instalada verás dos certificados (el 0, tuyo, y el 1, el intermedio) y un código 0:

 0 s:CN=tudominio.com
   i:C=US, O=Let's Encrypt, CN=R11
 1 s:C=US, O=Let's Encrypt, CN=R11
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
Verify return code: 0 (ok)

Si falta el intermedio, solo aparece el 0 y el código cambia:

 0 s:CN=tudominio.com
   i:C=US, O=Let's Encrypt, CN=R11
Verify return code: 21 (unable to verify the first certificate)

El código 20 (unable to get local issuer certificate) también apunta a una cadena incompleta.

Con curl

curl -sSI https://tudominio.com
curl: (60) SSL certificate problem: unable to get local issuer certificate

curl no descarga intermedios, así que es un buen indicador. Si curl falla y el navegador funciona, ya sabes lo que pasa.

Otros síntomas

• Errores de certificado solo en algunos móviles o solo en la app de un cliente.
• Webhooks o notificaciones de la pasarela de pago que fallan con errores de SSL.
• El error aparece justo después de renovar un certificado de pago o de migrar de servidor.

Cómo instalar la cadena completa

1. Consigue el intermedio correcto

• Let’s Encrypt con certbot: ya lo tienes. certbot guarda en /etc/letsencrypt/live/tudominio.com/ cuatro ficheros: cert.pem (solo tu certificado), chain.pem (solo el intermedio), fullchain.pem (los dos juntos) y privkey.pem (la clave). El que hay que usar es fullchain.pem.
• Certificado de pago: la autoridad te lo entrega junto al certificado, a menudo en un fichero llamado CA bundle, intermediate o chain. Si no lo encuentras, descárgalo de la web oficial de esa autoridad, buscando el intermedio que coincide con el issuer de tu certificado. No uses intermedios de webs de terceros.

2. Monta el fichero en el orden correcto

Primero tu certificado, después el intermedio. La raíz no hace falta: el dispositivo ya la tiene y enviarla solo añade peso.

cat tudominio.crt intermedio.crt > fullchain.crt

Comprueba qué hay dentro y en qué orden:

openssl crl2pkcs7 -nocrl -certfile fullchain.crt | openssl pkcs7 -print_certs -noout

El primer subject debe ser tu dominio, y el issuer de cada certificado debe coincidir con el subject del siguiente.

3. Configura el servidor

En Nginx:

ssl_certificate     /etc/letsencrypt/live/tudominio.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/tudominio.com/privkey.pem;

En Apache 2.4.8 o posterior, el fichero de SSLCertificateFile puede llevar la cadena completa:

SSLCertificateFile    /etc/letsencrypt/live/tudominio.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/tudominio.com/privkey.pem

En versiones antiguas de Apache se usaba además SSLCertificateChainFile apuntando al intermedio. Si encuentras una configuración con cert.pem y sin cadena, ahí está el fallo.

En Plesk y cPanel, al instalar un certificado de pago hay un campo específico para el certificado de la CA o CA bundle: pega ahí el intermedio. Si lo dejas vacío, el panel servirá solo tu certificado.

En IIS (Windows Server), importa el intermedio en el almacén «Entidades de certificación intermedias» del equipo local (con certlm.msc). IIS construye la cadena a partir de ese almacén.

En un balanceador o CDN donde subes el certificado a mano, suele haber un campo «cadena» o «certificate chain». Rellénalo.

4. Recarga y comprueba

sudo nginx -t && sudo systemctl reload nginx
openssl s_client -connect tudominio.com:443 -servername tudominio.com </dev/null 2>/dev/null | grep 'Verify return code'

Tiene que salir Verify return code: 0 (ok). Prueba también con curl -sSI https://tudominio.com y desde un móvil con datos móviles, no con el Wi-Fi de la oficina.

Errores habituales

• Usar cert.pem en lugar de fullchain.pem. Es la causa más frecuente en servidores con certbot configurados a mano.
• Orden invertido: el intermedio primero y tu certificado después. Algunos servidores ni arrancan; otros sirven una cadena que no valida.
• Intermedio equivocado, de otra autoridad o de una generación anterior. El issuer de tu certificado tiene que coincidir con el subject del intermedio.
• Renovar el certificado de pago y no actualizar el intermedio. Las autoridades cambian de intermedio de vez en cuando; usa siempre el que viene con el certificado nuevo.
• Comprobarlo solo en tu navegador. Tu navegador es justo el que te esconde el problema. Usa openssl o curl.
• Arreglarlo en el servidor y olvidar el CDN o el balanceador, que tienen su propia copia del certificado.

Si después de instalar la cadena sigue habiendo errores, el problema puede ser otro: repasa la lista completa en errores de certificado SSL. Y si el certificado está a punto de caducar, aprovecha y mira cómo renovarlo para que no vuelva a pasar.

Para agencias: el error que el cliente ve y tú no

Este es el error de «a mí me funciona» por excelencia. Si solo pruebas desde tu navegador, puedes tener una web con la cadena rota durante meses sin enterarte, mientras fallan los pagos o la app del cliente.

Jeffrey se conecta a cada web cada 6 horas como un cliente estricto, sin completar cadenas por su cuenta. Si falta el intermedio, abre una alerta crítica y urgente con el motivo claro: «Falta el certificado intermedio». En la misma revisión detecta certificados caducados, autofirmados o emitidos para otro dominio, y te avisa cuando quedan 14 días o menos para la caducidad. Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.

Preguntas frecuentes