«La conexión no es privada» significa que el navegador no pudo verificar el certificado SSL del sitio y cortó la conexión antes de cargar la página. El código que aparece debajo del mensaje indica el motivo: NET::ERR_CERT_DATE_INVALID (el certificado caducó o el reloj del dispositivo está mal), NET::ERR_CERT_COMMON_NAME_INVALID (el certificado se emitió para otro nombre, a menudo sin www), NET::ERR_CERT_AUTHORITY_INVALID (certificado autofirmado o falta el certificado intermedio). El visitante solo puede corregir su reloj y su red; todo lo demás depende del propietario del sitio.
Cómo lo probamos
El 10 de noviembre de 2026, en un banco de pruebas: contenedor con Ubuntu 24.04.5, nginx 1.24.0, OpenSSL 3.0.13, curl, Chromium 153 (el navegador completo en modo headless mediante Playwright). Creamos nuestra propia CA raíz de prueba, un intermedio y varios certificados de servidor, levantamos en puertos distintos sitios con un certificado caducado, uno autofirmado, uno sin www y otro sin la cadena intermedia, y desplazamos el reloj del cliente con libfaketime. En cada caso anotamos el código de error de Chromium, el texto de la advertencia en inglés, ucraniano y ruso, y la salida de curl y openssl. Es el comportamiento del banco de pruebas, no datos de los servidores de RichHost. Las fechas de fuentes oficiales se comprobaron el mismo día.
Qué muestra el navegador y dónde está el código de error
En Chromium 153 con la interfaz en español, la página de advertencia se titula «La conexión no es privada». Lo importante no es el título, sino la línea pequeña de debajo: NET::ERR_CERT_ seguido del motivo. El botón «Configuración avanzada» abre una explicación en lenguaje sencillo y, si el navegador lo permite, un enlace del tipo «Acceder a … (sitio no seguro)».
Esto es, en resumen, lo que Chromium (interfaz en inglés) escribió bajo «Configuración avanzada» para cada causa en nuestro banco:
- certificado caducado: que el certificado de seguridad caducó hace 73 días, junto con la fecha del reloj del ordenador y la pregunta de si es correcta;
- certificado sin www: que el certificado de seguridad es de mysite.test (habíamos abierto www.mysite.test);
- certificado autofirmado y certificado sin la cadena intermedia: que el sistema operativo del ordenador no confía en el certificado de seguridad. Mismo texto, causas distintas.
Tabla: código de error, causa y quién lo soluciona
| Código de error | Causa | Quién lo soluciona | Cómo |
|---|---|---|---|
| NET::ERR_CERT_DATE_INVALID, caducado hace N días | Certificado caducado, la renovación automática falló | Propietario | Renovar el certificado, revisar la renovación automática y la recarga del servidor web |
| NET::ERR_CERT_DATE_INVALID con una página que avisa de que el reloj va atrasado | Fecha u hora incorrecta en el dispositivo del visitante | Visitante | Activar la fecha y hora automáticas, recargar la página |
| NET::ERR_CERT_COMMON_NAME_INVALID | El certificado no incluye el nombre abierto: www, un subdominio, otro dominio en la misma IP | Propietario | Volver a emitir el certificado con todos los nombres, incluido www |
| NET::ERR_CERT_AUTHORITY_INVALID en un solo sitio | Certificado autofirmado o el servidor no envía el intermedio | Propietario | Instalar un certificado de una CA pública (Let’s Encrypt), servir la cadena completa |
| NET::ERR_CERT_AUTHORITY_INVALID en muchos sitios a la vez | Algo entre tú y el sitio intercepta el tráfico: la página de acceso de un wifi público, el análisis HTTPS de un antivirus, un proxy corporativo | Visitante | Probar otra red, iniciar sesión en el wifi, desactivar el análisis HTTPS del antivirus |
| Sin enlace para continuar, se menciona HSTS | Cualquiera de las causas anteriores en un sitio con HSTS | Propietario | Arreglar el certificado: los visitantes no pueden saltarse esta advertencia |
| Sin advertencia, la página se abre pero el candado está incompleto o algo falla | Contenido mixto, otro problema | Propietario | Sustituir las direcciones http:// por https:// en el código y la base de datos |
Qué hacer si eres visitante
- Mira la fecha que aparece al pulsar «Configuración avanzada». Si es incorrecta, el problema está en tu dispositivo: corrige el reloj y recarga la página.
- Abre el mismo sitio con datos móviles en lugar del wifi. Si el error desaparece, la causa es la red: en una cafetería o un hotel, abre primero cualquier sitio sin HTTPS para que aparezca la página de acceso.
- Si la advertencia sale en todos los sitios, revisa el antivirus y las extensiones del navegador que «analizan HTTPS».
- Si solo falla un sitio con DATE_INVALID, COMMON_NAME_INVALID o AUTHORITY_INVALID, solo su propietario puede solucionarlo. Envíale el código de error y la dirección exacta.
No introduzcas contraseñas ni datos de tarjeta en una página a la que hayas llegado mediante «Acceder a … (sitio no seguro)». En ese momento el navegador no puede demostrar que estás hablando con el sitio real.
Certificado caducado: ERR_CERT_DATE_INVALID
Una causa típica del lado del propietario. En el banco, el servidor enviaba un certificado que caducó el 30 de agosto de 2026. Chromium mostraba NET::ERR_CERT_DATE_INVALID, mientras que curl y openssl indicaban el motivo directamente:
$ curl https://mysite.test:11102/ curl: (60) SSL certificate problem: certificate has expired $ openssl s_client -connect mysite.test:11102 -servername mysite.test verify error:num=10:certificate has expired
Un solo comando muestra la fecha de caducidad y los nombres del certificado de cualquier sitio:
$ echo | openssl s_client -connect mysite.test:443 -servername mysite.test 2>/dev/null \
| openssl x509 -noout -subject -issuer -enddate -ext subjectAltName
subject=CN = mysite.test
issuer=CN = CW11 Test Intermediate R1
notAfter=Aug 30 10:00:00 2026 GMT
X509v3 Subject Alternative Name:
DNS:mysite.test, DNS:www.mysite.test
Para la monitorización, usa openssl x509 -noout -checkend 2592000: devuelve un error si el certificado caduca en los próximos 30 días. No confíes en los correos de la CA: Let’s Encrypt dejó de enviar avisos de caducidad el 4 de junio de 2025 (anuncio de Let’s Encrypt). Además, los certificados son cada vez más cortos para todos: según la votación SC-081 del CA/Browser Forum, la vida máxima de un certificado público es de 200 días desde el 15 de marzo de 2026, de 100 días desde el 15 de marzo de 2027 y de 47 días desde el 15 de marzo de 2029 (calendario de DigiCert, consultado el 10.11.2026). Sin renovación automática, los certificados caducados serán algo habitual, así que configura en tu hosting un certificado gratuito de Let’s Encrypt que se renueve solo. En RichHost, un certificado SSL gratis de Let’s Encrypt viene incluido en todos los planes de hosting.
Reloj incorrecto en el dispositivo del visitante
Un certificado es válido durante un intervalo de tiempo, y el navegador lo compara con el reloj del dispositivo, no con el del servidor. Dejamos un certificado válido en el servidor (del 10 de noviembre de 2026 al 8 de febrero de 2027) y cambiamos la hora solo en el cliente:
| Fecha en el cliente | curl | Chromium 153 |
|---|---|---|
| 1 de marzo de 2027 | certificate has expired | ERR_CERT_DATE_INVALID, caducado hace 21 días, con enlace para continuar |
| 1 de octubre de 2026 | certificate is not yet valid | ERR_CERT_DATE_INVALID, certificado que supuestamente solo será válido dentro de 40 días |
| 15 de enero de 2024 | certificate is not yet valid | Una página aparte que avisa de que el reloj va atrasado, con un botón para actualizar la fecha y la hora, sin opción de continuar |
Consejo para propietarios: si un visitante se queja mientras el sitio funciona para ti y para los demás, pídele el texto que aparece en «Configuración avanzada». La fecha que contiene muestra al instante qué reloj está mal.
Con o sin www: ERR_CERT_COMMON_NAME_INVALID
Un certificado enumera los nombres para los que es válido. En el banco, el certificado solo contenía mysite.test: el dominio sin www funcionaba y www.mysite.test fallaba:
$ curl https://www.mysite.test:11103/ curl: (60) SSL: no alternative certificate subject name matches target host name 'www.mysite.test' $ openssl s_client -connect www.mysite.test:11103 -servername www.mysite.test -verify_hostname www.mysite.test verify error:num=62:hostname mismatch
Clave: una redirección de www al dominio sin www no sirve aquí. El navegador comprueba el certificado al establecer la conexión, antes de recibir cualquier respuesta del servidor, incluida una 301. Por eso el certificado debe incluir ambos nombres, y solo entonces rediriges uno al otro. Las reglas de redirección están en nuestra guía con ejemplos del archivo .htaccess, y si la redirección acaba en un bucle, consulta cómo solucionar ERR_TOO_MANY_REDIRECTS. El mismo error aparece cuando varios sitios comparten una IP y el servidor envía el certificado de otro dominio: normalmente el SSL simplemente no está activado para tu dominio en el panel de control.
Certificado autofirmado: ERR_CERT_AUTHORITY_INVALID
Nadie responde por un certificado autofirmado, así que el navegador no tiene motivos para confiar en él. En el banco, curl devolvió (60) SSL certificate problem: self-signed certificate, openssl dio verify error:num=18:self-signed certificate y Chromium mostró NET::ERR_CERT_AUTHORITY_INVALID. Un certificado así suele quedar tras instalar un servidor o un panel, cuando el sitio ya funciona pero nunca se emitió un certificado real. La solución: un certificado gratuito de Let’s Encrypt o uno de pago de una CA comercial. Las diferencias y cuándo compensa pagar se explican en nuestro artículo sobre el precio de un certificado SSL.
Falta el intermedio: funciona en el navegador, falla en curl
El caso más traicionero. El sitio envía solo su propio certificado, sin el intermedio que lo enlaza con la CA raíz. Montamos dos versiones de un servidor así:
- certificado con la dirección del intermedio en el campo AIA (así lo hacen las CA públicas): Chromium descargó el intermedio por su cuenta y abrió la página con estado 200, mientras que curl y openssl fallaron;
- certificado sin campo AIA: Chromium también mostró NET::ERR_CERT_AUTHORITY_INVALID.
$ curl https://mysite.test:11106/ curl: (60) SSL certificate problem: unable to get local issuer certificate $ openssl s_client -connect mysite.test:11106 -servername mysite.test verify error:num=20:unable to get local issuer certificate Verify return code: 21 (unable to verify the first certificate)
Por eso los propietarios ven un candado en su propio navegador y no se creen las quejas, mientras que los módulos de pago, las tareas cron, los clientes de API y algunas aplicaciones reciben un error. Cuenta los certificados que envía el servidor:
$ echo | openssl s_client -connect mysite.test:443 -servername mysite.test -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE' 1
El servidor bien configurado del banco enviaba 2 (el suyo y el intermedio). La solución: en nginx, ssl_certificate debe apuntar al archivo fullchain (primero el certificado del sitio, luego el intermedio); en un panel de control, pega el intermedio en el campo correspondiente del formulario SSL. El orden importa: cuando pusimos el intermedio primero, nginx -t se negó a arrancar con key values mismatch.
HSTS: por qué no hay enlace para continuar
La cabecera Strict-Transport-Security indica al navegador que un sitio solo funciona por HTTPS. En el banco abrimos primero un sitio que enviaba Strict-Transport-Security: max-age=31536000 con un certificado válido y después el mismo dominio con uno caducado. Chromium mostró NET::ERR_CERT_DATE_INVALID, pero el botón para volver a un sitio seguro se sustituyó por «Volver a cargar», el enlace para continuar desapareció y la explicación decía que no se podía visitar el sitio en ese momento porque usa HSTS. Un dominio de control sin la cabecera, en las mismas condiciones, mantuvo el enlace para continuar. Después, el navegador también reescribía por su cuenta las direcciones http:// a https://.
Para los visitantes, esta advertencia no se puede saltar, y es intencionado. Para los propietarios: activa HSTS solo después de comprobar que la renovación automática funciona, porque cualquier problema con el certificado dejará fuera a todos los que ya visitaron el sitio.
Contenido mixto: otro problema que se suele confundir con este
Si una página HTTPS carga scripts o imágenes desde direcciones http://, no aparece ninguna advertencia a pantalla completa: la página se abre y el problema solo se ve en la consola de desarrollador (F12). En el banco, Chromium bloqueó el script y cambió automáticamente la dirección de la imagen a https:
Mixed Content: The page at 'https://mysite.test:11101/mixed.html' was loaded over HTTPS, but requested an insecure script 'http://mysite.test:11110/app.js'. This request has been blocked; the content must be served over HTTPS.
El resultado: un menú, un slider o un formulario deja de funcionar aunque el certificado esté bien. Mira cómo solucionar el contenido mixto tras pasar a HTTPS y nuestro resumen sobre el certificado SSL en hosting compartido.
Lista de comprobación para propietarios
- Abre el sitio con y sin www, en un ordenador y en un móvil. Anota el código de error.
- Ejecuta el comando con
-enddate -ext subjectAltName: ¿la fecha sigue siendo válida?, ¿aparecen todos los nombres? - Cuenta los certificados con
-showcerts: debería haber al menos 2. - Ejecuta
curl -I https://your-domain/: curl no descarga los intermedios que faltan y delatará una cadena incompleta. - Tras la corrección, añade una comprobación con
-checkenda tu monitorización o a cron.
Si el sitio no se abre en absoluto y no hay ninguna advertencia de certificado, la causa está en otra parte, en el lado del servidor. En los planes de hosting de RichHost se activa un certificado gratuito de Let’s Encrypt en nuestro propio panel de control con asistente de IA (comprueba que cubra también la dirección con www), y el soporte atiende de 10:00 a 20:00, hora de Kyiv, con una respuesta habitual en unos 30 minutos.
Preguntas frecuentes
¿Es seguro pulsar «Acceder a … (sitio no seguro)»?
Solo si conoces la causa exacta, por ejemplo, si es tu propio servidor de pruebas. En el sitio de otra persona, no introduzcas ahí contraseñas ni datos de pago: el navegador no puede confirmar que la página sea auténtica.
¿Por qué el sitio me funciona a mí pero no a mi cliente?
A menudo por una cadena incompleta: en nuestro banco, Chromium obtuvo por su cuenta el intermedio que faltaba, curl y openssl no. La segunda causa habitual es un reloj incorrecto en el dispositivo del cliente.
¿Por qué el error solo aparece en la dirección con www?
El certificado se emitió sin el nombre con www. Vuelve a emitirlo con ambos nombres; una redirección 301 no elimina este error.
¿Sirve de algo borrar la caché del navegador?
No. El certificado se comprueba en cada conexión nueva y la caché de páginas no influye. En cuanto el propietario arregle el certificado, basta con recargar la página.
