Cómo solucionar el error NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID es un error de protocolo de enlace TLS a nivel del navegador que ocurre cuando el certificado presentado por un servidor web no puede rastrearse hasta una Autoridad de Certificación (CA) raíz de confianza del almacén de confianza integrado del navegador. El navegador termina la conexión antes de que se intercambie cualquier dato, mostrando este error para prevenir la exposición a ataques de intermediario (MITM), interceptación de datos o tráfico de un servidor falsificado.

Esto no es una advertencia cosmética. Es un fallo de verificación criptográfica grave. El navegador ha inspeccionado la cadena de certificados, intentado validar cada eslabón hasta una raíz de confianza, y ha encontrado la cadena rota, ausente o criptográficamente inválida. Entender exactamente dónde se rompe esa cadena es la diferencia entre una solución de cinco minutos y horas de diagnóstico erróneo.

Qué Desencadena Realmente Este Error

La mayoría de la documentación enumera causas superficiales. El panorama real es más matizado, y cada causa raíz requiere una ruta de solución diferente.

Certificados Autofirmados

Un certificado autofirmado es aquel en el que el emisor y el sujeto son idénticos — el servidor firmó su propio certificado en lugar de que una CA de confianza lo firmara. Estos son estándar en entornos de desarrollo local, servidores de pruebas internos e infraestructura privada. Ningún almacén de confianza de navegador público los reconoce, por lo que la validación de la cadena falla inmediatamente.

Matiz crítico: Incluso si añades un certificado autofirmado al almacén de confianza de tu sistema operativo, algunos navegadores (especialmente Chrome en ciertas plataformas) utilizan su propio almacén de certificados y seguirán rechazándolo a menos que se configure explícitamente.

Certificado SSL/TLS Expirado

Cada certificado lleva un campo `notBefore` y `notAfter` codificado en su estructura X.509. Una vez que el reloj del sistema supera la marca de tiempo `notAfter`, el certificado es criptográficamente inválido independientemente de cómo fue emitido. Los navegadores aplican esto estrictamente.

Caso extremo: Si el reloj de tu servidor se desvía significativamente hacia adelante, un certificado que técnicamente sigue siendo válido puede aparecer como expirado para el propio servidor durante la negociación del protocolo de enlace TLS, causando este error desde el lado del servidor en lugar del lado del cliente.

Cadena de Certificados Incompleta (CA Intermedia Faltante)

Esta es la causa más comúnmente mal diagnosticada en entornos de producción. Una CA raíz de confianza no firma directamente los certificados de entidad final. Firma CAs intermedias, que luego firman tu certificado. Cuando instalas un certificado SSL en un servidor, debes instalar la cadena completa: tu certificado de entidad final más todos los certificados intermedios concatenados en orden.

Si el certificado intermedio falta en la respuesta TLS del servidor, la mayoría de los navegadores no pueden completar el recorrido de la cadena hasta una raíz de confianza. Firefox es algo más tolerante aquí porque almacena en caché los intermedios de sesiones anteriores (obtención AIA), pero Chrome y Edge fallarán completamente.

Cómo verificar: Ejecuta `openssl s_client -connect yourdomain.com:443 -showcerts` e inspecciona si se devuelve la cadena completa.

Nombre Común del Certificado o SAN No Coincidente

Si un certificado fue emitido para `www.example.com` pero el usuario está accediendo a `example.com` (o un subdominio no cubierto por un comodín), el navegador generará un error relacionado pero distinto. Sin embargo, en algunas configuraciones esto se manifiesta como un error de autoridad inválida en lugar de un error de nombre no coincidente, particularmente con formatos de certificado más antiguos que carecen de Nombres Alternativos de Sujeto (SANs).

Desviación del Reloj del Cliente

Los certificados TLS están limitados en el tiempo. Si el reloj de la máquina cliente está configurado en una fecha anterior al campo `notBefore` del certificado o posterior a su campo `notAfter`, el navegador lo rechazará. Esto es extremadamente común en máquinas virtuales, servidores recién aprovisionados o máquinas que han estado apagadas durante períodos prolongados sin sincronización NTP.

Inspección SSL por Software de Seguridad

Los firewalls corporativos, suites de seguridad de endpoints y algunos productos antivirus realizan inspección SSL/TLS (también llamada interceptación HTTPS). Terminan la conexión TLS en el dispositivo de seguridad, inspeccionan el texto sin formato, luego lo vuelven a cifrar usando un certificado generado dinámicamente firmado por la propia CA del dispositivo. Si esa CA del dispositivo no está en el almacén de confianza del navegador, cada sitio HTTPS desencadenará este error.

Almacén de Certificados Raíz Desactualizado

En sistemas operativos más antiguos (Windows 7 sin actualizaciones, distribuciones Linux heredadas), el paquete de CA raíz del sistema puede no incluir certificados raíz más nuevos. ISRG Root X1 de Let’s Encrypt, por ejemplo, causó errores generalizados en Android 7 e inferior y en sistemas Windows sin parches cuando la firma cruzada DST Root CA X3 expiró en septiembre de 2021.

Comparación de Causas Raíz

Soluciones Paso a Paso

Paso 1: Sincronizar la Fecha y Hora del Sistema

Esta es la solución más rápida cuando el error aparece repentinamente en una máquina que funcionaba anteriormente.

Windows:

1. Abre Configuración > Hora e idioma > Fecha y hora.
2. Activa Establecer hora automáticamente y Establecer zona horaria automáticamente.
3. Haz clic en Sincronizar ahora bajo “Sincronizar tu reloj”.
4. Si la sincronización automática falla, abre el Símbolo del sistema como Administrador y ejecuta: `w32tm /resync /force`

macOS:

1. Abre Configuración del Sistema > General > Fecha y hora.
2. Activa Establecer fecha y hora automáticamente y selecciona un servidor NTP cercano (p. ej., `time.apple.com`).
3. Si el problema persiste, ejecuta en Terminal: `sudo sntp -sS time.apple.com`

Linux (servidor o escritorio):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

Después de sincronizar, reinicia el navegador e inténtalo de nuevo.

Paso 2: Limpiar Caché del Navegador, Cookies y Certificados en Caché

Los navegadores almacenan en caché las políticas HSTS (HTTP Strict Transport Security) y los datos de certificados. Una entrada de caché obsoleta puede perpetuar un error incluso después de que el problema subyacente se haya resuelto.

Google Chrome:

1. Navega a `chrome://settings/clearBrowserData`.
2. Establece el intervalo de tiempo en Todo el tiempo.
3. Marca Cookies y otros datos de sitios e Imágenes y archivos en caché.
4. Haz clic en Borrar datos.

Para limpiar la caché específica de HSTS en Chrome, navega a `chrome://net-internals/#hsts`, introduce el dominio en “Eliminar políticas de seguridad del dominio” y haz clic en Eliminar.

Mozilla Firefox:

1. Abre Configuración > Privacidad y seguridad.
2. En Cookies y datos del sitio, haz clic en Limpiar datos.
3. También limpia el Contenido web en caché.

Microsoft Edge:

1. Navega a `edge://settings/clearBrowserData`.
2. Selecciona Todo el tiempo y limpia los datos en caché y las cookies.

Paso 3: Identificar y Deshabilitar la Inspección SSL

Si estás en una red corporativa o utilizas un producto de seguridad de endpoint, la inspección SSL es el principal sospechoso.

1. Haz clic en el icono del candado (o icono de advertencia) en la barra de direcciones del navegador.
2. Inspecciona los detalles del certificado. Si el emisor es tu proveedor de antivirus (p. ej., “Avast Root”, “Kaspersky Anti-Virus”, “ESET SSL Filter CA”) en lugar de una CA pública como DigiCert, Let’s Encrypt o Sectigo, la inspección SSL está activa.
3. En la configuración de tu antivirus o firewall, localiza Análisis HTTPS, Filtrado SSL o Web Shield y desactívalo.
4. Alternativamente, añade el certificado CA raíz del dispositivo al almacén de confianza de tu navegador.

No desactives permanentemente tu software de seguridad. Vuelve a activarlo después de las pruebas, o configúralo para excluir dominios de confianza específicos.

Paso 4: Verificar y Reparar la Cadena de Certificados del Lado del Servidor (Administradores de Servidor)

Esta es la solución correcta para sitios web de producción donde los visitantes están viendo el error.

Diagnosticar la cadena:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

O usa la inspección completa de la cadena:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Cuenta los certificados devueltos. Deberías ver al menos dos (entidad final + intermedio). Si solo aparece uno, falta el intermedio.

Solución en Apache (`httpd.conf` o archivo de host virtual):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Solución en Nginx (`nginx.conf` o bloque de servidor):

Nginx requiere que la cadena completa se concatene en un único archivo:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Luego referenciarlo:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

Después de editar, siempre prueba la configuración antes de reiniciar:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Luego recarga el servicio:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Si estás ejecutando un entorno administrado, un VPS con cPanel proporciona una interfaz GUI en el Administrador SSL/TLS donde puedes pegar el certificado, la clave privada y el paquete CA directamente sin tocar los archivos de configuración manualmente.

Paso 5: Renovar o Reemplazar un Certificado Expirado

Si el certificado ha expirado, no hay solución del lado del cliente. El servidor debe presentar un certificado válido.

Para Let’s Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Para certificados gestionados manualmente: Obtén un nuevo certificado de tu CA, súbelo a través de tu panel de control y asegúrate de que la cadena del nuevo certificado esté completa. Si necesitas un certificado de confianza para un dominio de producción, los Certificados SSL de una CA reconocida eliminan el problema del certificado autofirmado por completo.

Automatizar las renovaciones: Los certificados de Let’s Encrypt expiran cada 90 días. Añade un trabajo cron o usa temporizadores systemd para automatizar la renovación:

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Paso 6: Confiar en un Certificado Autofirmado para Uso Interno

Si estás ejecutando herramientas internas, un servidor de desarrollo o un servicio de red privada donde reemplazar el certificado no es factible, puedes añadir el certificado autofirmado al almacén de confianza del SO.

Windows:

1. Exporta el certificado desde el navegador (haz clic en la advertencia > Certificado > Detalles > Copiar en archivo).
2. Abre `certmgr.msc`.
3. Navega a Autoridades de certificación raíz de confianza > Certificados.
4. Haz clic derecho > Todas las tareas > Importar e importa el certificado.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Importante: Chrome en Linux y Windows utiliza el almacén de confianza del SO para la mayoría de los propósitos, pero también mantiene su propia base de datos NSS. Si Chrome sigue rechazando el certificado después de actualizar el almacén del SO, impórtalo directamente a través de `chrome://settings/certificates`.

Paso 7: Actualizar el Navegador y el Sistema Operativo

Un navegador desactualizado puede carecer de certificados CA raíz más nuevos o puede no admitir las versiones actuales del protocolo TLS (ahora se requiere un mínimo de TLS 1.2; se prefiere TLS 1.3).

Chrome: Navega a `chrome://settings/help`. Chrome se actualiza automáticamente; si hay una actualización pendiente, se instalará aquí.

Firefox: Navega a Ayuda > Acerca de Firefox. Firefox buscará y aplicará actualizaciones.

Sistema Operativo: En Windows, asegúrate de que Windows Update esté al día. En servidores Linux, ejecuta:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Esto es particularmente importante para servidores que ejecutan distribuciones más antiguas donde el paquete de CA (`ca-certificates`) no se ha actualizado para incluir las CA raíz más nuevas.

Paso 8: Restablecer la Pila de Red y Vaciar DNS

Las configuraciones incorrectas a nivel de red, las cachés DNS corruptas o las entradas Winsock obsoletas pueden contribuir ocasionalmente a fallos en la negociación TLS.

Windows (ejecutar Símbolo del sistema como Administrador):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Reinicia la máquina después de ejecutar estos comandos.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Paso 9: Omitir la Advertencia (Solo para Pruebas)

Esta es estrictamente una herramienta de diagnóstico, no una solución. Úsala solo para confirmar que el error está relacionado con el certificado y no con un problema de red o aplicación, o cuando accedas a un servidor interno conocido como seguro durante el desarrollo.

Chrome: Haz clic en Avanzado en la página de error, luego en Continuar a [dominio] (no seguro).

Firefox: Haz clic en Avanzado, luego en Aceptar el riesgo y continuar.

Nunca omitas esta advertencia en sitios que manejen autenticación, pagos o datos personales. La advertencia existe porque la conexión está genuinamente sin verificar.

Verificar la Solución

Después de aplicar cualquier cambio del lado del servidor, valida el resultado usando estas herramientas antes de declarar el problema resuelto:

• Prueba SSL de SSL Labs (`ssllabs.com/ssltest/`): Proporciona un análisis completo de la cadena, calificación de soporte de protocolo e identifica debilidades específicas de configuración.
• `openssl s_client`: Verificación por línea de comandos que muestra exactamente lo que el servidor está presentando durante el protocolo de enlace TLS.
• `curl -vI https://yourdomain.com`: Verificación rápida que muestra los detalles del protocolo de enlace TLS y el resultado de la validación del certificado.
• `whatsmychaincert.com`: Diagnostica específicamente los certificados intermedios faltantes.

Elegir la Infraestructura de Alojamiento Correcta para Prevenir Recurrencias

Muchos errores de certificados provienen de limitaciones de infraestructura más que de errores del administrador. Los entornos de alojamiento compartido a veces restringen cómo se configuran las cadenas de certificados o limitan el acceso a los archivos de configuración del servidor web. Si encuentras repetidamente problemas de cadena o renovación, migrar a un entorno de Alojamiento VPS te da control total sobre tu pila TLS — incluyendo la capacidad de configurar Nginx o Apache directamente, automatizar las renovaciones de Certbot e instalar paquetes CA personalizados.

Para cargas de trabajo de alto tráfico o sensibles al cumplimiento donde la gestión de certificados es crítica, los Servidores Dedicados eliminan las variables de múltiples inquilinos que pueden complicar la configuración SSL. Si gestionas múltiples dominios o subdominios, un Panel de Control VPS simplifica el despliegue de certificados en todos ellos desde una única interfaz.

Matriz de Decisión: Qué Solución Aplica a Tu Situación

Lista de Verificación de Puntos Clave Prácticos

• Confirma si el error es del lado del cliente (reloj, caché, inspección SSL) o del lado del servidor (certificado expirado, intermedio faltante) antes de tomar cualquier acción.
• Ejecuta `openssl s_client -connect domain:443 -showcerts` como primer paso de diagnóstico para cualquier investigación del lado del servidor.
• Siempre concatena la cadena de certificados completa (entidad final + todos los intermedios) en la configuración de tu servidor web.
• Automatiza la renovación de certificados con trabajos cron de Certbot o equivalente — la renovación manual es un camino garantizado hacia futuras interrupciones.
• Después de cualquier cambio de certificado, valida con SSL Labs antes de cerrar el incidente.
• Nunca deshabilites permanentemente el análisis SSL del antivirus; en su lugar, configura exclusiones o instala correctamente el certificado CA del proxy.
• En servidores Linux, mantén actualizados los paquetes `ca-certificates` y `openssl` para asegurarte de que el almacén raíz refleje las CAs de confianza actuales.
• Usa `chrome://net-internals/#hsts` para limpiar las entradas de caché HSTS cuando el certificado de un dominio ha sido cambiado legítimamente y Chrome sigue negándose a conectarse.

Preguntas Frecuentes

¿Cuál es la diferencia entre NET::ERR_CERT_AUTHORITY_INVALID y NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` significa que el emisor del certificado no es de confianza — la cadena no puede verificarse. `ERR_CERT_COMMON_NAME_INVALID` significa que el certificado es de una CA de confianza pero fue emitido para un dominio diferente al que se está accediendo. Requieren soluciones diferentes: el primero requiere un nuevo certificado de una CA de confianza o reparación de la cadena; el segundo requiere un certificado reemitido con los Nombres Alternativos de Sujeto correctos.

¿Puede aparecer NET::ERR_CERT_AUTHORITY_INVALID incluso con un certificado SSL válido y de pago?

Sí. Un certificado de pago de una CA de confianza seguirá desencadenando este error si el certificado intermedio no está incluido en la respuesta TLS del servidor. El navegador no siempre puede obtener los intermedios faltantes automáticamente (la obtención AIA no es confiable), por lo que la cadena debe configurarse explícitamente en el servidor.

¿Por qué aparece este error solo en Chrome pero no en Firefox?

Firefox mantiene su propio almacén de confianza de certificados y también almacena en caché los certificados intermedios de conexiones exitosas anteriores (un mecanismo llamado obtención AIA con caché). Chrome depende más estrictamente del almacén de confianza del SO y de la cadena presentada por el servidor. Un intermedio faltante que Firefox ha almacenado en caché de una sesión anterior seguirá causando que Chrome falle.

¿Es seguro hacer clic en “Continuar de todos modos” en la advertencia NET::ERR_CERT_AUTHORITY_INVALID?

Solo en escenarios controlados: acceder a un servidor interno conocido, un entorno de desarrollo local o un servidor de pruebas que administras. En cualquier sitio público — especialmente aquellos que requieren credenciales de inicio de sesión, información de pago o datos personales — continuar es genuinamente peligroso. La conexión no está cifrada desde una perspectiva de confianza, lo que significa que cualquier interceptor en la ruta de red puede leer o modificar el tráfico.

¿Cómo puedo evitar que este error se repita en mi servidor de producción?

Automatiza la renovación de certificados (Certbot con un trabajo cron o temporizador systemd), monitorea la expiración de certificados con una herramienta externa (UptimeRobot, Zabbix o `ssl-cert-check`), siempre despliega la cadena de certificados completa y mantén activa la sincronización NTP de tu servidor. Para entornos donde la gestión manual es propensa a errores, considera una plataforma de alojamiento con gestión integrada de certificados — un VPS con cPanel gestiona las renovaciones AutoSSL automáticamente en todos los dominios alojados.