PrestaShop treats HTTPS differently from most content management systems. Instead of relying purely on the web server or a single configuration file, it stores protocol preferences inside the database and injects Rewrite rules into your .htaccess whenever you regenerate the store's SEO and URL settings. When a certificate is installed but the shop still serves pages over plain HTTP, redirects loop endlessly, or the browser padlock breaks with mixed-content warnings, the fault almost always lies in the gap between what the web server reports and what PrestaShop believes about the connection. Understanding that split is what makes these problems solvable from an unprivileged hosting account.

How PrestaShop Decides a Request Is Secure

Every PrestaShop request passes through Tools::usingSecureMode(), which inspects PHP superglobals to determine whether the visitor arrived over TLS. On a direct LiteSpeed connection this is straightforward: the server sets $_SERVER['HTTPS'] to on and PrestaShop is satisfied. The complication appears on the Hostiso stack because LiteSpeed frequently terminates TLS at an edge layer and forwards the request internally. In that arrangement the backend PHP process may see the request as plain HTTP even though the visitor's browser negotiated a valid certificate. PrestaShop then concludes the connection is insecure, issues a redirect back to the HTTPS front controller, and the loop begins.

Two database values govern the store's behavior, both stored in the ps_configuration table (your prefix may differ). PS_SSL_ENABLED tells PrestaShop that a certificate exists and HTTPS is available, while PS_SSL_ENABLED_EVERYWHERE forces every page — not just checkout and account areas — onto HTTPS. If you flip these on before a valid certificate is actually serving, or before the proxy detection is corrected, the storefront becomes unreachable and you lock yourself out of the admin. That risk is why the order of operations matters far more than the individual settings.

Start by confirming a certificate is live. In cPanel Jupiter, open Security → SSL/TLS Status and verify the domain shows a valid AutoSSL or Let's Encrypt certificate covering both the bare domain and the www host. In DirectAdmin Evolution the equivalent is Account Manager → SSL Certificates, where you request a free Let's Encrypt certificate and tick both hostnames. Load https://yourdomain.com directly in a browser and check the padlock before touching any PrestaShop setting. If the certificate itself is missing or only covers one hostname, no amount of shop configuration will fix the padlock.

Enabling SSL Inside the PrestaShop Dashboard

With the certificate confirmed, log into the back office and navigate to Shop Parameters → General. PrestaShop displays an Enable SSL toggle with a link labelled Please click here to check if your shop supports HTTPS. Clicking that link forces a secure request; if the page reloads over HTTPS without error, set Enable SSL to Yes and save. Only after that succeeds should you enable Enable SSL on all pages. Save again and let PrestaShop rewrite its configuration.

When the back office redirect loops before you can reach that screen, edit the values directly through phpMyAdmin rather than guessing. Open phpMyAdmin from cPanel or DirectAdmin, select your shop database, and run a targeted query against the configuration table. Adjust the prefix to match your install:

UPDATE ps_configuration SET value = '1' WHERE name = 'PS_SSL_ENABLED';
UPDATE ps_configuration SET value = '1' WHERE name = 'PS_SSL_ENABLED_EVERYWHERE';

The domain values live in the ps_shop_url table. Confirm that domain and domain_ssl both hold the exact hostname visitors use, with no trailing slash and no http:// prefix:

UPDATE ps_shop_url SET domain = 'yourdomain.com', domain_ssl = 'yourdomain.com' WHERE id_shop = 1;

After changing configuration in the database, clear the compiled cache so the new values take effect. Using File Manager, navigate to your document root and delete the contents of /var/cache/prod/ (or /var/cache/dev/ if debug mode is on). Removing the files there forces PrestaShop to rebuild its container with the corrected protocol settings on the next request. Never delete the folders themselves, only the files inside.

Forcing HTTPS in .htaccess and Handling the Proxy Header

PrestaShop generates its own rewrite block bounded by # ~~start~~ and # ~~end~~ comments in .htaccess. You can regenerate it from Shop Parameters → Traffic & SEO by clicking Save at the bottom, which writes fresh rules. If the automatically generated redirect does not stick, add an explicit rule above the PrestaShop block. Open the site's root .htaccess in File Manager and place this near the top:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

The second condition is what resolves proxy loops. When LiteSpeed sits behind a TLS-terminating layer, it forwards the original scheme in the X-Forwarded-Proto header. Checking that header prevents the rule from firing on requests that are already secure at the edge but appear plain to the backend, which is the exact scenario that produces infinite redirects.

PrestaShop also needs to read that header when it builds internal URLs. Because you cannot edit server-wide PHP settings, use a .user.ini file in the document root to keep the environment sane, and confirm the PHP version in cPanel MultiPHP Manager or DirectAdmin's PHP Selector matches your PrestaShop version (8.x expects PHP 8.1 or newer). If the proxy detection still fails, define the trusted behavior in config/settings.inc.php or, on PrestaShop 1.7.8+, in app/config/parameters.php, where the array key that enables reverse-proxy awareness lives alongside the database credentials. Set the trusted proxy option so Tools::usingSecureMode() honors the forwarded header rather than the raw connection.

Clearing Mixed-Content Warnings and Verifying the Result

Once redirects behave, the padlock may still show a warning because older content references http:// assets. PrestaShop hardcodes some URLs into the database when products, CMS pages, or theme settings are saved over HTTP. Open your browser's developer console on the storefront and read the mixed-content messages; each one names the insecure resource. Most originate from image tags and inline links stored in ps_cms, ps_cms_lang, and ps_product_lang. Correct them with a scoped phpMyAdmin update, testing on one table first:

UPDATE ps_cms_lang SET content = REPLACE(content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE ps_product_lang SET description = REPLACE(description, 'http://yourdomain.com', 'https://yourdomain.com');

Always export a backup of these tables before running replacements, since a bad pattern can corrupt serialized theme configuration. Avoid protocol-relative shortcuts inside serialized fields; targeted absolute-to-absolute replacements are safer. After updating, empty /var/cache/prod/ again and hard-refresh the storefront.

Finish by confirming the whole chain end to end. Load the homepage, a category, a product page, the cart, and the login page, watching that each stays on HTTPS with a clean padlock. Check the store's own log at /var/logs/ and the account error log for any residual redirect or SSL warnings. If you manage TLS-sensitive callbacks such as payment webhooks, the same forwarded-header logic applies to server-to-server requests; the approach used for Joomla payment callbacks and TLS handshake failures maps directly onto PrestaShop's cURL-based gateways. With the certificate valid, the database protocol flags set, proxy awareness corrected, and legacy URLs rewritten, the storefront serves consistently over HTTPS without loops or warnings.