¿Por qué sigue apareciendo una advertencia de sitio no seguro después de instalar un certificado de seguridad SSL?

Tras completar la instalación del certificado de seguridad SSL, si el navegador sigue mostrando «La conexión no es segura», «Certificado no válido» o no aparece el icono de candado en la barra de direcciones, normalmente no se debe a que el archivo del certificado haya caducado, sino a que la cadena de implementación está incompleta, el nombre de dominio visitado no coincide, la página sigue cargando recursos HTTP o el servidor no ha habilitado HTTPS correctamente. Este tipo de problema afecta la confianza de los visitantes en el sitio web y también puede provocar que el navegador bloquee o advierta de riesgos en procesos como el inicio de sesión, el envío de formularios y las redirecciones de pago.

Durante la revisión, no se limite a comprobar si «el certificado se ha adquirido o cargado». Debe basarse en el certificado al que el navegador accede realmente, la ruta de acceso y los recursos de la página: primero confirme el tipo de error; después verifique el nombre de dominio, la cadena de certificados, el puerto y las reglas de redirección; por último, solucione el contenido mixto. Así evitará sustituir repetidamente el certificado sin resolver el problema.

Primero revise el aviso del navegador para determinar en qué nivel se encuentra el problema

Haga clic en el aviso «No seguro» o en el icono de candado de la barra de direcciones del navegador para consultar los detalles del certificado y el mensaje de error específico. Los distintos síntomas corresponden a diferentes líneas de investigación.

La consola del navegador también es fundamental. Si en la consola aparece «Mixed Content», significa que la página principal se ha abierto mediante HTTPS, pero algunos recursos siguen solicitándose mediante HTTP; si muestra un error de nombre de certificado o de validación de la cadena de certificados, debe volver a la capa de implementación del servidor para revisarla.

La falta de coincidencia del nombre de dominio es el problema que más fácilmente se pasa por alto tras instalar un certificado de seguridad SSL

El certificado solo es válido para los nombres de dominio indicados en él y no cubre automáticamente todas las variantes. Por ejemplo, si el certificado se emite únicamente para www.example.com, el acceso directo a example.com puede seguir generando un error; un certificado ordinario de un solo dominio emitido para el dominio principal tampoco suele cubrir subdominios como shop.example.com o en.example.com.

Revise los «nombres alternativos del sujeto (SAN)» o los «nombres alternativos del titular» en los detalles del certificado y compárelos uno por uno con los puntos de acceso reales. Como mínimo, confirme lo siguiente:

• si están cubiertos tanto los dominios con www como los que no lo llevan, o si se han redirigido de forma unificada;
• si los sitios multilingües, subportales de tienda, sitios de descarga y paneles de administración, entre otros, utilizan subdominios independientes;
• si los usuarios podrían acceder directamente mediante dominios antiguos, dominios de prueba o direcciones IP;
• si el certificado se ha implementado en la vinculación de dominio o en la configuración del host virtual que presta actualmente servicio al exterior.

No intente ocultar una falta de coincidencia de nombres «redirigiendo todos los dominios a HTTPS». La redirección ocurre después del protocolo de enlace TLS: el navegador debe validar primero el certificado del dominio actual y, si el nombre del certificado no coincide, la advertencia aparecerá igualmente. El enfoque correcto es ampliar la cobertura del certificado para los puntos de acceso reales o normalizar los nombres de dominio en DNS, los accesos al sitio y los enlaces promocionales.

Cuando falta la cadena de certificados, el servidor parece estar configurado correctamente, pero el cliente no puede validarla

Un certificado SSL normalmente no consta de un único certificado de servidor. El navegador también necesita establecer, mediante certificados intermedios, una ruta de validación hasta un certificado raíz de confianza. Si durante la implementación solo se carga el certificado de dominio y no se configura el paquete de certificados intermedios proporcionado por la CA, algunos navegadores o dispositivos antiguos indicarán que el certificado no es de confianza.

En entornos Nginx, un problema habitual es que ssl_certificate apunte a un archivo de certificado independiente, en lugar de a un archivo de cadena completa que incluya el certificado del servidor y los certificados intermedios; en Apache, debe confirmarse que la configuración correspondiente de la cadena de certificados cumpla los requisitos de la versión actual. En entornos de panel de control, utilice el archivo «cadena de certificados completa», «fullchain» o «CA Bundle» proporcionado por la entidad certificadora, en vez de pegar únicamente el primer bloque del contenido del certificado.

También debe evitarse un orden incorrecto de la cadena. Normalmente, primero debe colocarse el certificado del sitio y, a continuación, añadirse los certificados intermedios en orden; por lo general, no es necesario que el servidor entregue activamente el certificado raíz. Tras sustituir los archivos, vuelva a cargar la configuración del servicio web y compruébela desde una red externa, en lugar de limitarse a verificar en el propio servidor si los archivos existen.

HTTPS está habilitado: ¿por qué la página sigue mostrándose como no segura?

Esta situación suele estar relacionada con el contenido mixto. El HTML de la página se transmite mediante HTTPS, pero las imágenes, JavaScript, CSS, vídeos, fuentes, códigos de analítica, iframe o direcciones de interfaz todavía están escritos como http://. Los navegadores modernos bloquean directamente parte del contenido activo, como los scripts y las solicitudes XHR; para determinadas imágenes o recursos multimedia, pueden permitir la carga, pero reducen el estado de seguridad.

El proceso de resolución debe comenzar con el código fuente de la página y la consola del navegador para localizar la dirección específica del recurso; después, revise el origen del recurso:

1. los recursos estáticos internos deben cambiarse a direcciones absolutas HTTPS o utilizar rutas relativas adecuadas para el sitio actual;
2. deben revisarse en lote los enlaces HTTP codificados de forma fija en plantillas, contenido enriquecido, detalles de productos y artículos históricos;
3. los scripts de terceros, mapas, ventanas de atención al cliente, inserciones de vídeo y componentes de formularios deben confirmar que admiten HTTPS;
4. los dominios de interfaz, de almacenamiento de archivos y las CDN de imágenes también deben implementar certificados válidos; no basta con modificar únicamente el dominio de la página de inicio;
5. tras realizar los cambios, limpie la caché del sitio, la caché de la CDN y la caché del navegador antes de volver a realizar las pruebas.

No se recomienda depender únicamente de la política del navegador de «actualizar automáticamente solicitudes no seguras». Puede servir como medida transitoria, pero no garantiza que todos los recursos se carguen correctamente; si los recursos de terceros no admiten HTTPS, aún pueden producirse estilos incompletos, fallos funcionales o errores en las solicitudes de datos.

Revise la escucha del servidor, las redirecciones y la configuración multinodo

Que el certificado sea correcto no significa que el puerto 443 ya esté atendido por el sitio adecuado. Debe confirmar que el firewall del servidor, el grupo de seguridad y el servicio web permitan el acceso al puerto 443, y que dicho puerto esté vinculado al certificado correspondiente al nombre de dominio objetivo. En entornos con IP compartida y varios sitios, una configuración SNI anómala puede hacer que el servidor devuelva el certificado de otro sitio, provocando así una falta de coincidencia del nombre de dominio.

También deben revisarse las redirecciones de HTTP a HTTPS. Lo ideal es que, al acceder a la versión http://, se redirija con un único 301 o 308 a la dirección HTTPS normalizada; no debe producirse un ciclo en el que HTTP redirija a HTTPS y HTTPS vuelva a HTTP, ni permitir que distintas páginas salten repetidamente entre las versiones con y sin www. Las páginas de inicio de sesión, envío de formularios, devolución de llamada de pago y acceso al panel de administración deben verificarse por separado, especialmente.

Si el sitio utiliza CDN, balanceo de carga o proxy inverso en la capa frontal, también debe confirmar por separado los certificados de los nodos perimetrales y del servidor de origen. Si los nodos perimetrales funcionan correctamente pero el origen presenta anomalías, algunos escenarios de retorno al origen pueden fallar; si el origen se ha actualizado, pero la CDN conserva el certificado antiguo, es posible que el acceso externo tampoco muestre el nuevo certificado. Cuando existen resoluciones de doble pila IPv4 e IPv6, deben probarse los nodos correspondientes a ambos tipos de dirección.

Evite problemas recurrentes de «error justo después de renovar»

Si tras renovar el certificado sigue apareciendo el certificado antiguo, suele deberse a que no se actualizó la ruta de referencia en la configuración, no se recargó el servicio o algún nodo no sincronizó el nuevo archivo. Al crear un registro de cambios de certificados, deben anotarse simultáneamente los dominios cubiertos por el certificado, la fecha de vencimiento, la ubicación de almacenamiento de la clave privada, la ubicación del archivo de cadena completa, los nodos de implementación y las operaciones de recarga. Antes y después de la actualización, consulte desde la red externa el número de serie y el período de validez para confirmar que el navegador recibe realmente el nuevo certificado.

Para páginas de destino de marketing, sitios independientes y páginas multilingües, también debe incorporar la comprobación de HTTPS al proceso de publicación: antes de publicar una página nueva, revise el protocolo de los recursos externos; al añadir un nuevo subdominio, confirme si está incluido en el certificado; al integrar una nueva herramienta de terceros, valide su código de inserción. De este modo, los avisos de «No seguro» pueden controlarse antes de la publicación, en vez de repararlos uno por uno después de recibir comentarios de los visitantes.