Configura HTTPS en PrestaShop y recupera el acceso ante bucles de redirección

Qué haríamos

Primero elaboraríamos un mapa de la tienda actual: su alojamiento, CDN o proxy inverso, versión de PrestaShop, dominios multitienda, tema, módulos, integraciones de pago y URL almacenadas en el contenido. Acuerda quién controla cada capa y quién puede recuperar el acceso. Un cambio de certificado, una corrección del proxy y una reparación del contenido necesitan responsables distintos.

Para un cambio planificado, ensaya en una copia de pruebas con el mismo tema e integraciones, aislada de los correos a clientes, los pagos reales y las exportaciones para la preparación de pedidos. Conserva una copia de seguridad recuperable y registra los ajustes actuales del servidor, el proxy y la tienda. Después repite los cambios probados en una ventana de producción acordada, con alguien que compruebe los pedidos y las llamadas de retorno. Restaura la configuración afectada si hace falta; sustituir la base de datos de producción por una copia antigua podría descartar los pedidos recibidos desde esa copia.

Elige el punto de partida

Si no está clara la responsabilidad sobre el recorrido de las solicitudes, PrestaShop Hosting & Infrastructure Audit ofrece una evaluación y un informe escrito; la instalación de certificados y los cambios de configuración del servidor son trabajos aparte.

Instala y verifica el certificado

HTTPS cifra la conexión y autentica el nombre de host del servidor mediante su certificado. Domain Validation comprueba el control de un dominio; Organization Validation y Extended Validation añaden comprobaciones de identidad. Esas etiquetas no seleccionan por sí solas un cifrado TLS más fuerte.

Un certificado gratuito con validación de dominio puede satisfacer las necesidades de una tienda. Elige la cobertura, el emisor y los mecanismos de renovación que encajen con tu alojamiento y los requisitos contractuales.

• cPanel: usa SSL/TLS Status y su acción AutoSSL donde tu alojamiento la active. Comprueba el proveedor configurado, los resultados de validación de dominio y el estado de renovación. Consulta la documentación de AutoSSL de cPanel.
• Plesk: usa la gestión de certificados del dominio y la extensión activada de Let's Encrypt o certificados. Confirma la cobertura de hosts y la renovación en el panel instalado; consulta la guía de la extensión de certificados de Plesk.
• Tu propio servidor: sigue las instrucciones de Certbot para tu servidor y sistema operativo. Los complementos Apache y Nginx pueden obtener e instalar certificados; prueba la renovación automática.
• Cloudflare: configura un certificado válido en el origen y usa Full (strict) para conexiones al origen cifradas y con certificado validado. Flexible envía HTTP al origen y puede entrar en conflicto con las redirecciones HTTPS.

Antes de cambiar PrestaShop, abre la tienda y el back office directamente por HTTPS. Comprueba la caducidad del certificado, la cobertura de nombres de host y la validez de la cadena. Incluye cualquier nombre de host alternativo al que se acceda por HTTPS antes de redirigir al nombre preferido: el certificado se comprueba antes de que pueda ejecutarse esa redirección. Mantén disponible el acceso al servidor y a la base de datos para la recuperación.

Los navegadores suelen negociar HTTP/2 sobre TLS, pero el servidor o la CDN deben admitirlo. HTTPS por sí solo no activa HTTP/2 ni garantiza una mejora de velocidad.

Activa los controles de tu versión de PrestaShop

Abre Parámetros de la tienda > Configuración. Comprueba los controles presentes en tu versión instalada.

PrestaShop 9.1

La preferencia SSL usa un control, Activar SSL, respaldado por PS_SSL_ENABLED. Cuando está activado, los controladores de la tienda usan SSL en toda la tienda.

Versiones anteriores con dos controles

PrestaShop 1.7.8 tiene Activar SSL y Activar SSL en todas las páginas, respaldados por PS_SSL_ENABLED y PS_SSL_ENABLED_EVERYWHERE. Tras probar el acceso HTTPS, activa SSL, verifica las páginas afectadas y actívalo después en todas las páginas y vuelve a probar. Comprueba la interfaz real en las demás versiones.

El primer control ya puede afectar a la administración. Activar los controles por fases no garantiza que el acceso HTTP al back office siga disponible.

En Parámetros de la tienda > Tráfico & SEO > SEO y URLs, comprueba los ajustes de URL de la tienda. Los campos de dominio contienen solo nombres de host, como example.com, sin protocolo ni ruta. Configura la ruta base por separado. En multitienda, revisa los registros de URL y el contexto de tienda correspondientes.

Haz coherente la detección del protocolo detrás del proxy

Si TLS termina en un proxy inverso, el protocolo que ve el navegador y la conexión al origen pueden ser distintos. Puede producirse un bucle de redirección cuando la aplicación ve HTTP y redirige a un visitante que ya usa HTTPS. Por ejemplo, un balanceador de carga acepta HTTPS y reenvía HTTP a Apache. La regla de Apache para TLS directo que aparece a continuación ve una solicitud insegura al origen y redirige a la misma URL HTTPS pública en cada visita. Coloca esa redirección en el servicio perimetral o adapta la detección del protocolo al proxy de confianza y después prueba tanto la tienda como la administración.

El método clásico Tools::usingSecureMode() comprueba variables de servidor y también lee X-Forwarded-Proto. Las comprobaciones anteriores de variables de servidor pueden afectar a su resultado. La administración Symfony usa la detección de protocolo seguro de su objeto de solicitud y la configuración de proxies de confianza.

En la administración de PrestaShop 9, establece PS_TRUSTED_PROXIES con las direcciones reales de los proxies según requiera tu despliegue. Haz que el proxy sobrescriba las cabeceras reenviadas, impide que clientes no fiables las falsifiquen y expón un protocolo coherente a PHP. No confíes en direcciones arbitrarias de proxy.

Con Cloudflare, comprueba conjuntamente el modo de cifrado y las redirecciones del origen. Full (strict) valida la conexión al origen, pero las reglas contradictorias de host o protocolo aún pueden provocar bucles. Usa las comprobaciones de bucles de redirección de Cloudflare para revisar ambas capas.

Añade redirecciones canónicas en la capa correcta

Cuando HTTPS funcione, redirige las URL HTTP antiguas al host HTTPS elegido. Conserva las rutas y las cadenas de consulta. Comprueba que las etiquetas canónicas finales, los enlaces internos y el sitemap coincidan.

Prioriza una regla del host virtual o del servicio perimetral si TLS termina ahí. En Apache, las reglas personalizadas deben ir fuera del bloque generado de PrestaShop delimitado por # ~~start~~ y # ~~end~~. La regeneración del núcleo conserva el contenido exterior a esos marcadores y puede sustituir las reglas interiores.

El siguiente ejemplo es para Apache con terminación TLS directa y example.com como host elegido. No cubre un proxy que se conecta a Apache por HTTP:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
</IfModule>

Prueba con redirecciones temporales antes de adoptar una regla permanente. Detrás de un proxy, redirige en el servicio perimetral o configura el servidor para usar el protocolo original indicado por tu proxy de confianza. Una condición simple HTTPS !=on puede provocar un bucle ahí.

En Cloudflare, Always Use HTTPS redirige las solicitudes HTTP en el servicio perimetral; configura Full (strict) por separado para la conexión al origen. Nginx utiliza la configuración de bloques de servidor en lugar de .htaccess. Para más reglas a nivel de archivo, utiliza la guía de .htaccess de PrestaShop.

Busca y corrige contenido mixto

Abre los paneles Consola y Red del navegador en páginas HTTPS. Hay contenido mixto cuando una página segura solicita un recurso inseguro. Los navegadores bloquean algunos tipos de recurso y pueden actualizar otros a HTTPS. Comprueba la URL y el fallo en lugar de deducirlos de un diseño roto.

• Las descripciones de productos y categorías y el contenido CMS pueden contener URL absolutas HTTP de imágenes.
• Los módulos pueden registrar URL inseguras de CSS o JavaScript. Utiliza el iniciador de la solicitud en el panel Red para rastrear el origen; después actualiza el módulo o pide a su responsable que corrija la generación de URL.
• El CSS del tema puede contener fuentes o imágenes de fondo HTTP.
• Los vídeos, la analítica y las inserciones sociales externas necesitan soporte HTTPS.
• Las imágenes de correo también necesitan URL HTTPS válidas para el cliente de correo, aunque el renderizado del correo es independiente del contenido mixto de la tienda.

Usa editores compatibles o una migración dirigida tras una copia de seguridad. Comprueba product_lang.description, product_lang.description_short, category_lang.description y cms_lang.content cuando corresponda. Limita los cambios al host, la tienda y los campos previstos; no ejecutes una sustitución ciega en toda la base de datos.

Para los recursos de la tienda, utiliza en adelante HTTPS o URL relativas a la raíz adecuadas. Usa URL HTTPS absolutas para las imágenes de correo. Confirma que los hosts de terceros realmente sirvan la URL sustituta. Las cabeceras de seguridad no pueden reparar un archivo ausente ni un fallo de certificado.

Actualiza los servicios externos y las URL generadas

Regenera los sitemaps con la herramienta instalada y revisa las URL que emite. Actualiza las páginas de destino de productos, los feeds, los destinos publicitarios y las URL del sitio configuradas para que coincidan con el sitio HTTPS canónico.

En Search Console, una propiedad de dominio existente cubre HTTP y HTTPS. Si usas propiedades de prefijo de URL, añade o verifica el prefijo HTTPS cuando haga falta. Consulta la guía de tipos de propiedad de Google.

Comprueba la gestión de llamadas de retorno de pagos con el proveedor instalado y la versión del módulo. Actualiza las direcciones de webhooks o notificaciones configuradas en el panel cuando la integración las use. Otras integraciones envían la URL de retorno al crear un pago, así que comprueba una transacción de prueba recién creada, además del panel del proveedor.

Completa un pago y confirma que la llamada de retorno cambia el estado del pedido. Que funcione la página de retorno del navegador por sí sola no basta.

Recupera el acceso sin modificar todas las tiendas

1. Registra la URL que falla, la tienda afectada y si falla la tienda, la administración o ambas. Mantén disponible el acceso al alojamiento, los archivos y la base de datos fuera del back office averiado.
2. Inspecciona la cadena de redirecciones con un cliente sin estado previo y registra qué host o capa emite cada redirección. Compara la URL solicitada con el valor Location de cada respuesta para detectar direcciones repetidas o nombres de host que se alternan.
3. Comprueba los errores del certificado, el modo de la CDN, las reglas del servidor y las cabeceras reenviadas. Modifica la capa que causa el fallo y vuelve a probar antes de cambiar otra.
4. Si la imposición de SSL en la aplicación impide el acceso, haz una copia de seguridad e inspecciona las filas de configuración pertinentes antes de cambiarlas. Registra el contexto de tienda activo, los identificadores de tienda y grupo y cualquier configuración heredada para poder identificar el valor efectivo.

SELECT id_configuration, name, value, id_shop_group, id_shop
FROM ps_configuration
WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE');

Utiliza tu prefijo real. Cambia solo la fila o filas de configuración previstas para el alcance afectado y únicamente las claves que utilice esa versión. Evita una actualización sin restricciones en todas las tiendas. Conserva los valores originales y un registro de cada cambio. Restaura la configuración segura después de corregir la causa y prueba la tienda afectada y, en multitienda, otra que comparta la instalación.

Un cambio en la aplicación no puede eliminar redirecciones del servidor web o la CDN, reparar las cabeceras del proxy ni borrar el estado HSTS del navegador. Mantén el tráfico de clientes fuera de una sesión de recuperación insegura. Vacía la caché desde Parámetros avanzados > Rendimiento o con el comando de consola compatible, usando el entorno y el usuario de aplicación correctos. Vuelve a abrir la administración, realiza un pedido de prueba y confirma su llamada de retorno de pago antes de admitir tráfico normal. Concilia los pagos recibidos durante la incidencia antes de pedir a los clientes que lo intenten de nuevo.

Verifica el resultado antes de añadir HSTS

1. Comprueba la seguridad de la conexión y el estado del certificado en el navegador. El icono varía según el navegador y la versión.
2. Prueba las páginas de inicio, producto, categoría, CMS, acceso y compra con la consola limpia. Utiliza el tema real y los métodos de pago activados en escritorio y móvil, cubriendo los idiomas, monedas y tiendas que ofreces.
3. Comprueba todo el back office por HTTPS.
4. Prueba HTTP y HTTPS para cada nombre de host configurado de la tienda afectada, incluidos www y sin www cuando corresponda. Confirma que las direcciones alternativas redirijan al nombre de host HTTPS elegido para esa tienda conservando las rutas y las cadenas de consulta. El ejemplo de Apache anterior solo redirige HTTP; si sigue siendo accesible un nombre de host HTTPS alternativo, configura su redirección de host en la capa adecuada.
5. Completa un pago de prueba, incluida su llamada de retorno. Asocia la referencia del proveedor con el pedido resultante y el estado esperado; conserva el resultado para la persona que supervise el cambio.
6. Prueba la renovación del certificado, designa a la persona responsable de los fallos de renovación e inspecciona el despliegue con un comprobador TLS como SSL Labs.

curl -I https://example.com/
curl -I http://example.com/

HSTS indica a los navegadores que usen HTTPS durante un periodo recordado. Actívalo cuando el sitio sea estable, con una duración prudente. Añade includeSubDomains o preload solo tras comprobar todos los hosts afectados. HSTS hace ineficaz una reversión a HTTP en los navegadores que han recordado la política.

Para los controles de cabeceras de seguridad compatibles con Security Revolution, utiliza la página de ayuda del módulo y confirma cuáles ofrece tu versión instalada.

Qué preguntar a tu desarrollador o agencia

• ¿Dónde termina TLS, qué capa se encarga de las redirecciones canónicas y en qué direcciones de proxy confía la aplicación?
• ¿Qué ajustes e integraciones específicos de la tienda han cambiado y dónde están los resultados de las pruebas en el entorno de pruebas y en producción?
• ¿Cómo se restaura el acceso si falla la administración y qué limitaciones imponen las redirecciones en caché o HSTS?
• ¿Quién supervisa la renovación, los fallos de llamadas de retorno y los nuevos pedidos después del cambio, y dónde están las instrucciones de recuperación?

Preguntas de los propietarios

¿Puede HTTPS hacer segura una tienda comprometida?

HTTPS protege la conexión con el nombre de host. No elimina el código malicioso de tu tema o módulos; una página comprometida puede seguir enviando a los clientes a un formulario de pago fraudulento por HTTPS.

¿Por qué rechaza una llamada de retorno el proveedor de pagos si mi navegador abre la página?

El proveedor es un cliente independiente. Comprueba su error de entrega, la cadena pública de certificados, la autenticación del endpoint y la respuesta. Una sesión de navegador puede estar ya autenticada mientras que el proveedor recibe una página de acceso o un desafío; una notificación redirigida también puede comportarse de forma distinta a la solicitud original.

¿Debo sustituir todos los enlaces HTTP de mi contenido?

Identifica si se trata de un recurso cargado o de un enlace normal a otro sitio. Repara los recursos y las URL canónicas de tu tienda según sea necesario; no reescribas a ciegas enlaces externos ajenos cuyo destino puede no admitir HTTPS.

¿Puedo conservar el nombre de host de pruebas tras un ensayo correcto?

Utiliza el entorno de pruebas para demostrar el método y después aplica los ajustes acordados para el nombre de host de producción. Busca direcciones del entorno de pruebas en el contenido, los ajustes de módulos, los feeds y las URL de llamadas de retorno antes de reabrir la tienda en producción.