Cómo solucionar el error “Este sitio no puede proporcionar una conexión segura”

El error "Este sitio no puede proporcionar una conexión segura" significa que tu navegador no pudo completar un protocolo de enlace TLS con el servidor de destino. El intento de conexión fue terminado antes de que pudiera establecerse cualquier canal cifrado, dejando al navegador incapaz de verificar la identidad del servidor o negociar un conjunto de cifrado.

Este error aparece en Chrome, Firefox, Edge y Safari y casi siempre va acompañado de un código de error específico — los más comunes son ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH o SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Cada código apunta a una capa de fallo distinta: la configuración del certificado del servidor, la pila TLS del cliente o la ruta de red entre ellos. Identificar qué capa es la responsable antes de modificar cualquier configuración te ahorrará tiempo significativo.

Qué Ocurre Realmente Durante un Protocolo de Enlace TLS

Antes de profundizar en las soluciones, es importante entender el mecanismo de fallo. Cuando tu navegador se conecta a un sitio HTTPS, realiza un protocolo de enlace TLS en milisegundos:

1. El navegador envía un mensaje ClientHello anunciando las versiones TLS y conjuntos de cifrado compatibles.
2. El servidor responde con un ServerHello, seleccionando una versión de protocolo y un cifrado, y luego presenta su cadena de certificados.
3. El navegador valida el certificado contra las Autoridades de Certificación (CA) raíz de confianza, comprueba la fecha de vencimiento, verifica que el dominio coincide con el Nombre Alternativo del Sujeto (SAN) y confirma que el certificado no ha sido revocado (mediante OCSP o CRL).
4. Ambas partes derivan claves de sesión y comienzan la comunicación cifrada.

Un fallo en cualquiera de estos cuatro pasos produce el mensaje "no puede proporcionar una conexión segura". El código de error en el panel de detalles del navegador te indica exactamente qué paso falló.

Causas Raíz Mapeadas a Códigos de Error

Si el código de error sitúa la responsabilidad en el administrador del servidor y tú no controlas el servidor, tus opciones se limitan a contactar al propietario del sitio. Las secciones siguientes se centran en los errores que puedes resolver en el lado del cliente, seguidos de la corrección en el lado del servidor para administradores.

Soluciones del Lado del Cliente

1. Verifica el Certificado Antes de Cambiar Cualquier Cosa

Haz clic en el candado (o el icono de advertencia) en la barra de direcciones y selecciona La conexión es segura > El certificado es válido. Comprueba:

• Período de validez: La fecha "No después de" debe ser futura.
• Emitido para: El dominio en el campo SAN del certificado debe coincidir exactamente con la URL, incluidos los subdominios.
• Emitido por: La cadena de CA debe terminar en una CA raíz en la que confíe tu sistema operativo.

Si el certificado está vencido o no coincide y no eres propietario del servidor, detente aquí y contacta al propietario del sitio. Si administras el servidor, ve a la sección del lado del servidor a continuación.

2. Sincroniza la Fecha y Hora del Sistema

La validación del certificado es sensible al tiempo. Un reloj del sistema que esté incluso unos minutos desajustado puede hacer que el navegador concluya que un certificado válido está vencido, o que se está utilizando prematuramente un certificado aún no válido.

Windows:

w32tm /resync /force

Alternativamente, haz clic derecho en el reloj del sistema, selecciona Ajustar fecha/hora y activa Establecer hora automáticamente con el servicio de hora de Windows.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Abre Configuración del Sistema > General > Fecha y hora y activa Establecer fecha y hora automáticamente.

Después de sincronizar, reinicia el navegador y vuelve a probar.

3. Limpia el Estado SSL y la Caché del Navegador

Los navegadores almacenan en caché los resultados de validación de certificados y las políticas HSTS (HTTP Strict Transport Security). Una entrada de caché obsoleta puede bloquear el acceso incluso después de que se haya resuelto un problema de certificado en el lado del servidor.

Chrome — borrar datos de navegación:

Navega a chrome://settings/clearBrowserData, selecciona Todo el tiempo, marca Cookies y otros datos del sitio y Imágenes y archivos en caché, luego haz clic en Borrar datos.

Chrome — borrar entrada HSTS para un dominio específico:

Navega a chrome://net-internals/#hsts, introduce el dominio en Eliminar políticas de seguridad del dominio y haz clic en Eliminar. Esto es especialmente útil cuando un dominio era anteriormente solo HTTPS y ahora está mal configurado.

Windows — borrar el estado SSL a nivel del sistema operativo:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Esto borra la caché de certificados utilizada por Internet Explorer, Edge (heredado) y algunas aplicaciones de Windows.

Firefox: Navega a about:preferences#privacy, desplázate hasta Cookies y datos del sitio y haz clic en Borrar datos.

4. Deshabilita la Inspección HTTPS del Antivirus

Los productos de seguridad de proveedores como Avast, AVG, Kaspersky, ESET y Bitdefender realizan interceptación SSL/TLS — actúan como un proxy local de intermediario, volviendo a firmar los certificados con su propia CA raíz. Cuando su CA raíz no está correctamente instalada en el almacén de confianza del navegador, o cuando el módulo de interceptación tiene errores, todas las conexiones HTTPS fallan.

Para comprobar si esta es la causa:

1. Deshabilita temporalmente la función Escudo Web, Análisis HTTPS o Filtrado SSL en la configuración de tu antivirus.
2. Recarga la página que falla.
3. Si el error desaparece, el antivirus es el culpable.

La solución permanente es agregar el dominio afectado a la lista de exclusiones del antivirus en lugar de deshabilitar el análisis HTTPS globalmente, lo que reduciría tu nivel de seguridad.

5. Actualiza el Navegador

El TLS moderno requiere que el navegador admita como mínimo TLS 1.2, y TLS 1.3 para una seguridad óptima. Los navegadores anteriores a aproximadamente Chrome 70, Firefox 63 o Edge 79 pueden carecer de soporte para TLS 1.3 o tener errores conocidos en el protocolo de enlace.

Chrome:

Navega a chrome://settings/help. Chrome busca actualizaciones automáticamente y las instala al reiniciar.

Firefox:

Navega a about:support, luego Buscar actualizaciones en el menú Ayuda.

Mantener el navegador actualizado también garantiza que el almacén de CA raíz integrado del navegador esté al día, lo que importa para los certificados emitidos por CA más nuevas.

6. Audita la Configuración del Protocolo TLS en el Navegador

Chrome y Edge (basados en Chromium):

Estos navegadores no exponen controles de versión TLS en la interfaz de usuario desde Chrome 84. TLS 1.0 y 1.1 están deshabilitados permanentemente. Si un sitio requiere TLS 1.0 o 1.1, el sitio debe actualizarse — no existe ninguna solución alternativa en el lado del cliente, ni debería haberla.

Para verificar indicadores TLS experimentales, navega a chrome://flags y busca TLS. En la mayoría de las versiones de producción, no aparecerán indicadores accionables.

Firefox:

Navega a about:config y busca security.tls.version.min. El valor debe ser 3 (correspondiente a TLS 1.2). Establecerlo en 1 o 2 para adaptarse a un servidor defectuoso es un riesgo de seguridad y solo debe hacerse en entornos de prueba aislados.

Internet Explorer / Edge heredado:

Navega a Opciones de Internet > Avanzado > Seguridad y asegúrate de que Usar TLS 1.2 y Usar TLS 1.3 estén marcados. Desmarca Usar SSL 3.0, Usar TLS 1.0 y Usar TLS 1.1.

7. Deshabilita o Audita las Extensiones del Navegador

Las extensiones con acceso a la red — en particular VPN, bloqueadores de anuncios, herramientas de privacidad y conmutadores de proxy — pueden interceptar o modificar las conexiones TLS. Para aislar un conflicto de extensiones:

Navega a chrome://extensions/ y deshabilita todas las extensiones. Recarga la página que falla. Si el error se resuelve, vuelve a habilitar las extensiones de una en una, recargando después de cada una, hasta identificar la extensión problemática.

8. Cambia el Resolvedor DNS

El DNS no afecta directamente a TLS, pero un resolvedor DNS que devuelve direcciones IP incorrectas (debido a envenenamiento, filtrado o interferencia del ISP) puede dirigir tu navegador a un servidor que presenta un certificado para el dominio incorrecto, causando un error ERR_CERT_COMMON_NAME_INVALID.

Cambiar a un resolvedor público elimina la manipulación DNS a nivel del ISP:

Windows — cambiar DNS mediante PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Reemplaza "Ethernet" con el nombre real de tu interfaz (usa Get-NetAdapter para listar las interfaces).

Linux:

sudo nano /etc/resolv.conf

Añade:

nameserver 1.1.1.1
nameserver 8.8.8.8

Resolvedores públicos recomendados:

9. Restablece la Pila de Red (Windows)

Un catálogo Winsock corrupto o una pila TCP/IP dañada pueden causar fallos TLS intermitentes que parecen no estar relacionados con los certificados. Ejecuta lo siguiente como Administrador:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Reinicia la máquina después de ejecutar los cinco comandos. No omitas el reinicio — netsh winsock reset en particular requiere un reinicio para surtir efecto.

Soluciones del Lado del Servidor para Administradores

Si administras el servidor web que presenta el certificado, las siguientes son las causas más comunes del lado del servidor y su corrección.

Certificado SSL Vencido o Mal Configurado

Un certificado vencido es la causa más común de este error a nivel del servidor. Si estás ejecutando un sitio en un entorno de Hosting VPS, la renovación del certificado debería estar automatizada.

Comprueba el vencimiento del certificado desde la línea de comandos:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Automatiza la renovación con Certbot (Let's Encrypt):

sudo certbot renew --dry-run

Añade un trabajo cron o un temporizador systemd para ejecutar certbot renew dos veces al día — los certificados de Let's Encrypt vencen cada 90 días, y Certbot solo renueva cuando quedan menos de 30 días.

0 0,12 * * * root certbot renew --quiet

Si necesitas un certificado validado comercialmente con validación extendida o cobertura wildcard, los Certificados SSL de una CA de confianza proporcionan la cadena de confianza requerida por todos los navegadores principales.

Cadena de Certificados Incompleta

Una configuración incorrecta muy común: el servidor presenta solo el certificado de entidad final sin los certificados CA intermedios. El navegador no puede construir una ruta de confianza hacia una CA raíz que reconozca, lo que resulta en ERR_CERT_AUTHORITY_INVALID.

Diagnóstico con SSL Labs:

Ejecuta tu dominio a través de SSL Labs Server Test (herramienta externa). Un problema de cadena se detectará de inmediato.

Solución en Nginx:

La directiva ssl_certificate debe apuntar a un archivo que contenga la cadena completa — tu certificado seguido de todos los certificados intermedios:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Solución en Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Versiones TLS Obsoletas y Conjuntos de Cifrado Débiles

Los navegadores han eliminado el soporte para TLS 1.0 y TLS 1.1. Si tu servidor solo ofrece estas versiones de protocolo, los navegadores modernos rechazarán la conexión por completo.

Configuración TLS recomendada para Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Configuración TLS recomendada para Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

Después de modificar la configuración del servidor, prueba con:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Discrepancia de Dominio en el Certificado

Si tu certificado cubre www.example.com pero los usuarios acceden a example.com (o viceversa), el navegador reportará una discrepancia de dominio. La solución correcta es emitir un certificado con ambos nombres en el campo SAN, o usar un certificado wildcard (*.example.com).

Al configurar un nuevo dominio en un entorno de Servidores Dedicados, verifica siempre que el campo SAN cubra todas las variantes de nombre de host a las que el servidor responderá antes de ponerlo en producción.

Bloqueo de Contenido Mixto

Una página cargada mediante HTTPS que hace referencia a recursos HTTP (imágenes, scripts, hojas de estilo) genera advertencias de contenido mixto. Aunque esto no produce directamente el error "no puede proporcionar una conexión segura", puede causar fallos parciales en la página que se diagnostican erróneamente como errores TLS.

Audita el contenido mixto con:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Comparación de Causas del Lado del Cliente vs. del Lado del Servidor

Consideraciones sobre el Entorno de Hosting

El entorno de hosting que utilizas influye directamente en la facilidad con la que puedes resolver problemas TLS del lado del servidor.

En el Hosting Web Compartido, la gestión de certificados se realiza normalmente a través del panel de control. La mayoría de las plataformas de hosting compartido modernas incluyen integración gratuita con Let's Encrypt, pero tienes un control limitado sobre la configuración del protocolo TLS a nivel del servidor.

En un VPS con cPanel, obtienes acceso a AutoSSL para el aprovisionamiento automatizado de certificados y puedes configurar directamente los ajustes TLS de Apache o Nginx. Este es el entorno recomendado para sitios donde la precisión en la configuración TLS es importante.

En Servidores Dedicados de metal desnudo, tienes control total sobre toda la pila TLS — versión de OpenSSL, selección de conjuntos de cifrado, grapado OCSP, precarga HSTS y fijación de certificados — pero también eres completamente responsable de mantener la configuración actualizada.

Lista de Verificación Práctica para la Toma de Decisiones

Usa esta lista de verificación para clasificar el error de forma sistemática en lugar de aplicar soluciones al azar:

• ¿El error aparece en todos los sitios HTTPS o solo en uno?
• Todos los sitios: céntrate en el reloj del sistema, el análisis HTTPS del antivirus, la actualización del navegador y el almacén de CA raíz del sistema operativo.
• Un sitio: el problema es casi con certeza del lado del servidor.

• ¿Qué indica el código de error específico?
• ERR_CERT_DATE_INVALID: comprueba primero el reloj del sistema, luego el vencimiento del certificado.
• ERR_CERT_AUTHORITY_INVALID: comprueba la completitud de la cadena de certificados.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: el servidor está ejecutando TLS obsoleto o cifrados no compatibles.
• ERR_CERT_COMMON_NAME_INVALID: el SAN del certificado no coincide con el dominio.

• ¿El error desaparece en una red diferente?
• Sí: el firewall, el proxy o la inspección TLS a nivel del ISP es la causa.

• ¿El error desaparece con el antivirus deshabilitado?
• Sí: configura una exclusión para el dominio en la configuración de análisis HTTPS del antivirus.

• ¿Eres el administrador del servidor?
• Ejecuta diagnósticos openssl s_client y la prueba de SSL Labs antes de tocar cualquier archivo de configuración.
• Automatiza la renovación del certificado inmediatamente después de resolver el problema inmediato.

Preguntas Frecuentes

¿Por qué aparece "Este sitio no puede proporcionar una conexión segura" solo en un sitio web?

Cuando el error está aislado a un único dominio, la causa raíz es casi siempre del lado del servidor: un certificado vencido, una cadena de certificados incompleta, una discrepancia en el nombre de dominio en el campo SAN del certificado, o el servidor configurado para usar solo versiones TLS obsoletas (1.0 o 1.1) que los navegadores modernos ya no aceptan.

¿Puede una VPN causar este error?

Sí. Algunos clientes VPN enrutan las consultas DNS a través de sus propios resolvedores o realizan inspección de tráfico que interfiere con los protocolos de enlace TLS. Si el error aparece solo mientras la VPN está activa, deshabilita la función de "tunelización dividida" o "inspección SSL" de la VPN, o añade el dominio afectado como exclusión.

¿Limpiar la caché siempre soluciona los errores SSL?

No. Limpiar la caché resuelve errores causados por políticas HSTS obsoletas o respuestas de certificados inválidos almacenadas en caché. No tiene ningún efecto sobre los problemas de certificados del lado del servidor, problemas con el reloj del sistema o la interceptación del antivirus. Usa la limpieza de caché como primer paso, no como solución universal.

¿Cómo puedo comprobar si el certificado SSL de mi servidor está correctamente configurado sin un navegador?

Usa OpenSSL desde cualquier máquina con acceso a la red:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

La salida muestra la cadena de certificados completa, la versión TLS negociada, el conjunto de cifrado seleccionado y cualquier error de verificación. Este es el método de diagnóstico más fiable para problemas TLS del lado del servidor.

¿Cuál es la diferencia entre ERR_SSL_PROTOCOL_ERROR y ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR indica que el servidor envió una respuesta que no se ajusta a ningún formato de registro TLS reconocido — a menudo causado por un servidor que envía una respuesta HTTP en el puerto 443, un balanceador de carga mal configurado o un firewall que termina la conexión a mitad del protocolo de enlace. ERR_SSL_VERSION_OR_CIPHER_MISMATCH significa que el protocolo de enlace comenzó correctamente pero el cliente y el servidor no pudieron acordar una versión TLS o un conjunto de cifrado mutuamente compatible, típicamente porque el servidor solo admite protocolos obsoletos.