iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
To enable HTTPS on a PrestaShop shop hosted on a VPS, point every shop hostname to the server, obtain a Let’s Encrypt certificate with Certbot, configure Apache or Nginx to serve the full certificate chain on port 443, enable PrestaShop’s secure URL behavior, and then test renewal and every customer-facing workflow. A certificate installed only at the web-server level is not enough: PrestaShop, redirects, proxies, themes, modules, payment callbacks, and scheduled renewal all have to agree that HTTPS is the canonical protocol.
The safest order is DNS and firewall preparation, deployment inventory and backups, certificate issuance, web-server configuration, PrestaShop configuration, functional testing, renewal verification, and only then optional HSTS. The exact commands differ by Linux distribution and by whether the VPS runs Apache or Nginx, so treat configuration examples as templates and adapt paths, PHP integration, and hostnames to your installation.
What must be ready before you request a certificate
Let’s Encrypt validates control of domain names. It does not issue a normal publicly trusted certificate for a bare VPS IP address. Decide the canonical shop name first, such as example.com or www.example.com, and include every other name customers or integrations will use.
Record the deployment
- PrestaShop major and minor version, including whether the store is single-store or multistore.
- Linux distribution and release, web server (Apache or Nginx), and whether PHP runs through PHP-FPM or an Apache module.
- The actual PrestaShop document root and the virtual-host files that serve it.
- The canonical hostname, the intended behavior of the
wwwvariant, and any subdomains used for images, APIs, checkout, or administration. - Any reverse proxy, CDN, load balancer, or provider firewall in front of the VPS.
Back up the web-server configuration, PrestaShop files, and database before changing TLS or redirect rules. Certbot can edit supported Apache and Nginx configurations, but a configuration backup gives you a clear rollback path if a virtual host is selected incorrectly or a syntax error prevents reload.
#1 Best Overall
Make DNS authoritative before ACME validation
Create an A record for each hostname that should resolve to the VPS IPv4 address and an AAAA record only when the server is correctly reachable over IPv6. Check that the records resolve publicly to this VPS before running Certbot. If an old address remains in DNS, the validation request can reach the wrong server even though the new configuration is correct.
Permit inbound TCP 80 and 443 in both the VPS operating-system firewall and the hosting provider’s firewall. HTTP-01 validation requires Let’s Encrypt to reach port 80 from the Internet. DNS-01 validation places a challenge in DNS instead and is useful when port 80 cannot be exposed, when a service is behind a private network, or when a wildcard certificate is required.
Recommended Free Tools
| Validation method | What it needs | When to choose it |
|---|---|---|
| HTTP-01 | Public DNS for the hostname and an Internet-reachable TCP port 80 serving the ACME challenge path | The ordinary choice for a web server that can accept HTTP traffic |
| DNS-01 | Ability to create the required ACME TXT records in the domain’s DNS service | Port 80 cannot be opened, or the certificate must cover a wildcard name |
Do not enable a blanket HTTP-to-HTTPS redirect that blocks the challenge path before issuance. A redirect can coexist with HTTP-01, but the ACME client must still be able to retrieve its token under /.well-known/acme-challenge/.
Install Certbot using the method for your operating system
Use the current Certbot instructions for the actual Linux distribution and web server on the VPS. Package names, plugin availability, and supported installation methods vary; an Ubuntu command copied to another distribution can install an obsolete client or omit the Apache/Nginx plugin.
The documented snap-based approach installs Certbot, links /snap/bin/certbot into /usr/local/bin, and then uses the appropriate web-server installer. If your distribution provides another currently supported method, follow that method instead. Confirm the installed client with certbot --version and keep the client updated so renewal remains supported.
Choose an installation mode
| Mode | Example | Effect |
|---|---|---|
| Apache installer | sudo certbot --apache |
Obtains a certificate and edits a supported Apache virtual host |
| Nginx installer | sudo certbot --nginx |
Obtains a certificate and edits a supported Nginx server block |
| Certificate only | sudo certbot certonly |
Obtains files while leaving web-server configuration under your control |
The integrated installers are convenient when Certbot can unambiguously identify the correct virtual host. Use certonly when you manage configuration manually, use a nonstandard proxy layout, or need a controlled change review before the server begins redirecting traffic.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesObtain a certificate for every hostname customers use
Using the Apache or Nginx installer
After DNS and firewall checks, run the installer for the existing stack. Certbot will ask which names to include and whether HTTP should redirect to HTTPS. Select all names served by the same shop and verify that the selected virtual host has matching server_name (Nginx) or ServerName/ServerAlias (Apache) values.
Rank #2
For a shop that accepts both the apex and www name, the resulting request must include both, conceptually equivalent to -d example.com -d www.example.com. Add each required subdomain explicitly. A certificate for only the apex does not cover www, and a certificate for www does not cover the apex.
Using webroot with certonly
When you want to edit the server configuration yourself, use an authenticator appropriate to your layout. A webroot request has the following shape:
sudo certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Replace /var/www/letsencrypt with a directory that the HTTP virtual host actually exposes. Certbot writes a token below /.well-known/acme-challenge/; the web server must return that file without routing it to the PrestaShop front controller. If the site uses DNS-01, use the DNS authenticator supported by your DNS provider instead and create the required TXT records.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
After a successful request, Certbot stores the live certificate material under /etc/letsencrypt/live/<certificate-name>/. The exact certificate name can include a numeric suffix if an earlier certificate used the same names, so inspect the directory rather than assuming its name.
Configure Nginx to serve the certificate correctly
Adapt PrestaShop’s official Nginx template to the real document root, PHP socket, hostnames, and application rules. The TLS server block must listen on 443, identify the correct names, and present the full chain and private key:
server {
listen 443 ssl http2;
server_name example.com www.example.com;
root /var/www/prestashop;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Keep the remainder of the PrestaShop location and PHP-FPM rules here.
}
Use fullchain.pem, not only the leaf certificate, so browsers receive the intermediate chain. Protect privkey.pem with the permissions expected by the web-server process; never place the private key in the document root or commit it to a repository.
Keep an HTTP server block for redirects and challenges
The port-80 block should serve the ACME directory and redirect all other requests once to the chosen canonical HTTPS hostname:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →server {
listen 80;
server_name example.com www.example.com;
location ^~ /.well-known/acme-challenge/ {
root /var/www/letsencrypt;
}
location / {
return 301 https://example.com$request_uri;
}
}
If www is canonical, change the redirect target accordingly. Do not create a redirect loop by sending HTTPS traffic back to HTTP. If a reverse proxy terminates TLS before Nginx, configure the proxy and Nginx consistently and ensure the original protocol is conveyed; otherwise PrestaShop may generate HTTP links even though the browser connected over HTTPS.
Run sudo nginx -t before reloading. A successful syntax test does not prove that the right certificate is served, so inspect the live endpoint afterward and confirm that its names and chain match the request. Reload only after the test passes.
Configure Apache when Apache serves PrestaShop
For Apache, create or adapt a TLS virtual host that points to the actual PrestaShop directory and references the certificate and key produced by Certbot. Enable the SSL and rewrite modules required by the distribution, and retain AllowOverride All in the relevant directory when PrestaShop’s .htaccess rules are needed.
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/prestashop
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
<Directory /var/www/prestashop>
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
The Apache example is a template, not a drop-in file. Adapt the PHP handler, directory permissions, logging, and any existing proxy or application rules. Keep a port-80 virtual host for the ACME path and an intentional permanent redirect to the canonical HTTPS URL.
Validate the complete configuration with sudo apachectl configtest (or the distribution’s equivalent) before reloading Apache. Check that the enabled site, rather than an unused template file, owns the requested names on port 443.
Turn on secure URLs inside PrestaShop
Once the web server serves a valid certificate, enable PrestaShop’s SSL or secure-URL setting in the Back Office for the relevant shop context. The label and location vary by major version, so use the SSL/secure URL control in the shop’s general settings rather than changing database values blindly. Clear PrestaShop’s cache after changing the setting and regenerate or verify rewritten URLs.
The command-line installer exposes an ssl option from PrestaShop 1.7.4 onward. That option is useful during a new installation; an existing shop still needs its Back Office configuration and a full functional test after the web-server change.
Rank #4
Require SSL for sensitive controllers
PrestaShop documents SSL-aware front controllers that redirect non-SSL requests. Review custom modules and controllers so login, customer account, checkout, payment-return, and administrative paths require HTTPS. A server certificate does not automatically correct a module that emits an absolute http:// callback or loads an insecure API endpoint.
Check every multistore and integration context
In a multistore deployment, review each shop and domain context separately. Update canonical URLs, payment-module return addresses, webhook endpoints, API integrations, scheduled-job URLs, and any CDN or reverse-proxy origin setting to HTTPS. Keep each hostname on the certificate and in the matching virtual host.
Test redirects, assets, sessions, and checkout
Test from a clean browser session and, where possible, from a network outside the VPS provider. Visit the canonical HTTPS URL and verify the browser’s lock indicator, as Certbot’s verification guidance recommends. Then test the alternate hostname and confirm that it redirects once to the canonical HTTPS name.
| Area | Expected result |
|---|---|
| HTTP homepage | One permanent redirect to the selected HTTPS hostname, with the original path and query preserved |
| HTTPS homepage and category pages | Valid certificate, correct hostname, and no certificate-chain warning |
| Back Office | Login works without returning to HTTP; session remains active after navigation |
| Customer account and cart | Forms, cookies, and redirects remain on HTTPS |
| Checkout and payment return | Payment callbacks and return URLs use the HTTPS address registered with the provider |
| Images, CSS, and JavaScript | All resources load over HTTPS with no browser mixed-content errors |
| Module AJAX and APIs | Requests use HTTPS and receive the expected status rather than a redirect or blocked mixed request |
Open browser developer tools and inspect the Console and Network panels for mixed-content failures. Search theme files, module configuration, and generated settings for hard-coded http:// references. Also check proxy behavior: if the proxy terminates TLS but fails to pass the original protocol, the application can keep generating HTTP URLs.
Free tools Windows power users keep installed
One-click scans. No signup required.
Confirm that credentials, cart data, and session cookies are never sent over an HTTP page. A redirect protects a normal browser navigation, but it does not repair an insecure absolute URL embedded in an image, script, form action, webhook, or API configuration.
Automate renewal and reload the new certificate
Let’s Encrypt certificates are short-lived, so issuance is only half the job. Use the Certbot timer or cron job installed by your chosen method and inspect its schedule. Certbot’s recurring certbot renew operation renews certificates that are close to expiry, but renewal is incomplete if Nginx or Apache continues serving the old certificate from memory.
Perform a staging dry run
Run a staging renewal test where supported by your Certbot setup. A dry run checks the authenticator, DNS or HTTP challenge path, permissions, and renewal configuration without consuming a production certificate. Resolve any challenge or hook error before relying on unattended renewal.
Best Value
Reload after successful renewal
Configure the appropriate deploy hook or service action so Apache or Nginx reloads after Certbot replaces the live files. A reload normally preserves active connections while causing new connections to use the renewed certificate; use the service command appropriate to your distribution and stack. Do not restart blindly in a production checkout window.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →After a real renewal, verify both the file timestamps and the certificate presented on port 443 from an external connection. Confirm the new expiration date and names. Keep Certbot updated, and monitor its timer or logs so a DNS, firewall, permission, or hook failure is visible before the certificate expires.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Enable HSTS only after the migration is complete
HTTP Strict Transport Security tells browsers to refuse future HTTP connections for a period you specify. PrestaShop’s Nginx example includes an HSTS configuration with a warning: do not use it while any required part of the site is not fully on HTTPS.
Wait until every shop hostname, asset, callback, API, administrative path, and subdomain that browsers must reach works over HTTPS. Confirm that renewal is reliable and that you will not need ordinary HTTP access for recovery. Then introduce HSTS deliberately, starting with a conservative policy and expanding only after observing real traffic. HSTS can make an incorrect redirect or an omitted hostname appear permanently broken in returning browsers until the policy expires.
Choose the least risky architecture for your existing stack
| Decision | Use this when | Main trade-off |
|---|---|---|
| Certbot Apache/Nginx installer | The supported web server owns the public virtual host and you want Certbot to make standard edits | Fast setup, but review generated redirects and selected virtual hosts before accepting them |
certonly with manual configuration |
You have a proxy, custom layout, or change-control process | More control, but you must configure certificates, redirects, reload hooks, and challenge paths yourself |
| HTTP-01 | Port 80 can be reachable and the hostname serves a normal web site | Simple web validation, but blocked port 80 prevents issuance or renewal |
| DNS-01 | Port 80 cannot be exposed or wildcard coverage is needed | Requires reliable automated DNS TXT changes and cleanup |
| Nginx | Nginx already fronts the shop and its PHP-FPM configuration is working | Efficient front end, but server blocks and proxy protocol handling must be correct |
| Apache | Apache and PrestaShop’s existing .htaccess rules are already in use |
Familiar per-directory rules, but modules and PHP handler settings must match the installation |
Troubleshoot the failures that occur most often
Certbot says the domain does not resolve to this server
Check A and AAAA records for every requested name, remove stale records, and verify public DNS from a network that is not the VPS itself. If an AAAA record points to an unreachable IPv6 address, validation may fail even when IPv4 works; either fix IPv6 routing or remove the incorrect record.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchHTTP-01 validation times out
Confirm that both provider and operating-system firewalls allow TCP 80, that the VPS has a public route, and that the port-80 virtual host answers the requested hostname. Test the exact challenge directory without letting PrestaShop rewrite it to a controller. If policy prevents opening port 80, switch to DNS-01.
The browser reports an incomplete chain
Point the web server at Certbot’s fullchain.pem rather than only the leaf certificate, keep the private key in privkey.pem, reload the service, and retest the endpoint. A correct file on disk is not proof that the active process loaded it.
HTTPS redirects in a loop
Look at every hop: browser, CDN or reverse proxy, web server, and PrestaShop. A TLS-terminating proxy must tell the origin that the original request was HTTPS. Remove conflicting redirect rules and ensure the HTTP block redirects to one canonical HTTPS hostname while the HTTPS block serves content directly.
PrestaShop still generates HTTP links
Recheck the Back Office SSL setting for the current shop context, clear cache, and inspect canonical URL configuration. Then search themes and modules for hard-coded HTTP assets or callbacks. If only proxied requests are affected, correct the original-protocol forwarding between the proxy and web server.
Renewal succeeds but visitors see the old expiry date
Check whether the deploy hook reloads Apache or Nginx, identify which process owns port 443, and compare the active certificate with the files under /etc/letsencrypt/live/. In a proxy or load-balanced setup, every TLS-terminating node must receive and load the renewed certificate.
Quick Recap
Final production checklist
- Every apex,
www, and required subdomain resolves to the intended VPS or TLS proxy. - TCP 80 and 443 are allowed wherever the selected validation and serving design requires them.
- The certificate includes every customer-facing hostname and the server presents the full chain on 443.
- The HTTP challenge path remains reachable during issuance and renewal.
- Apache or Nginx passes its configuration test and reloads cleanly.
- PrestaShop secure URLs, controller requirements, multistore domains, callbacks, and webhooks use HTTPS.
- Homepage, Back Office, login, cart, checkout, payment return, assets, and module AJAX calls pass without mixed content.
- A staging renewal dry run succeeds, and a deploy hook reloads the active web server.
- HSTS is deferred until the entire required site is HTTPS and recovery procedures are understood.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

