UA-51298262-10 Skip to main content
Seguridad

«Your connection is not private»: solución tras instalar SSL

By octubre 3, 2026No Comments
'Your connection is not private': solución tras instalar SSL

Aparece de golpe. Instalas el certificado, recargas la web esperando el candadito verde y te topas con el aviso your connection is not private, una pantalla que bloquea el acceso y que a los visitantes les transmite justo lo contrario de lo que buscábamos: desconfianza. Lo he visto más veces de las que recuerdos, y casi siempre la causa está bien identificada. Con una revisión ordenada (certificado, contenido mixto, configuración de WordPress) el problema se arregla en minutos.

Qué significa el error «Your connection is not private» y por qué aparece tras instalar un SSL

El aviso puede llegar con varios códigos según el navegador: NET::ERR_CERT_AUTHORITY_INVALID, NET::ERR_CERT_DATE_INVALID o SSL_ERROR_NO_CYPHER_OVERLAP. Todos dicen básicamente lo mismo: el navegador no consigue validar la conexión cifrada con el servidor. El certificado puede estar instalado, sí, pero algo en la cadena de confianza se ha roto. Y el navegador, ante la duda, prefiere bloquear antes que mostrar contenido que podría no ser seguro.

Justo después de una instalación de SSL, estas son las causas que aparecen una y otra vez:

  • Certificado mal emitido: el SSL se emitió para otro dominio. Sin la variante www, por ejemplo. O para midominio.com cuando el sitio carga en midominio.es. Detalles así pasan más de lo que uno creería.
  • Cadena de certificados incompleta: falta el certificado intermedio. Muy típico en servidores propios o VPS, donde mucha gente instala solo el archivo principal y se olvida del resto.
  • Certificado caducado o autofirmado: los autofirmados, en producción, no pasarán nunca la validación del navegador. No insistas.
  • Cache del navegador: el navegador guarda la respuesta de error anterior. Es sorprendente cuántos «problemas graves» se solucionan con una limpieza de caché o una prueba en modo incógnito.
  • Contenido mixto: la página carga por HTTPS pero recursos internos (imágenes, scripts, fuentes) siguen apuntando a HTTP.

Comprobar que el certificado SSL está correctamente instalado y vigente

Antes de tocar nada de WordPress, confirma que el SSL está bien instalado a nivel de servidor. Yo lo haría en este orden:

  1. Verifica la caducidad: entra al sitio con HTTPS, haz clic en el candado y revisa la fecha de validez. Si trabajas con Let’s Encrypt, ten presente que los certificados duran 90 días y deben renovarse solos.
  2. Comprueba el dominio exacto: prueba con y sin www. Si una de las dos falla, necesitas un certificado que cubra ambas variantes o un registro SAN adicional.
  3. Analiza la cadena completa: herramientas gratuitas como el SSL Checker de SSL Labs sirven, o directamente openssl s_client -connect tudominio.com:443 desde terminal. Si la cadena aparece como «incomplete», falta el certificado intermedio: descárgalo de tu autoridad emisora y añádelo al archivo del certificado en la configuración de Apache o Nginx.
  4. Revisa la configuración TLS: desactiva las versiones viejas, TLS 1.0 y 1.1, y deja activos TLS 1.2 y 1.3. Con protocolos antiguos aparecen errores de cifrado que no tienen nada que ver con el certificado en sí.

Corregir el contenido mixto (mixed content) en WordPress

Puede que el SSL sea perfecto y aun así el navegador siga avisando. ¿Por qué? Porque la web carga imágenes, scripts u hojas de estilo por HTTP. WordPress es especialmente propenso a esto: las URL antiguas quedan enterradas en la base de datos tras la migración a HTTPS, y ahí se quedan.

Actualizar las URLs en la base de datos

Ve a Ajustes > Generales y comprueba que tanto la dirección de WordPress (URL) como la dirección del sitio (URL) usen https://. Después, reemplaza las referencias http:// antiguas del contenido con un plugin como Better Search Replace, buscando http://tudominio.com y sustituyéndolo por https://tudominio.com. Y no te saltes este paso: copia de seguridad de la base de datos antes de tocar nada.

Forzar HTTPS con redirecciones y cabeceras

Añade esta regla al principio del archivo .htaccess (Apache):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

En Nginx, la redirección equivalente se define en el bloque del server en el puerto 80 con return 301 https://$host$request_uri;.

Localizar los recursos problemáticos

  • Abre la consola del navegador (F12, pestaña Console) y ve anotando cada recurso marcado como mixed content.
  • Con la pestaña Inspeccionar puedes averiguar si vienen de la biblioteca de medios, del tema o de algún plugin.
  • Plugins como Really Simple SSL corrigen el contenido mixto de forma automática. Funcionan, claro. Pero la solución de verdad, la limpia, es actualizar las URLs de origen.

Certificado validado, cadena completa, contenido mixto eliminado. Con eso el error your connection is not private debería desaparecer del todo. Y si después de todo esto persiste, en RedServicio (redservicio.net) puedes encontrar ayuda profesional para diagnosticar y resolver cualquier incidencia con certificados SSL y servidores web.

Actualizar la URL del sitio y forzar HTTPS con redirecciones 301

Instalado el certificado, toca avisar a WordPress de que la dirección del sitio ya no es la misma. Ha pasado de HTTP a HTTPS, y si no se lo dices, el gestor seguirá generando enlaces internos con el protocolo viejo. Ahí aparecen los contenidos mixtos y, con ellos, el error your connection is not private. Lo más rápido: entra en Ajustes > Generales desde el panel de administración y cambia los dos campos:

  • Dirección de WordPress (URL): https://tudominio.com
  • Dirección del sitio (URL): https://tudominio.com

¿Que ni siquiera puedes acceder al panel por culpa del propio error? Hay salida. Edita el archivo wp-config.php y añade estas líneas antes del comentario que avisa de dejar de editar:

  • define(‘WP_HOME’, ‘https://tudominio.com’);
  • define(‘WP_SITEURL’, ‘https://tudominio.com’);

Siguiente paso: forzar que todo el tráfico entre por HTTPS. Lo más limpio, sin duda, es hacerlo a nivel de servidor con una redirección 301, que de paso conserva el SEO. Si tu servidor corre Apache, añade esto al principio del archivo .htaccess que está en la raíz de la instalación:

  • RewriteEngine On
  • RewriteCond %{HTTPS} off
  • RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

En Nginx el bloque, dentro de la configuración del servidor, queda así:

  • server { listen 80; server_name tudominio.com; return 301 https://$host$request_uri; }

Un consejo: evita los plugins de redirección si tienes acceso al servidor. La regla nativa rinde mejor y te quita una dependencia de encima (menos cosas que actualizar, menos cosas que fallen). Para comprobar que funciona, ejecuta curl -I http://tudominio.com y fíjate en la respuesta: debería devolver un 301 con la cabecera Location apuntando a la versión segura.

Limpiar caché, cookies y guardar los enlaces permanentes

Configuración correcta, todo en orden… y el navegador sigue mostrando el error. Pasa más de lo que parece. Casi siempre la culpa es del contenido obsoleto guardado en el navegador o en alguna capa de caché intermedia. Antes de tocar nada más, descarta el lado del cliente:

  1. Borra la caché y las cookies del navegador, o prueba directamente en modo incógnito.
  2. ¿Usas un plugin de caché (WP Rocket, W3 Total Cache, LiteSpeed Cache)? Vacía toda la caché desde su panel.
  3. Si trabajas con Cloudflare u otra CDN, purga la caché completa desde la opción correspondiente.
  4. Y si tu hosting tiene caché a nivel de servidor (LiteSpeed, Varnish, OPcache), purga también esa capa desde el panel de control.

Luego regenera los enlaces permanentes. Es un truco sencillo pero efectivo: al hacerlo, WordPress reconstruye todas las rutas internas con el protocolo nuevo. Ve a Ajustes > Enlaces permanentes y pulsa en Guardar cambios sin cambiar absolutamente nada. Con eso refrescas las reglas de reescritura y te ahorras sorpresas tipo error 404 después del cambio de URL.

Última comprobación. Abre la consola del navegador (F12) y mira la pestaña de seguridad: no debería aparecer ningún aviso de contenido mixto, y el candado tiene que verse bien. Ejecuta también una auditoría en SSL Labs para confirmar que la cadena de certificados está completa y que la nota es una A o mejor.

Conclusión: checklist final para eliminar el error your connection is not private

El error your connection is not private después de instalar un SSL casi siempre se debe a lo mismo: certificado mal instalado o caducado, contenido mixto, URLs sin actualizar o cachés obsoletas. Antes de abrir un ticket con soporte, repasa esta lista, en orden:

  1. Comprueba que el certificado está activo, vigente y que cubre el dominio con y sin www.
  2. Verifica que la cadena de certificados intermedios está completa.
  3. Cambia las URLs del sitio en Ajustes > Generales o en wp-config.php.
  4. Localiza y corrige el contenido mixto con la URL de la base de datos o con Better Search Replace.
  5. Configura la redirección 301 de HTTP a HTTPS en .htaccess o Nginx.
  6. Vacía la caché del navegador, del plugin, del CDN y del servidor.
  7. Regenera los enlaces permanentes y valida el resultado en SSL Labs.

¿Y si después de todo esto el candado sigue sin aparecer? ¿O el navegador continúa con la advertencia? Entonces puede haber algo más profundo: un problema en la configuración del servidor o en la emisión del certificado. En RedServicio (redservicio.net) ofrecen ayuda profesional para diagnosticar y resolver cualquier incidencia con certificados SSL y servidores web, y dejar tu sitio WordPress funcionando de forma segura.