«No es seguro» en Chrome: qué significa y cómo quitarlo

Si al entrar en tu web Chrome escribe «No es seguro» junto a la dirección, respira: en la inmensa mayoría de los casos no significa que te hayan hackeado. Ese aviso gris dice una cosa muy concreta y muy técnica: el navegador no ha conseguido establecer una conexión cifrada válida con tu servidor, o la ha establecido pero la página está pidiendo algún archivo por una conexión sin cifrar. Es un problema de configuración, y casi siempre se arregla en menos de una tarde.

Vas a hacer tres cosas en este orden: distinguir tu aviso de otro mucho más grave con el que se confunde, averiguar la causa exacta con las herramientas que ya tienes en el navegador y aplicar la corrección que toque. Sin tocar nada a ciegas.

El aviso gris y la pantalla roja no son lo mismo

Antes de nada, mira bien qué te sale, porque hay dos avisos completamente distintos y la gente los mezcla:

«No es seguro» en gris, en la barra de direcciones, y la web se carga normal. Es un problema de cifrado: certificado ausente, caducado, mal instalado o contenido cargado por HTTP. Es lo que trata este artículo.
Una pantalla roja a página completa que dice «Sitio engañoso» o «El sitio web que aparece más adelante contiene programas dañinos» y te obliga a hacer clic para continuar. Eso es Google Safe Browsing y sí es un aviso de seguridad real: significa que Google ha detectado phishing o malware en tu dominio. Ese caso no se arregla con un certificado; hay que limpiar la web y pedir revisión.

Si lo tuyo es la pantalla roja, deja este artículo y trátalo como un incidente. Si es el texto gris, sigue.

Dónde está exactamente el aviso

En las versiones recientes de Chrome el candado desapareció y en su lugar hay un icono de controles deslizantes, así que el estado de la conexión ya no se ve de un vistazo. Cuando no hay cifrado válido, en su lugar sale el texto «No es seguro». Firefox muestra un candado tachado y Safari también avisa: no es cosa de Chrome, lo van a ver todos tus visitantes.

Mira el motivo exacto antes de tocar nada

Tienes el diagnóstico dentro del propio navegador y tarda un minuto:

Abre tu web y haz clic en el icono a la izquierda de la dirección. Chrome te dirá si el problema es «La conexión no es segura» o si el certificado no es válido.
Pulsa F12 para abrir las herramientas de desarrollador y ve a la pestaña Consola. Recarga la página.
Busca líneas que empiecen por Mixed Content:. Tienen esta pinta: «Mixed Content: The page at ‘https://tudominio.es/’ was loaded over HTTPS, but requested an insecure image ‘http://tudominio.es/wp-content/uploads/logo.png’». Esa línea te está dando la URL culpable, con nombre y apellidos.

Si no hay ni rastro de Mixed Content, el problema es el certificado o la falta de él. Si hay veinte líneas de esas, el certificado está bien y lo que falla es el contenido de tus páginas.

Causa 1: no hay certificado, o lo hay pero la web se sirve por http://

Comprueba primero si el certificado existe: escribe a mano https://tudominio.es en la barra. Si carga con normalidad y sin avisos, el certificado está y el problema es que tu WordPress sigue enlazando a http://. Si al escribir https:// te sale un error de conexión o una advertencia a página completa, es que no hay certificado válido.

Para instalarlo, entra en tu panel de hosting. En cPanel está en Seguridad → SSL/TLS Status (o Estado de SSL/TLS): marcas el dominio y pulsas «Ejecutar AutoSSL». En Plesk es Certificados SSL/TLS. Casi todos los proveedores serios incluyen hoy certificados gratuitos de Let’s Encrypt, así que si el tuyo te cobra aparte por un certificado básico de dominio, tenlo en cuenta cuando toque renovar. Ese punto y otros parecidos, en la guía sobre qué preguntar antes de contratar un hosting.

Causa 2: el certificado ha caducado o no cubre el nombre que usas

Los certificados de Let’s Encrypt duran noventa días y se renuevan solos. Cuando dejan de hacerlo, casi siempre es por uno de estos tres motivos:

El dominio ha cambiado de DNS (por ejemplo, lo has puesto detrás de Cloudflare) y el servidor ya no puede validar la propiedad.
Una redirección del .htaccess está interceptando la ruta /.well-known/acme-challenge/, por donde se hace la validación. Si tienes reglas ahí, excluye esa ruta.
El certificado se emitió para tudominio.es pero se entra por www.tudominio.es, o al revés. Tiene que cubrir ambos nombres.

Ese último caso da un error característico: NET::ERR_CERT_COMMON_NAME_INVALID. No es que el certificado esté roto, es que no es el de ese nombre.

Causa 3: contenido mixto, el sospechoso habitual en WordPress

Es la causa número uno en webs que llevan años funcionando y que en su día pasaron de HTTP a HTTPS sin terminar la mudanza: la página va cifrada, pero dentro pide imágenes, hojas de estilo o scripts por http://. Se arregla en tres pasos, y el orden importa:

1. Cambia las URL del sitio

En Ajustes → Generales tienes «Dirección de WordPress (URL)» y «Dirección del sitio (URL)». Las dos tienen que empezar por https://. Si esos campos aparecen en gris y no te dejan editarlos, es que están fijados en wp-config.php con WP_HOME y WP_SITEURL: cámbialos allí.

2. Reemplaza las URL antiguas dentro del contenido

Miles de enlaces e imágenes viven en la base de datos con la dirección antigua escrita a mano. Dos formas de arreglarlo:

Con un plugin de búsqueda y reemplazo (Better Search Replace es el más usado). Haz primero la simulación en seco, revisa cuántas coincidencias salen y solo entonces ejecútalo de verdad.
Con WP-CLI, si tienes acceso SSH:

wp search-replace 'http://tudominio.es' 'https://tudominio.es' --skip-columns=guid --dry-run
wp search-replace 'http://tudominio.es' 'https://tudominio.es' --skip-columns=guid

El --skip-columns=guid no es opcional: si tocas esa columna, los lectores de feeds pueden republicar como nuevas todas tus entradas antiguas. Y antes de ejecutar la versión sin --dry-run, ten una copia de seguridad (backup) de la base de datos que sepas restaurar. Si nunca has probado a restaurar la tuya, lee primero qué debe incluir una copia de seguridad para que sirva el día malo.

3. Fuerza el HTTPS en el servidor

En un Apache con WordPress, añade esto antes del bloque # BEGIN WordPress de tu .htaccess:

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

Si tu web está detrás de un proxy o de una CDN, la variable %{HTTPS} puede llegar siempre vacía y provocar un bucle de redirecciones. En ese caso la condición correcta es RewriteCond %{HTTP:X-Forwarded-Proto} !https. Si acabas en una redirección infinita, esa es la razón: no insistas recargando, cambia la condición.

Hay plugins que hacen todo esto de golpe (Really Simple SSL es el más conocido) y funcionan, pero conviene saber qué hacen: reescriben las URL al vuelo al generar la página, sin corregir lo guardado en la base de datos. Buen parche temporal; como solución definitiva te deja el problema debajo de la alfombra.

Causa 4: un formulario que envía a http://

Menos frecuente, pero muy visible: al hacer clic en un campo aparece un aviso extra de que los datos no viajarán cifrados. Ocurre cuando el atributo action del formulario apunta a una dirección http:// escrita a mano, casi siempre en un formulario antiguo pegado como HTML dentro de una página. Quítale el http: de delante y déjalo con la ruta relativa.

Comprobar que ha funcionado de verdad

No te fíes de tu navegador: guarda en caché con mucho entusiasmo. Haz esto:

Vacía la caché de tu plugin de caché y, si usas CDN, purga también la del CDN.
Abre la web en una ventana de incógnito y revisa varias páginas, no solo la portada: el contenido mixto suele esconderse en entradas antiguas y en la página de contacto.
Vuelve a la consola con F12 y confirma que no queda ninguna línea de Mixed Content.
Comprueba que http://tudominio.es redirige de verdad y no se queda cargando en claro.

Cuando esté todo limpio, el paso siguiente natural es activar HSTS para que el navegador ni siquiera intente la conexión sin cifrar, y revisar el resto de cabeceras de seguridad HTTP que tu web debería estar enviando. Eso sí: activa HSTS solo cuando estés seguro de que el HTTPS funciona en todos los subdominios que uses, porque es una decisión difícil de revertir a corto plazo.

Cuándo el «No es seguro» sí es síntoma de algo peor

Hay un escenario en el que este aviso deja de ser un asunto de configuración y merece que mires más a fondo: cuando aparece de repente en una web que llevaba años bien y tú no has tocado nada. Motivos posibles:

Alguien ha modificado el .htaccess o las URL del sitio en la base de datos: manipulación típica cuando han entrado en el panel.
Hay un script inyectado que carga desde fuera por HTTP. En la consola se ve claro: el Mixed Content apunta a un dominio que no es el tuyo.
El certificado dejó de renovarse porque alguien cambió los DNS del dominio.

En esos tres casos el aviso es la punta del iceberg. Antes de darlo por cerrado, mira qué plugins tienes realmente instalados y revisa la lista de usuarios administradores. Y si el Mixed Content señala a un dominio ajeno, no lo corrijas y sigas: eso ya no es un fallo de HTTPS, es contenido metido por alguien.

Resumen honesto de cuándo necesitas ayuda

Instalar el certificado desde el panel del hosting y cambiar las dos URL de Ajustes → Generales lo puede hacer cualquiera sin miedo, y la búsqueda y reemplazo en la base de datos también, con una copia hecha antes. Conviene parar y pedir ayuda si tu web es una tienda con pedidos en curso, si al forzar HTTPS entras en un bucle que no sabes deshacer, o si el aviso ha aparecido solo y sospechas que hay alguien más tocando. El resto es configuración, y la tienes ordenada de principio a fin en la guía de configuración segura de hosting, HTTPS, correo y DNS.

Cuando hayas terminado, merece la pena mirarlo desde fuera y no solo desde tu navegador. Comprueba tu web gratis con PathScan: te dice en un minuto si el certificado está bien servido, si queda contenido cargándose sin cifrar y qué más está viendo un visitante cualquiera al entrar en tu dominio.

Seguir leyendo en esta sección

Ver todo en Endurecer tu web → · Mapa completo del sitio