ERR_CERT_AUTHORITY_INVALID: por qué aparece y cómo solucionarlo

ERR_CERT_AUTHORITY_INVALID significa que el navegador no pudo construir una cadena de confianza desde el certificado que presentó tu servidor hasta una autoridad raíz en la que ya confía. Chrome lo muestra como NET::ERR_CERT_AUTHORITY_INVALID bajo la pantalla "La conexión no es privada". Casi nunca indica que tu certificado haya caducado, y casi siempre se debe a una de dos cosas: tu servidor no está enviando su certificado intermedio, o el certificado no lo emitió una autoridad de confianza pública. La solución lleva minutos una vez sabes de qué lado está el fallo.

Qué significa realmente el error

Cada certificado TLS se valida recorriendo una cadena. El navegador recibe el certificado del servidor (el certificado final), lee qué autoridad lo firmó y busca esa autoridad. Si la autoridad firmante es un intermedio, el navegador necesita también ese certificado intermedio para comprobar quién firmó ese, y así continúa el recorrido hasta llegar a un certificado raíz ya instalado en su almacén de confianza.

Si falta cualquier eslabón de ese recorrido, no está firmado por una parte de confianza, o lo emitió una autoridad que el navegador ha eliminado, la cadena no puede completarse y la conexión se rechaza con ERR_CERT_AUTHORITY_INVALID.

Chrome distribuye su propia lista de confianza, el Chrome Root Store, en lugar de depender únicamente del sistema operativo. Firefox hace lo mismo. Safari y Edge se apoyan en el almacén del sistema. Esa diferencia explica por qué un sitio puede fallar en un navegador y cargar en otro dentro del mismo equipo, y es una de las señales de diagnóstico más útiles que tienes.

Las siete causas, y dónde está el fallo

Las causas 1 y 2 explican la inmensa mayoría de los casos reales. Si el sitio es tuyo, empieza por ahí.

Diagnóstico rápido en 30 segundos

Antes de cambiar nada, averigua si el problema está en el servidor o en el equipo del visitante.

1. Abre el sitio con datos móviles, en un teléfono que nunca lo haya visitado. Si falla ahí pero funciona en tu equipo, falta un intermedio. Los navegadores de escritorio guardan en caché los intermedios que ya han visto y reparan la cadena en silencio, que es justo por lo que este fallo sobrevive tanto tiempo sin detectarse.
2. Prueba otro navegador en el mismo equipo. Si solo falla en Chrome, apunta a que el Chrome Root Store rechaza la autoridad. Si falla todo en un equipo, apunta a intercepción o a un dispositivo desactualizado.
3. Pulsa en la advertencia, entra en "Configuración avanzada" y lee el emisor. Si el emisor es tu antivirus, un proveedor de cortafuegos o el nombre de tu empresa, el tráfico se está interceptando y refirmando. Esa es la causa 4, y no es culpa de tu web.
4. Comprueba la cadena desde la línea de comandos con OpenSSL:

openssl s_client -connect ejemplo.com:443 -servername ejemplo.com -showcerts

Deberías ver al menos dos certificados en la salida: el final y, después, uno o más intermedios. Si solo vuelve un certificado, falta el intermedio y has encontrado el fallo.

Solución 1: instala la cadena de certificados completa

Esta es, con diferencia, la causa más habitual en el servidor. Tu autoridad te entrega un certificado final y uno o varios intermedios, y el servidor tiene que enviarlos todos. Apunta tu servidor web a la cadena completa en lugar de al certificado final por sí solo.

Si usas Let's Encrypt, la solución suele ser cambiar una palabra: usa fullchain.pem, nunca cert.pem. Let's Encrypt señala que todo certificado que emite tiene un intermedio firmado directamente por su raíz más ampliamente reconocida, y que varios intermedios activos rotan con el tiempo, por lo que fijar en el código un archivo intermedio concreto es frágil (Let's Encrypt, Chains of Trust). Recarga el servidor tras el cambio; una modificación de configuración no hace nada hasta que el proceso la lee.

Solución 2: sustituye un certificado autofirmado

Un certificado autofirmado se firma a sí mismo. Ninguna autoridad pública responde por él, así que ningún navegador puede confiar en él sin intervención manual. Es el comportamiento correcto, no un error.

Para cualquier cosa expuesta al público, consigue un certificado gratuito de una autoridad de confianza pública y automatiza la renovación. Para herramientas realmente internas, o bien añades tu raíz interna a los almacenes de confianza de los dispositivos que la necesiten, o bien emites desde una CA interna que ya distribuya tu gestión de dispositivos. No acostumbres a tu equipo a saltarse la advertencia: precisamente con ese hábito cuentan los operadores de phishing.

Solución 3: descarta intercepción y dispositivos obsoletos

Si el emisor que aparece en la advertencia es un producto antivirus, desactiva temporalmente su análisis HTTPS o SSL y recarga. Muchas suítes de seguridad insertan su propia raíz para inspeccionar tráfico cifrado, y una raíz de inspección rota o caducada rompe todos los sitios HTTPS a la vez.

En un dispositivo obsoleto, instala las actualizaciones pendientes del sistema. Los almacenes de raíces llegan con las actualizaciones del sistema, y un equipo con varios años de retraso carecerá por completo de las raíces más recientes. Por último, comprueba el reloj: una fecha del sistema disparatada puede hacer que una raíz válida parezca aún no válida, lo que se manifiesta como un error de autoridad y no de fecha.

Solución 4: comprueba si tu CA sigue siendo de confianza

Los programas de raíces eliminan autoridades que incumplen sus requisitos, y esas eliminaciones son hechos reales con plazos reales. El Chrome Root Program exige que, a partir del 15 de junio de 2026, los certificados TLS públicos de nueva emisión lleven únicamente el uso extendido de clave serverAuth; los certificados que lleven además clientAuth dejarán de ser de confianza para Chrome, y los propietarios de CA cuyas jerarquías no cumplan deberán reestructurarlas o salir del almacén (Chrome Root Program Policy).

Si un sitio empieza a fallar de repente en Chrome mientras clientes más antiguos lo siguen aceptando, una retirada de confianza es una explicación realista. El remedio es reemitir desde una CA que cumpla.

Por qué este error va a volverse más frecuente

La vida útil de los certificados se está desplomando. Según la votación SC-081v3 del CA/Browser Forum, aprobada en abril de 2025, el periodo máximo de validez baja de 398 días a 200 días el 15 de marzo de 2026, a 100 días en 2027 y a 47 días en 2029 (CA/Browser Forum, Ballot SC-081v3).

Vida máxima de un certificado TLS según la votación SC-081v3 del CA/Browser Forum. Fuente: CA/Browser Forum, abril de 2025.

Más renovaciones significan más ocasiones para que un script de automatización despliegue un certificado final sin su intermedio. Cada renovación es ahora un despliegue, y cada despliegue puede romper la cadena. Los equipos que renovaban a mano una vez al año y luego se olvidaban del tema se encontrarán con este error por primera vez en 2026.

Cómo verificar la solución

Después de cambiar la cadena, no te fíes de tu propio navegador. Ha guardado el intermedio en caché y te mostrará un candado verde sobre una cadena que sigue fallando para todos los demás. Verifica desde un punto limpio: un escáner externo, un teléfono con datos móviles o un perfil de navegador recién creado. Confirma que se sirven el certificado final y todos los intermedios, y que ningún intermedio está caducado.

Guías relacionadas

• "La conexión no es privada": qué significa el error y cómo solucionarlo cubre la pantalla de advertencia general bajo la que aparece este error.
• ERR_SSL_PROTOCOL_ERROR: qué significa y cómo solucionarlo trata los fallos de handshake que se parecen pero tienen otras causas.
• Seguridad SSL/TLS: guía completa para calificación A+ recorre la configuración de cadena, protocolos y cifrados de principio a fin.

Preguntas frecuentes

¿Es peligroso ERR_CERT_AUTHORITY_INVALID para los visitantes? Puede serlo. El navegador te está diciendo que no puede verificar con quién habla, que es exactamente la condición que crea un ataque de intermediario. En un sitio que no controlas, trátalo como una advertencia real y no continúes.

¿Por qué el sitio funciona en mi ordenador pero no para mis clientes? Los navegadores de escritorio guardan en caché los intermedios de visitas anteriores y pueden completar de memoria una cadena rota. Los dispositivos que nunca han visto el intermedio no pueden. Esa asimetría es la firma clásica de un intermedio ausente.

¿Se arregla borrando la caché del navegador? Rara vez, y solo cuando el fallo está en el dispositivo. Si la cadena está rota en el servidor, borrar la caché no cambia nada para nadie.

¿En qué se diferencia de ERR_CERT_COMMON_NAME_INVALID? AUTHORITY_INVALID significa que no se puede confiar en el emisor. COMMON_NAME_INVALID significa que el emisor sí es de confianza pero el certificado se emitió para un nombre de host distinto del que se está visitando.

¿Puedo simplemente saltarme la advertencia? En tu propio servidor de pruebas, sí. En cualquier sitio que maneje datos reales, no. Saltarla desactiva justo la protección que te avisaría de que la conexión ha sido manipulada.

Revisa tu cadena antes que tus visitantes

Un intermedio ausente es invisible desde tu escritorio y evidente para cada nuevo visitante. Ejecuta un análisis gratuito de FortifyNet y consulta tu cadena de certificados completa, el soporte de protocolos, las cabeceras de seguridad, el DNS y la autenticación de correo en unos 60 segundos. Sin registro.

---

Fuentes: CA/Browser Forum, Ballot SC-081v3; Chrome Root Program Policy; Let's Encrypt, Chains of Trust.