ERR_CERT_AUTHORITY_INVALID: solución en Chrome y Android

¿Qué es NET::ERR_CERT_AUTHORITY_INVALID?

NET::ERR_CERT_AUTHORITY_INVALID significa que tu navegador no confía en quien emitió el certificado del sitio web. Chrome muestra «La conexión no es privada» y, en Avanzado, dice que el servidor «no ha podido demostrar que es example.com» porque su certificado de seguridad no es de confianza, y que esto «puede deberse a una configuración incorrecta o a que un atacante ha interceptado la conexión». Chromium lo registra como el error -202 (net_error_list.h).

La conexión se estableció, el servidor envió su certificado y el navegador no pudo vincularlo con una autoridad de certificación (CA) de confianza. Las propias notas de Chromium dan tres motivos: un atacante sustituyó el certificado, el sitio usa una CA que el navegador no conoce o el certificado es autofirmado.

Si un certificado tiene varios problemas, Chrome muestra solo el más grave, y un emisor sin confianza pesa más que un nombre incorrecto o una fecha caducada. Por eso un certificado autofirmado que además ha caducado muestra este código y no ERR_CERT_DATE_INVALID.

Cómo se ve ERR_CERT_AUTHORITY_INVALID en cada navegador

Cada navegador lo expresa a su manera. Busca estos mensajes:

Cómo funciona la confianza en certificados SSL (cadena de confianza)

Todo certificado cuelga de una cadena de confianza que termina en un certificado raíz de una autoridad de certificación en la que el navegador ya confía.

Al conectarte, el servidor envía su propio certificado y uno o más intermedios. El navegador comprueba que el certificado del sitio esté firmado por el intermedio, y el intermedio por una raíz de su lista. Chrome ya no usa para esto la lista de tu sistema operativo: lleva la suya, la Chrome Root Store, en Windows y macOS desde Chrome 108 y en Android desde Chrome 115 (no en iPhone ni iPad, donde es obligatoria la lista de Apple). Esa lista tiene unas 100 raíces y se actualiza en segundo plano (Chrome Root Store). En Windows y macOS, Edge incluye la lista de Microsoft; Firefox, la de Mozilla; y todos confían además en las raíces que tú o tu empresa añadáis al equipo.

Si falta un eslabón o es desconocido, aparece este error (más en qué es una cadena de certificados SSL). La cadena tiene cuatro partes:

• CA raíz — autofirmada e incluida en la lista de raíces del navegador
• CA intermedia — firmada por la raíz; el servidor debe enviarla. Chrome descarga la que falte desde la dirección que figura en el certificado, pero curl, las aplicaciones y muchos otros clientes no pueden
• Certificado del sitio — firmado por el intermedio, para los nombres de su lista de Nombres alternativos del sujeto
• Validación — el navegador recorre la cadena desde el certificado del sitio hasta una raíz de confianza; todas las firmas deben ser correctas

¿Qué causa NET::ERR_CERT_AUTHORITY_INVALID?

Dónde lo ves acota la causa: si es en un solo sitio, el problema casi siempre es el certificado de ese sitio. Si es en todos los sitios HTTPS, es tu dispositivo o tu red.

Soluciones para visitantes (lado del cliente)

Si ves el error en un sitio que no gestionas, prueba esto en orden. Nunca escribas una contraseña ni el número de una tarjeta en una página que muestre esta advertencia.

Solución 1: inicia sesión en el Wi-Fi o prueba otra red

El Wi-Fi de hoteles, aeropuertos y cafeterías suele interceptar tus primeras conexiones para mostrar una página de acceso, y entonces un sitio HTTPS recibe el certificado de la red en lugar del suyo. La ayuda de Chrome dice que esas redes exigen iniciar sesión y que visitar una página con http:// abre la página de acceso; Chrome también puede mostrar la página «Conectarse a una red Wi-Fi» en lugar de este error. Acepta el acceso y recarga.

Las redes de empresas y centros educativos también pueden inspeccionar el HTTPS con su propio certificado. Si el error desaparece con datos móviles, consulta al equipo de TI de la red: los dispositivos que gestionan suelen tener instalada su raíz, y es posible que el tuyo no.

Solución 2: revisa el análisis HTTPS del antivirus

Antivirus como Kaspersky, Avast, ESET y Bitdefender pueden analizar el HTTPS descifrándolo con su propio certificado y volviéndolo a cifrar. Si tu navegador no confía en su certificado raíz, o la función falla tras una actualización, todos los sitios HTTPS muestran este error a la vez.

Para comprobarlo, pausa solo la función de análisis HTTPS o web y recarga. Si el error desaparece, repara o actualiza el antivirus para que reinstale su certificado, o deja desactivado el análisis HTTPS.

Solución 3: actualiza el navegador y el sistema operativo

Los navegadores y los sistemas operativos actualizan sus listas de raíces con regularidad (Chrome mediante actualizaciones de componentes en segundo plano), y los sistemas antiguos no tienen las raíces más recientes. Las versiones de Android anteriores a la 7.1.1, por ejemplo, no confían en ISRG Root X1, así que los sitios de Let's Encrypt fallan en los navegadores y aplicaciones que usan la lista del sistema.

Actualiza primero el navegador: Chrome y Edge llevan sus propias listas de raíces en Windows y macOS, y Chrome también en Android desde la versión 115. Después actualiza el sistema operativo.

Solución 4: revisa la fecha y la hora

Un reloj desfasado meses o años hace que los certificados parezcan aún no válidos o caducados. Chrome suele mostrar para eso otra advertencia («Tu reloj está atrasado» o ERR_CERT_DATE_INVALID), pero un reloj muy desajustado tras agotarse la pila CMOS o restaurar una máquina virtual también puede romper la comprobación de confianza. Descartarlo lleva diez segundos.

Windows: Configuración → Hora e idioma → Fecha y hora → activa Ajustar hora automáticamente. macOS: Ajustes del Sistema → General → Fecha y hora → Ajustar hora y fecha automáticamente. Android: Ajustes → Sistema → Fecha y hora → Establecer hora automáticamente (en Android 16 se llama Fecha y hora automáticas).

Solución 5: prueba en incógnito y reinicia el navegador

Una ventana de incógnito (Ctrl+Shift+N en Chrome y Edge, Ctrl+Shift+P para una ventana privada en Firefox) funciona sin tus extensiones, salvo que las hayas permitido. Las extensiones de VPN y proxy pueden enviar tu tráfico por un servidor que presenta su propio certificado; si el sitio funciona en incógnito, desactiva las extensiones en chrome://extensions y vuelve a activarlas de una en una.

Si el sitio acaba de arreglar su certificado, cierra todas las ventanas del navegador y ábrelo de nuevo, para que compruebe el nuevo desde cero.

Solución 6: en Android

Android añade algunas comprobaciones propias:

• Establece la fecha y la hora automáticamente: Ajustes → Sistema → Fecha y hora.
• Actualiza Chrome y Android System WebView desde Play Store. Las aplicaciones que muestran páginas web mediante WebView comprueban los certificados con la lista de raíces del propio Android, así que una versión antigua de Android aún puede fallar ahí.
• Desactiva las aplicaciones de VPN, bloqueo de anuncios o «navegación segura» que filtran el HTTPS; muestran un icono de llave o de VPN en la barra de estado.
• Inicia sesión en el Wi-Fi: las redes públicas muestran el error hasta que aceptas su página de acceso.
• En Android anterior a la 7.1.1, la raíz de Let's Encrypt no está en la lista del sistema, así que las aplicaciones y navegadores que dependen de ella no pueden verificar esos sitios. Un navegador que lleve su propia lista de raíces es la única solución.

Soluciones para propietarios de sitios web (lado del servidor)

Si los visitantes notifican NET::ERR_CERT_AUTHORITY_INVALID en tu sitio, el certificado que sirves normalmente no enlaza con una raíz pública. Compruébalo primero con el SSL Checker y corrige lo que encuentre. Si muestra un certificado distinto del que instalaste, confirma con DNS Lookup que el dominio apunta al servidor que crees, y con el HTTP Header Checker qué servidor responde.

Solución 1: instala un certificado de una CA de confianza

Los navegadores de los visitantes nunca confiarán en un certificado autofirmado, ni en uno de tu propia CA: el firmante no está en ninguna lista pública de raíces.

Instala en su lugar un certificado de una CA de confianza pública. Let's Encrypt emite certificados gratuitos y automatizados en los que confían todos los navegadores principales; DigiCert, Sectigo y GlobalSign venden certificados con validación de organización y soporte.

# Install Let's Encrypt certificate with Certbot (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Install Let's Encrypt certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

# Verify the installed certificate
sudo certbot certificates

Solución 2: envía la cadena de certificados completa

Tu certificado puede ser perfectamente válido y que el servidor olvide enviar el intermedio. Chrome suele disimularlo descargando él mismo el intermedio que falta, así que el sitio funciona en Chrome y falla en curl, aplicaciones, callbacks de pago y algunos teléfonos.

Pasa el sitio por el SSL Checker de DNS Robot: muestra la cadena que envía tu servidor y si Mozilla, Chrome, Apple y Microsoft confían en ella. O comprueba desde una 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]:'

# letsencrypt.org on 26 Oct 2026, a complete chain:
#  0 s:CN=letsencrypt.org
#    i:C=US, O=Let's Encrypt, CN=YE2
#  1 s:C=US, O=Let's Encrypt, CN=YE2
#    i:C=US, O=ISRG, CN=Root YE
#  2 s:C=US, O=ISRG, CN=Root YE
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#  3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
# Only certificate 0 listed = the intermediate is missing.

# nginx: point ssl_certificate at the full chain, not the leaf alone
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache 2.4.8+
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Solución 3: renueva un certificado expirado

Un certificado caducado de una CA de confianza muestra ERR_CERT_DATE_INVALID, no este error. Verás ERR_CERT_AUTHORITY_INVALID solo si además la cadena no es de confianza, porque Chrome informa del problema más grave. En cualquier caso, comprueba las fechas y renueva:

# Check the certificate's dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
# notBefore=Sep 30 12:00:00 2026 GMT
# notAfter=Dec 29 11:59:59 2026 GMT

# Renew now with Certbot, then reload the web server
sudo certbot renew --force-renewal
sudo systemctl reload nginx    # or apache2

Solución 4: cubre todos los nombres que usan los visitantes

Un certificado de confianza que no incluye el nombre de la barra de direcciones muestra en cambio ERR_CERT_COMMON_NAME_INVALID. Solo se convierte en este error cuando además el certificado no es de confianza, así que arregla primero la confianza y después los nombres.

Los navegadores comprueban únicamente la lista de Nombres alternativos del sujeto, no el antiguo Common Name. Un comodín (*.example.com) cubre un nivel de subdominios pero no example.com en sí, así que incluye ambos al solicitarlo. El SSL Checker muestra la lista completa de nombres de un certificado.

Solución 5: usa una CA privada o de empresa

Los sitios internos suelen usar una CA de empresa a propósito. Eso solo funciona en los dispositivos donde está instalado el certificado raíz de la empresa, y Chrome y Edge confían en una raíz añadida a Windows o macOS (Chrome Root Store FAQ). Distribúyela con directiva de grupo o con tu herramienta de gestión de dispositivos, o añádela a mano:

# Windows (Command Prompt as Administrator): trust for all users
certutil -addstore -f Root company-root.crt

# macOS: trust in the System keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root.crt

ERR_CERT_AUTHORITY_INVALID en localhost (desarrolladores)

Un servidor HTTPS local con un certificado autofirmado muestra este error por diseño. En lugar de hacer clic para continuar, haz que el certificado sea de confianza en tu propio equipo:

• mkcert — mkcert -install crea una CA local y la añade al almacén de confianza del sistema (y al de Firefox, una vez instalado certutil de NSS); después mkcert localhost 127.0.0.1 ::1 genera un certificado en el que confían Chrome, Edge y Firefox
• Next.js — next dev --experimental-https crea por ti un certificado de confianza local con mkcert
• Vite — @vitejs/plugin-basic-ssl genera un certificado sin confianza, así que seguirás viendo este error; apunta server.https a los archivos de mkcert
• Consejos antiguos que ya no funcionan — el interruptor chrome://flags/#allow-insecure-localhost caducó después de Chrome 130 y ya no está en chrome://flags

# Install mkcert (macOS)
brew install mkcert
mkcert -install

# Generate localhost certificate
mkcert localhost 127.0.0.1 ::1
# Creates: localhost+2.pem and localhost+2-key.pem

# Use with Node.js
const https = require('https');
const fs = require('fs');
https.createServer({
  cert: fs.readFileSync('localhost+2.pem'),
  key: fs.readFileSync('localhost+2-key.pem')
}, app).listen(3000);

Errores de certificado SSL relacionados

NET::ERR_CERT_AUTHORITY_INVALID es uno de los varios errores de certificado que hay detrás de la página «La conexión no es privada» de Chrome. Cada código apunta a una comprobación distinta: