Tu web de empresa muestra «No es seguro». Empieza por guardar el mensaje exacto y la dirección donde aparece. Una página HTTP, un certificado no válido, un recurso bloqueado y un aviso sobre un sitio peligroso requieren investigaciones distintas. Comprar otro certificado antes de identificar el aviso puede dejar el problema original sin resolver.

Esta guía ayuda al responsable de una empresa a preparar una solicitud de reparación y comprobar el resultado. No demuestra que una web esté libre de programas maliciosos ni sustituye una investigación si el navegador señala contenido peligroso.

Guarda el aviso antes de cambiar nada

Anota la dirección completa, incluido http:// o https://, si lleva www, la página afectada, el navegador y la hora. Guarda una captura y cualquier código de error. Indica si la página abre, si faltan imágenes y si el aviso aparece antes de llegar al sitio.

Evita introducir datos de clientes o de pago mientras haya dudas sobre la conexión. No pidas a los clientes que ignoren el aviso para poder consultar. La ayuda de Chrome sobre conexiones distingue entre conexión privada, conexión no segura y aviso de sitio peligroso.

Mi propuesta para el primer mensaje al responsable es sencilla: «Esta dirección exacta muestra este mensaje en este dispositivo. Identifica la causa, las direcciones afectadas y cómo comprobarás la reparación». No incluyas contraseñas en capturas ni en mensajes de soporte habituales.

Relaciona el síntoma con lo que hay que investigar

Esta tabla sirve para orientar la revisión; no es un diagnóstico. Los textos del navegador cambian. Envía el mensaje real en lugar de intentar encajarlo a la fuerza en una categoría.

Qué observas Qué pedir que investiguen Qué prueba solicitar
Una dirección HTTP abre sin conexión privada Disponibilidad de HTTPS y destino de los enlaces HTTP antiguos Dirección original y dirección final tras la reparación
HTTPS muestra un aviso de certificado Validez, nombre cubierto y cadena de certificados que recibe el visitante Código exacto, nombre del servidor afectado y resultado público corregido
La página abre, pero falla una imagen o función Si la página carga recursos no seguros Lista de recursos afectados y repetición correcta de la acción
Aparece un aviso de sitio peligroso a pantalla completa El hallazgo del navegador y una posible intrusión en la web Resultados de la investigación y proceso de revisión o recuperación pertinente

Mozilla documenta los códigos de aviso, incluidos problemas de nombre y confianza. Un certificado para un nombre de servidor no demuestra automáticamente que cubra todas las direcciones que usan los clientes. Pregunta por la dirección concreta que falló.

Una página HTTPS también puede solicitar recursos por HTTP. Los navegadores actualizan algunos contenidos mixtos a HTTPS y bloquean otras solicitudes; depende del recurso. El responsable debe revisar la consola y las peticiones reales. La documentación de MDN sobre contenido mixto explica este comportamiento. Emitir un certificado nuevo no reescribe por sí solo esas direcciones.

Comprueba si el problema sigue a la web

Prueba la misma dirección en otro navegador actualizado o dispositivo y, cuando sea posible, en otra red de confianza. Mantén la dirección idéntica. Que abra la portada y falle la página de contacto son observaciones distintas.

Si falla un dispositivo y funcionan los demás, registra la diferencia. Comprueba fecha, hora y zona horaria. La configuración de red, los proxies o el software que intercepta conexiones también pueden influir; la guía de Mozilla sobre conexiones seguras describe estas posibilidades. Pide que lo investigue quien administra el equipo o la red, en vez de desactivar la protección como solución permanente.

Estas comparaciones acotan la investigación. No demuestran que todos los clientes puedan entrar. Si el aviso se repite en varios dispositivos, entrega esos resultados al responsable en lugar de limitarte a «en mi portátil funciona».

Acuerda la reparación y las pruebas para aceptarla

Antes de aprobar el trabajo, pregunta quién gestiona el certificado y su renovación: el alojamiento, la plataforma web o el responsable de mantenimiento. La guía inicial de Let's Encrypt distingue estas situaciones. Algunos proveedores gestionan los certificados automáticamente; otros requieren activar una opción o usar un cliente aparte. Confirma tu caso real, sin suponer que emitirlo incluye toda su gestión futura.

Para una reparación de conexión, pediría estas comprobaciones:

  1. Volver a abrir cada dirección que fallaba, sin saltarse avisos del navegador.
  2. Confirmar que los enlaces HTTP antiguos llegan a la página HTTPS prevista y conservan las rutas pertinentes.
  3. Comprobar los nombres que utilizan los clientes, incluido www si aparece en publicidad o enlaces.
  4. Repetir en ordenador y móvil la acción que fallaba: abrir la imagen, descargar el documento o utilizar la vía de consulta.
  5. Registrar causa, fecha, responsable y acuerdo de renovación o supervisión futura.

Usa una consulta de prueba autorizada y confirma su recepción; evita datos de clientes. Si desaparece el aviso, pero sigue perdiéndose la consulta, continúa con la revisión de entrega del formulario. Deja constancia de lo pendiente en lugar de cerrar todo el trabajo porque una página ya abre.

Entiende qué demuestra una conexión sin avisos

HTTPS protege la información en tránsito entre navegador y sitio. No demuestra que las afirmaciones sobre tus productos sean correctas, que la empresa sea fiable o que toda la web sea segura. Un aviso de sitio peligroso requiere su propia investigación aunque también haya un certificado válido.

Conserva una nota breve del antes y después: direcciones afectadas, mensaje exacto, causa, reparación y resultados al repetir las pruebas. Relaciónala con tus responsabilidades de mantenimiento web. Así, la siguiente persona tendrá información útil si vuelve el problema, sin convertir una reparación de conexión en la afirmación de que toda la web ha superado una auditoría de seguridad.