Configurar SSL en cPanel: HTTPS, redirecciones y HSTS
Actualizado el 28 de octubre de 2026 · Guía para empresas en México
Para configurar SSL en cPanel, primero comprueba que HTTPS funcione en cada nombre que usa tu sitio; después ordena las redirecciones y revisa los recorridos importantes. HSTS requiere una decisión adicional sobre alcance y duración. Copiar una política anual para todos los subdominios puede bloquear servicios que todavía dependen de HTTP.
Esta guía te ayuda a obtener una evidencia concreta: qué dominio tiene un certificado válido, qué página abre sin errores y qué ruta falta comprobar. HTTPS protege la conexión; no acredita la honestidad de una tienda ni garantiza ventas o posiciones en Google. Chrome anunció el reemplazo del candado por un icono de controles precisamente para evitar esa confusión. Explicación de Chromium sobre el icono de conexión.
Antes de tocar reglas: dibuja la ruta de tu sitio
Identifica quién controla el dominio, DNS, hosting y, si existe, CDN o proxy. Anota el dominio principal, su variante www, tienda, formularios y servicios internos. Una página que abre bien no demuestra que todos estos destinos estén preparados.
Si todavía no distingues qué dominio muestra cada instalación, revisa la guía para organizar dominios y raíces de documentos en cPanel. Esa relación ayuda al inventario, pero no demuestra cobertura del certificado ni alcance de HSTS.
En una conexión directa, el navegador llega al servidor de alojamiento. Con CDN o proxy puede haber dos tramos: navegador al intermediario e intermediario al origen. Comprueba con el responsable qué certificado y qué política corresponden a cada tramo; la información del navegador no describe por sí sola el segundo. Guarda la configuración anterior, una copia recuperable del sitio y una persona responsable de detener el cambio si aparece un fallo.
1. Comprueba el certificado desde tu cPanel
Entra mediante la dirección HTTPS verificada que proporciona tu hosting, sin saltar advertencias. Busca SSL/TLS Status: según versión puede ser una pantalla independiente o parte de SSL/TLS Certificates. El proveedor decide qué interfaces permite. Revisa los nombres cubiertos, vigencia y estado, no únicamente el color de una fila. La documentación actual de SSL/TLS Status describe esas diferencias de interfaz.
Si tu cuenta ofrece ejecutar AutoSSL, utiliza el flujo documentado por el proveedor y revisa el resultado. Si no aparece, pide que confirmen disponibilidad y motivo; no necesitas administrar WHM para seguir esta guía. AutoSSL automatiza certificados de validación de dominio, pero su habilitación, proveedor y registros corresponden a la administración del servicio. No presupongas que cualquier plan incluye las mismas prestaciones. Referencia administrativa de AutoSSL.
Ante un fallo, conserva el nombre afectado, hora y mensaje exacto. Solicita revisar resolución DNS, validación del dominio y condiciones del emisor según ese error. Repetir la emisión sin conocer la causa no demuestra una reparación. No compartas claves privadas del certificado en un ticket público.
2. Prueba HTTPS antes de redirigir visitas
- Abre cada nombre con https: comprueba que el certificado corresponda y no haya advertencias. Si falla, detente en ese destino.
- Recorre páginas diferentes: inicio, una entrada, una ficha de producto y las pantallas de acceso o contacto que realmente existan.
- Revisa recursos: imágenes, scripts, estilos e integraciones. La consola del navegador puede señalar solicitudes HTTP dentro de una página HTTPS; registra página y recurso afectado. Corrige en el origen del contenido y comprueba de nuevo. Guía técnica sobre contenido mixto.
- Prueba procesos autorizados: usa un entorno de prueba o un caso acordado para formularios y pagos. No generes compras, cobros o mensajes reales únicamente para completar una revisión técnica.
Si el CMS requiere actualizar direcciones, aplica su procedimiento compatible con respaldo. No hagas sustituciones indiscriminadas en una base de datos: puedes alterar datos serializados, enlaces externos o configuraciones que no pertenecen a este cambio.
3. Centraliza la redirección, sin pegar una regla universal
La pantalla Domains puede ofrecer la opción de forzar HTTPS, dependiendo de la versión y las funciones habilitadas. Revisa la documentación de Domains y el procedimiento de tu alojamiento. Si ya redirigen el CDN o la aplicación, identifica un responsable y una ubicación coherente para cada regla antes de añadir otra.
Una comprobación útil consiste en abrir una dirección HTTP conocida y registrar su destino final: debe conservar la página prevista y terminar en el nombre HTTPS correcto, sin bucle. Repite con www y sin www cuando ambas variantes formen parte del sitio. Si una falla, registra la cadena observada y la configuración modificada; no desactives seguridad ni cambies DNS a ciegas para eliminar el síntoma.
4. Decide HSTS por alcance, no por una receta anual
HSTS hace que el navegador aplique HTTPS a un nombre. Con includeSubDomains abarca también sus descendientes, incluidos nombres anidados e internos. La guía del proyecto recomienda despliegue gradual y observación entre etapas; actualmente recomienda HSTS, pero no recomienda el precargado o preload. No lo actives por defecto. Recomendaciones oficiales y consecuencias del preload.
Quitar una línea del servidor no borra inmediatamente lo que los navegadores ya aprendieron. La desactivación de una política dinámica requiere una respuesta HTTPS válida y no elimina políticas independientes de otros nombres; una política heredada de un padre puede seguir aplicándose. La lista precargada tiene otro proceso de retirada y distribución. Por eso debes conservar HTTPS operativo durante la recuperación, no prometer una reversión instantánea. Funcionamiento y caducidad de HSTS en MDN.
Ensaya el alcance sin cambiar ningún servidor
Abre el simulador para alternar estados HTTPS de tres nombres ficticios y observar qué casos quedan dentro de la política seleccionada. Los resultados son un ejercicio de alcance, no una auditoría ni permiso para desplegar. No genera cabeceras de producción ni consulta dominios reales.
Abrir la herramienta interactiva de esta guía. Recurso separado en este sitio, no embebido en el artículo. Usa escenarios ficticios, sin consultar servidores ni enviar datos. Compara opciones, reinicia y guarda un resumen local.
Ejemplo sin JavaScript: imagina que example.test y tienda.example.test funcionan por HTTPS, pero el estado de interno.tienda.example.test es desconocido. Una política del padre con alcance a descendientes deja un caso sin verificar; dos respuestas correctas no resuelven el tercero. Si ese servicio solo funciona por HTTP, el caso es incompatible con exigirle HTTPS. Una política limitada al padre no prueba ni modifica el estado de los otros nombres, que podrían tener políticas propias. El simulador reduce esta situación a tres nombres; tu inventario real puede ser mayor.
Qué evidencia conservar al cerrar el cambio
- Por nombre: fecha, certificado observado, página HTTPS comprobada y responsable.
- Por recorrido: origen HTTP, destino final, recursos fallidos y resultado del proceso autorizado.
- Por política: alcance acordado, duración, servicios pendientes y recuperación documentada.
- Para seguimiento: quién vigila renovación y quién atiende avisos. Que haya funcionado hoy no prueba una renovación futura.
En un sitio comercial puedes observar errores y conversiones con tu medición autorizada antes y después, pero campañas, tráfico y otras modificaciones también cambian los resultados. No atribuyas una mejora de ventas a HTTPS sin evidencia suficiente.
Dónde ayuda la IA y dónde hace falta comprobar
Una IA puede ayudarte a ordenar un inventario ficticio o explicar un mensaje previamente anonimizado. Puede equivocarse con versiones, sintaxis y supuestos sobre proxies. No le entregues claves privadas, accesos, cookies o configuraciones sensibles sin autorización y revisión de su tratamiento de datos. Contrasta su propuesta con documentación vigente y con observaciones del sistema; la aprobación del despliegue y su recuperación corresponden al responsable técnico.
Cuándo resolverlo tú y cuándo pedir acompañamiento
Un sitio sencillo con documentación clara y soporte incluido puede seguir el procedimiento del alojamiento sin contratar otra capa de administración. Con tienda, CDN y servicios heredados, un socio experimentado puede aportar inventario de dependencias, pruebas acordadas, coordinación con el proveedor y un plan de recuperación. Ese trabajo puede justificar un precio mayor; el precio por sí solo no acredita calidad.
Antes de contratar, concreta quién modifica cada componente, horarios y canales de atención, exclusiones y entregables. No presupongas disponibilidad permanente ni ausencia de caídas. Si necesitas ayuda, consulta con Cobalt Blue Web indicando qué nombres fallan, si utilizas CDN y qué evidencia ya reuniste, sin incluir secretos. Así podrán delimitar una revisión, en lugar de venderte un cambio de hosting sin diagnóstico.