Inventario de hostnames, dependencias y propiedad
Lista cada hostname que visitantes o integraciones usan: apex, www, subdominios, APIs, hosts de activos, portales y nombres regionales. Para cada uno, registra dónde termina TLS, quién puede cambiarlo, la cobertura y caducidad del certificado, el método de renovación y las dependencias que generan URLs. Un certificado debe cubrir el hostname solicitado en su lista de Subject Alternative Name (SAN). Incluye el CMS, CDN, tag manager, almacenamiento de objetos, proveedor de pagos, plantillas de email e incrustados de terceros; estos con frecuencia introducen URLs HTTP después del primer despliegue de HTTPS.
Selecciona un hostname canónico, apex o www, y redirige la alternativa directamente a él por HTTPS.
Despliega el certificado y las versiones actuales de TLS
Configura el servidor web, el proxy inverso, la CDN o el balanceador de carga que responde a la solicitud pública. Instala el certificado y la cadena necesaria, asígnalos a los nombres de host previstos y verifícalos desde fuera de la red de alojamiento. El navegador comprueba la cadena, el nombre de host y las fechas; una advertencia pública bloquea la publicación. Usa TLS 1.3 de forma predeterminada y conserva TLS 1.2 solo cuando sea necesario por compatibilidad. Deshabilita SSL y TLS 1.0 y 1.1. Sigue la guía actualizada de la plataforma en lugar de copiar una lista heredada de conjuntos de cifrado, y mantén actualizados el servidor y la biblioteca TLS.
Limita el acceso a las claves privadas y registra cada sistema que comparte una clave para que su reemplazo alcance a todos ellos.
Redirige HTTP de un solo salto y haz HTTPS canónico
Devuelve una redirección permanente del lado del servidor, normalmente 301 o 308, desde cada URL HTTP a su URL HTTPS equivalente. Evita cadenas: añaden latencia y más puntos de fallo. Publica URLs HTTPS canónicas en enlaces internos, etiquetas canonical, sitemaps, datos estructurados, etiquetas sociales, emails y enlaces absolutos generados por la aplicación. Prueba la página de inicio, una página profunda, una URL con query, rutas de error y variantes de hostname. Cuando TLS termina en un proxy, configura el manejo de protocolo reenviado de confianza para que la aplicación no entre en bucle entre HTTP y HTTPS.
Puede permanecer disponible solo para redirigir o completar un challenge de certificado, no para servir un sitio público separado.
Encuentra y corrige el contenido mixto en su origen
El contenido mixto es una página HTTPS que solicita un recurso por HTTP u otro protocolo inseguro. Los navegadores pueden actualizar algunos medios, pero bloquean muchas solicitudes riesgosas, incluidos scripts, hojas de estilo, frames, llamadas fetch y fuentes. Sustituye cada referencia por una URL HTTPS probada, una URL relativa para tu propio contenido o una alternativa aprobada. Analiza plantillas representativas e inspecciona las herramientas de desarrollo mientras completas los recorridos clave. Revisa CSS, JavaScript, bloques del CMS, manifiestos de activos, entradas del tag-manager, descargas e incrustados de proveedores. Una página segura no debe ofrecer una descarga por HTTP.
La actualización automática del navegador puede dejar una dependencia de terceros no disponible o no soportada; corrige la URL almacenada.
Automatiza la renovación y ensaya la recuperación de certificados
Trata la renovación como un despliegue automatizado, no como un recordatorio de calendario. El certificado debe renovarse y desplegarse en cada capa de servicio, y el servicio debe recargarse de forma segura. Prueba la misma ruta de validación antes de la caducidad en producción. Let’s Encrypt, por ejemplo, recomienda renovar sus certificados de 90 días cada 60 días; sigue el ciclo de vida de tu emisor y plataforma. Conserva en un inventario los nombres de certificados, la cuenta del emisor, el método de challenge, la automatización, la ubicación de la clave, los destinos y los contactos de emergencia. Verifica las fechas desde el endpoint público tras el despliegue.
Para una renovación fallida, comprueba DNS, enrutamiento del challenge, permisos, acceso del emisor, límites de tasa y el despliegue de CDN a origen.
Usa HSTS solo después de que el entorno HTTPS esté listo
HTTP Strict Transport Security (HSTS) es un encabezado de respuesta HTTPS que indica a los navegadores que deben usar HTTPS en futuras visitas a un host. A partir de entonces, los navegadores no ofrecen una opción para omitir los errores de certificado. Envíalo solo por HTTPS y conserva la redirección desde HTTP, porque HSTS se aprende después de una respuesta segura, salvo cuando se aplique una lista de precarga. Empieza con un max-age limitado y auméntalo después de comprobar las renovaciones y las rutas necesarias. No añadas includeSubDomains hasta que todos los subdominios actuales y futuros puedan ofrecer HTTPS válido. Preload no forma parte de la especificación HSTS y requiere una evaluación independiente del compromiso a largo plazo.
max-age=0 funciona solo después de que un navegador alcance una respuesta HTTPS válida; no puede reparar un host seguro inalcanzable.
Lanza, prueba y haz rollback sin debilitar el transporte
Guarda la configuración validada del certificado, de la capa perimetral y de las redirecciones antes de hacer cambios. Define quién autoriza una reversión, prueba en un entorno de preproducción cuando sea posible y modifica un solo tipo de control cada vez. Comprueba de inmediato los puntos de conexión públicos desde más de una red, sigue las redirecciones, inspecciona el certificado y completa las acciones importantes para los visitantes. Prueba los navegadores y grupos de clientes relevantes para tu audiencia. En flujos de pago o regulados, pide al proveedor de pagos y a un profesional cualificado de seguridad que revisen los requisitos aplicables. Si un cambio rompe HTTPS, restaura una configuración segura validada; no habilites HTTP en las páginas para clientes como solución temporal.
Captura el hostname, hora, cliente, error, cambio y resultado para que la próxima renovación o migración sea más fácil de diagnosticar.