Error Su Conexión No Es Privada (SSL): Cómo Diagnosticar y Resolver
Resuelve el error NET::ERR_CERT_AUTHORITY_INVALID y variantes SSL en el navegador identificando la causa real — certificado, cadena, fecha o DNS.
El aviso “Su conexión no es privada” en Chrome (o “Advertencia: riesgo potencial de seguridad por delante” en Firefox) es una de las pantallas más ambiguas de la web moderna. Detrás de un único mensaje amigable, el navegador esconde más de quince códigos de error distintos — cada uno apuntando a una causa raíz diferente. Tratar todos como el mismo problema lleva a intentos equivocados: renovar un certificado que está válido, tocar el DNS cuando el problema es el reloj, o peor, instruir al usuario final a hacer clic en “Avanzar” y exponer la conexión.
Esta guía es para quien opera un servidor propio (VPS o bare-metal) y necesita identificar rápidamente cuál es el problema real, separar lo que es responsabilidad del servidor de lo que es del cliente, y aplicar la corrección correcta. El proceso completo lleva entre 10 y 20 minutos, dependiendo de la causa.
La premisa fundamental: el error SSL siempre es específico. Antes de tocar cualquier configuración, necesitas leer el código exacto que el navegador muestra y decidir el camino de diagnóstico.
Prerrequisitos
Acceso SSH al servidor (sudo o root), navegador actualizado (Chrome 117+ o Firefox 120+) y herramientas de línea de comando openssl, curl y dig instaladas. En Ubuntu/Debian: sudo apt install -y openssl curl dnsutils. Conocimiento básico de cómo está configurado tu servidor web (nginx, Apache o Caddy).
443 /etc/letsencrypt/live/dominio/ fullchain.pem Identifica el código de error exacto
Antes de tocar cualquier cosa, abre la página del error en el navegador y haz clic en “Avanzado” (Chrome) o “Detalles técnicos” (Firefox). Verás un código en el formato NET::ERR_CERT_* o SEC_ERROR_*. Ese código es el punto de partida — cada uno exige tratamiento diferente.
La tabla siguiente cubre los más comunes:
| Código | Causa probable | Dónde corregir |
|---|---|---|
NET::ERR_CERT_AUTHORITY_INVALID | CA no confiable o cadena incompleta | Servidor |
NET::ERR_CERT_DATE_INVALID | Certificado expirado o reloj equivocado | Servidor o cliente |
NET::ERR_CERT_COMMON_NAME_INVALID | Certificado para otro dominio | Servidor |
NET::ERR_CERT_REVOKED | Certificado revocado por la CA | Servidor (reemitir) |
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM | Algoritmo SHA-1 obsoleto | Servidor (reemitir SHA-256+) |
SSL_ERROR_BAD_CERT_DOMAIN | Dominio accedido no coincide con SAN | Servidor |
NET::ERR_SSL_PROTOCOL_ERROR | TLS handshake falló (versión/cipher) | Servidor |
Anota el código exacto del error y el dominio (incluyendo subdominio) donde aparece. La diferencia entre www.sitio.com y sitio.com es crítica — un certificado emitido solo para uno no cubre el otro automáticamente.
Prueba en otro dispositivo en la misma red y en una red diferente (4G del celular, por ejemplo). Si el error aparece en todos, es problema del servidor. Si aparece solo en uno, es local.
Diagnostica del lado del servidor
Usa openssl s_client para ver exactamente lo que el servidor está presentando al navegador. Ese comando es el equivalente técnico de “abrir la página” — sin caché, sin extensiones, sin ambigüedad.
Conéctate a tu dominio y captura la cadena completa:
openssl s_client -connect dominio.com:443 \
-servername dominio.com \
-showcerts < /dev/nullLa flag -servername es obligatoria — sin ella, servidores con múltiples sitios (SNI) pueden entregar el certificado equivocado. La salida lista cada certificado servido entre -----BEGIN CERTIFICATE----- y -----END CERTIFICATE-----.
Verifica cuántos certificados aparecen. En una configuración saludable ves al menos 2: el leaf (de tu dominio) y el intermediario (de la CA). Si aparece solo 1, la cadena está incompleta — esa es la causa más común de NET::ERR_CERT_AUTHORITY_INVALID en servidores que “funcionaban hasta la semana pasada”.
Extrae fecha de validez y dominios cubiertos:
echo | openssl s_client -connect dominio.com:443 \
-servername dominio.com 2>/dev/null | \
openssl x509 -noout -dates -subject -ext subjectAltNameDebes ver notBefore y notAfter (validez), el subject (dominio principal) y la lista de SAN (Subject Alternative Names — todos los dominios que el cert cubre).
No intentes renovar un certificado antes de confirmar que el problema es validez. Renovar un certificado que está válido pero con cadena incompleta no resuelve nada — solo vas a cambiar un leaf válido por otro leaf válido, manteniendo el problema real.
Corrige problemas de cadena incompleta
Cadena incompleta es el error de configuración más común en servidores Linux. Generaste el certificado, lo copiaste a nginx, y todo parece OK — pero el servidor está sirviendo solo el leaf, sin el intermediario.
En servidores nginx con Let’s Encrypt, la directiva ssl_certificate debe apuntar a fullchain.pem, no a cert.pem:
ssl_certificate /etc/letsencrypt/live/dominio.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/dominio.com/privkey.pem;El fullchain.pem es la concatenación del leaf + intermediario(s) en el orden correcto. El cert.pem contiene solo el leaf — usarlo rompe clientes que no cachean el intermediario (buena parte de los Android antiguos, sistemas embebidos, algunos sistemas operativos corporativos).
Recarga la configuración sin reiniciar:
sudo nginx -t && sudo systemctl reload nginxEl nginx -t valida la sintaxis antes del reload — si falla, tu configuración antigua sigue corriendo.
En Apache, la directiva equivalente es SSLCertificateFile, y desde la versión 2.4.8 acepta el fullchain. En versiones más antiguas necesitas SSLCertificateChainFile apuntando separadamente al intermediario. Confirma tu versión con apache2 -v (Debian/Ubuntu) o httpd -v (RHEL/CentOS).
Corrige problemas de fecha y reloj
Si el código es NET::ERR_CERT_DATE_INVALID, hay dos posibilidades: el certificado realmente expiró (servidor) o el reloj del cliente está equivocado (local). Diferenciar es directo.
En el servidor, verifica la hora actual y el servicio NTP:
timedatectl statusBusca System clock synchronized: yes y NTP service: active. Si alguno está no o inactive:
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncdServidores virtuales que quedaron suspendidos por mucho tiempo (snapshot restaurado, migración entre nodos) frecuentemente despiertan con reloj desfasado — el certificado válido queda aparentemente expirado hasta que el NTP sincronice.
Compara la fecha del servidor con la validez del certificado:
date -u
echo | openssl s_client -connect dominio.com:443 \
-servername dominio.com 2>/dev/null | \
openssl x509 -noout -enddateSi la fecha actual es posterior al notAfter, el certificado expiró — renueva. Si es anterior al notBefore, el certificado fue emitido para el futuro (raro, generalmente error de timezone en el momento de la emisión).
Verifica si la corrección funcionó
Después de aplicar el fix, valida en tres capas — servidor, cadena pública y navegador real.
Limpia el caché del navegador y prueba en ventana de incógnito. Caché de certificados es agresivo: Chrome puede retener un certificado antiguo por hasta 24 horas en algunos casos. Ventana de incógnito ignora buena parte de ese caché.
Ejecuta una prueba externa vía SSL Labs:
curl -sI https://api.ssllabs.com/api/v3/analyze?host=dominio.comO abre https://www.ssllabs.com/ssltest/analyze.html?d=dominio.com en el navegador. Quieres nota A o A+. Notas B/C indican problemas adicionales (protocolos débiles, ciphers obsoletos) que vale corregir aunque el error principal ya haya desaparecido.
Validar solo en Chrome de tu escritorio no es suficiente. Prueba al menos en: Firefox (store de CA independiente), Safari iOS (validación más rigurosa) y curl de línea de comando (curl -v https://dominio.com). Si los tres funcionan sin warning, tu configuración está sólida.
Resolución de problemas frecuentes
Error solo aparece en www pero no en la raíz (o viceversa)
Tu certificado cubre solo uno de los dos. Reemite incluyendo ambos nombres. Con certbot:
sudo certbot --nginx -d dominio.com -d www.dominio.comEl -d acepta múltiples dominios en una única solicitud — van al mismo certificado vía SAN.
Error después de instalar antivirus o proxy corporativo
Antivirus que hacen inspección TLS (Kaspersky, BitDefender, ESET) instalan una CA propia en la máquina y refirman todo el tráfico HTTPS. Si esa CA no está en el trust store del navegador, todo sitio se rompe. Solución: deshabilitar inspección SSL en el antivirus o aceptar la CA de él manualmente. En redes corporativas con proxy (Zscaler, Forcepoint), el equipo de TI necesita distribuir la CA de la empresa vía política de grupo.
Renovación automática dejó de funcionar
Verifica el cron del certbot y los logs:
sudo systemctl status certbot.timer
sudo journalctl -u certbot --since "30 days ago"Causas comunes: puerto 80 bloqueado en el firewall (challenge HTTP-01 falla), DNS apuntando a IP equivocada después de migración, o rate limit de Let’s Encrypt (5 fallas por hora por el mismo dominio).
Próximos pasos
Después de resolver el error inmediato, vale endurecer la configuración TLS para evitar recurrencia. Considera habilitar HSTS (HTTP Strict Transport Security) con Strict-Transport-Security: max-age=31536000; includeSubDomains — eso fuerza al navegador a usar HTTPS por un año y elimina ataques de downgrade. Monitorea expiración de certificados con herramientas como Uptime Kuma o un cron simple que dispare alerta 14 días antes del notAfter. Para sitios con tráfico serio, habilita OCSP stapling (ssl_stapling on en nginx) — reduce latencia de la primera conexión y disminuye dependencia de las CAs.
Si estás poniendo esto en producción, una VPS Hostini ya viene con certbot preinstalado y renovación automática configurada — solo apuntas el DNS y ejecutas el comando de emisión.
Preguntas frecuentes
¿Por qué el error aparece solo en algunos navegadores y en otros no?
Cada navegador mantiene su propia lista de autoridades certificadoras raíz confiables. Chrome y Edge usan el store del sistema operativo, Firefox tiene store propio. Si el certificado fue emitido por una CA que Firefox conoce pero Windows no, solo Chrome se quejará. También influye: política de revocación (Chrome respeta CRLite, Firefox usa OCSP) y soporte a algoritmos más antiguos.
El candado verde en Chrome desapareció pero el sitio funciona — ¿el certificado está válido?
No necesariamente. Chrome 117+ removió el ícono de candado de la UI por defecto y muestra solo un ícono neutro de configuraciones. Haz clic en el ícono y mira Conexión es segura para confirmar. Si aparece No segura o un triángulo amarillo, hay problema real — generalmente contenido mixto (HTTPS cargando recurso HTTP) o certificado venciendo en menos de 7 días.
NET::ERR_CERT_AUTHORITY_INVALID en servidor con Let's Encrypt funcionando hace meses — ¿qué cambió?
Casi siempre es cadena intermedia incompleta tras renovación. Let's Encrypt cambió la raíz cruzada (ISRG Root X1 vs DST Root CA X3) en 2024, y configuraciones antiguas que servían solo el leaf sin el intermediario R3 se rompieron en clientes Android antiguos y algunos sistemas. Sirve el fullchain.pem (no el cert.pem) en la directiva ssl_certificate.
El error aparece en una máquina específica de la red y en ninguna más — ¿es problema del servidor?
No. Si una única máquina ve el error mientras las otras en la misma red acceden normal, el problema es local: reloj fuera de sincronía, antivirus interceptando TLS (Kaspersky, BitDefender, ESET lo hacen), proxy corporativo con CA propia no instalada, o extensión de navegador interfiriendo. Empieza por el reloj.
¿Cómo verifico si la cadena de certificados está completa antes de subir a producción?
Usa openssl s_client -connect dominio.com:443 -servername dominio.com -showcerts. La salida lista todos los certificados servidos. Debes ver el leaf, el intermediario e idealmente la raíz. Si aparece solo 1 certificado, la cadena está incompleta. Herramientas como SSL Labs (ssllabs.com/ssltest) y testssl.sh dan diagnóstico más visual y detectan otros problemas (protocolos débiles, ciphers obsoletos).
¿Puedo ignorar el aviso y continuar — es seguro?
Depende de la causa. Si es tu propio servidor de pruebas con certificado autofirmado, sí. Si es un sitio público que no controlas, no. El aviso puede indicar interceptación activa por atacante (MITM en Wi-Fi público), CA comprometida o phishing. Nunca hagas clic en Continuar para sitios donde vas a escribir contraseña, tarjeta o datos sensibles.