PrestaShop Lightsail : DNS, nom de domaine et HTTPS Let’s Encrypt

Table des matières :

Pré-requis (versions, réseau, et points de rupture classiques)
DNS sur Lightsail : IP statique, zone DNS, A/AAAA et TTL
Câbler le nom de domaine côté PrestaShop (URL boutique, multiboutique, redirections)
HTTPS Let’s Encrypt sur Lightsail : ACME, HTTP-01 vs DNS-01, Certbot et Bitnami
Durcissement TLS et hygiène applicative (redirects, headers, mixed content)
Renouvellement automatique et monitoring (sinon vous finirez en incident)
Dépannage reproductible : DNS, ACME, boucles 301, et erreurs “fantômes”

Sur Amazon Lightsail, la partie “nom de domaine + DNS + HTTPS” est souvent ce qui fait perdre du temps sur un déploiement PrestaShop : vous avez plusieurs plans de contrôle (Lightsail, registrar, éventuellement Cloudflare), des caches DNS, et un cœur PrestaShop qui tolère mal les incohérences domain/domain_ssl (boucles 301, mixed content, BO inaccessible). Le but ici est d’avoir une chaîne propre : IP stable → DNS correct → vhost correct → certificat ACME (Let’s Encrypt) → redirections et durcissement.

Ce qui fait “déraper” le plus souvent, ce n’est pas un bug exotique : c’est une couche configurée “à moitié” (DNS OK mais vhost pas prêt, ou HTTPS actif dans PrestaShop avant que le serveur ne serve vraiment le certificat). La bonne approche est de valider chaque brique avec un test simple, puis seulement de passer à l’étape suivante.

Pré-requis (versions, réseau, et points de rupture classiques)

Pour rester concret : les commandes ci-dessous visent Linux Debian/Ubuntu (typiquement ce que vous obtenez avec une instance Lightsail ou une image Marketplace). Côté applicatif, l’article s’applique à PrestaShop 8.1/8.2 et PrestaShop 9.x (2026), avec PHP 8.2+ (souvent 8.2/8.3 en production). Si vous utilisez l’image “PrestaShop packaged by Bitnami” sur Lightsail, vous avez une arborescence et des scripts spécifiques (on y revient).

Avant de toucher au DNS et au HTTPS, ouvrez le minimum côté réseau : dans Lightsail (onglet Networking), autorisez TCP 80 et TCP 443 vers l’instance, et vérifiez l’absence de blocage local (ufw, iptables, security hardening maison). Tant que le port 80 n’est pas joignable depuis Internet, le challenge HTTP-01 ACME échouera (erreur connection refused ou timeout).

Deux vérifications “basiques” qui évitent de chercher du côté de PrestaShop alors que c’est du réseau :

Depuis l’extérieur, validez l’accessibilité :

  # depuis une machine hors du serveur (votre PC, ou un autre VPS)
  curl -I http://IP_PUBLIQUE
  curl -I http://example.com

Depuis le serveur, validez que le service écoute :

  sudo ss -lntp | egrep ':80|:443'

Enfin, prévoyez un plan de rollback. Une bascule HTTPS mal enchaînée peut vous enfermer hors du back-office (redirection infinie + cookie + proxy). Ayez sous la main : accès SSH, accès base (ou au moins dump), et une méthode pour désactiver temporairement la redirection HTTPS côté vhost.

Pour la partie exploitation, vous gagnerez du temps à avoir déjà de la visibilité sur les logs serveur. Si vous êtes sur Lightsail avec MySQL local, l’article interne sur l’activation des logs est utile : Logs Amazon Lightsail : activer general log et slow query MySQL.

DNS sur Lightsail : IP statique, zone DNS, A/AAAA et TTL

Le point non négociable : attachez une IP statique Lightsail à votre instance avant de configurer le DNS. Une IP dynamique (au redémarrage / reconstruction) vous force à “courir après” les enregistrements DNS. Dans Lightsail : Networking → Create static IP → Attach.

Astuce migration (cas très fréquent en e-commerce) : si vous remplacez un serveur existant par Lightsail, baissez le TTL de votre A/AAAA (par ex. à 300 secondes) 24 à 48 h avant la bascule. Ça réduit mécaniquement la durée pendant laquelle des visiteurs tomberont sur l’ancien serveur après le switch.

Ensuite, vous avez trois architectures DNS courantes :

1) DNS chez le registrar (le plus simple) : vous créez un A vers l’IP statique et éventuellement un CNAME www vers le domaine racine.

2) Zone DNS Lightsail : vous déléguez votre domaine vers les nameservers Lightsail en modifiant les NS chez votre registrar. AWS documente le service DNS Lightsail ici : https://docs.aws.amazon.com/lightsail/latest/userguide/understanding-dns-in-amazon-lightsail.html

3) Route 53 / Cloudflare : utile si vous voulez du DNS avancé (DNSSEC, API de gestion, politiques de routage). Pour Let’s Encrypt en wildcard (DNS-01), une API DNS est un vrai plus.

Sur PrestaShop, la convention la plus robuste (et la moins source de surprises SEO) est : un domaine canonique (ex. example.com) + un alias (www.example.com) redirigé en 301, ou l’inverse. DNS minimal :

A @ → IP statique Lightsail
CNAME www → @ (ou un A si votre provider ne supporte pas CNAME au niveau www correctement)

Deux points qui évitent des erreurs “bizarres” :

Pas de CNAME à l’apex (@) : beaucoup de DNS providers l’interdisent pour des raisons de standard DNS. Si vous voyez des options “ALIAS/ANAME”, c’est une extension provider — utile, mais pas indispensable ici (un A suffit).
Attention à l’AAAA : évitez de publier un AAAA (IPv6) si votre instance n’est pas réellement joignable en IPv6. Un client qui préfère IPv6 (Happy Eyeballs) peut produire des erreurs intermittentes difficiles à diagnostiquer (alternance “ça marche / ça timeoute”).

Validez systématiquement avec dig depuis une machine neutre :

dig +short A example.com
dig +short CNAME www.example.com

Complétez au besoin par une vérification de délégation (quand vous utilisez la zone Lightsail mais que “rien ne change”) :

dig +short NS example.com

et vérifiez les TTL et la propagation (un TTL trop long rallonge les fenêtres de migration). Évitez aussi de modifier d’autres enregistrements “annexes” sans raison (MX, SPF/DMARC) : ils ne sont pas nécessaires à PrestaShop, mais une mauvaise manipulation pendant une migration DNS peut impacter la délivrabilité e-mail.

Mini-scénario (classique) : vous avez configuré une zone DNS Lightsail, mais vous n’avez pas mis à jour les NS chez le registrar. Résultat : vous éditez la “bonne” zone… qui n’est jamais interrogée. Dans ce cas, dig NS vous montre des nameservers qui ne sont pas ceux de Lightsail : corrigez d’abord la délégation, puis attendez la propagation.

Câbler le nom de domaine côté PrestaShop (URL boutique, multiboutique, redirections)

PrestaShop stocke l’URL “réelle” de la boutique dans ps_shop_url (ou PREFIX_shop_url) : champs domain, domain_ssl, physical_uri, virtual_uri. C’est un point faible historique du cœur : si domain_ssl n’est pas cohérent avec ce que sert votre front (et avec les en-têtes proxy), vous pouvez obtenir des boucles 301/302 et des liens générés en HTTP.

En pratique, la séquence la moins risquée est :

1) DNS OK (le domaine pointe vers l’IP) 2) vhost HTTP OK (le site répond en HTTP sur le domaine) 3) certificat OK (Let’s Encrypt) 4) activation SSL PrestaShop (BO) 5) redirection 301 HTTP→HTTPS au niveau serveur

Avant même de toucher PrestaShop, validez que votre serveur web route bien par nom d’hôte (et pas “au hasard” sur l’IP). C’est une source fréquente de confusion quand vous avez plusieurs vhosts :

# Bypass DNS pour tester le vhost sur l'IP (utile en pré-prod / migration)
curl -I --resolve example.com:80:IP_PUBLIQUE http://example.com/

Côté back-office, l’emplacement exact varie selon la version (8.x vs 9.x), mais l’idée est identique : définir le domaine principal et activer SSL.

Cas multiboutique : cohérence par boutique

En multiboutique, chaque shop peut avoir ses propres valeurs dans ps_shop_url. Le piège : corriger uniquement id_shop=1 alors que le trafic (ou un sous-domaine) arrive sur un autre id_shop. Avant de modifier, listez toutes les lignes :

SELECT id_shop, domain, domain_ssl, physical_uri, virtual_uri
FROM ps_shop_url
ORDER BY id_shop;

Si vous êtes bloqué (BO inaccessible), vous pouvez corriger à la main en SQL, par exemple :

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

Et en “plan B” (quand vous êtes enfermé par un force-SSL mal enchaîné), vous pouvez aussi désactiver temporairement le SSL côté PrestaShop via la table de configuration (selon préfixe) :

UPDATE ps_configuration
SET value='0'
WHERE name IN ('PS_SSL_ENABLED','PS_SSL_ENABLED_EVERYWHERE');

Après modification, purge cache (var/cache/ ou Advanced Parameters → Performance selon version) et invalidez au besoin l’OPcache/PHP-FPM si vous avez des comportements “fantômes”. Sur les boutiques à trafic, gardez une approche méthodique : une variation d’URL peut provoquer une explosion de redirections, des réécritures inattendues, et côté SEO une instabilité des canonical/hreflang (voir : PrestaShop multiboutique : paramétrage SEO pour éviter le contenu dupliqué).

Un point SEO/produit à rappeler (même si c’est 2026 et que c’est devenu une baseline) : Google a officialisé depuis longtemps l’usage de HTTPS comme signal. Citation exacte : “we’re starting to use HTTPS as a ranking signal” (Google Search Central Blog, 2014) https://developers.google.com/search/blog/2014/08/https-as-ranking-signal. Aujourd’hui, ce n’est plus “un bonus”, c’est plutôt un prérequis pour éviter des frictions (navigateur, paiement, cookies SameSite=None; Secure, etc.).

HTTPS Let’s Encrypt sur Lightsail : ACME, HTTP-01 vs DNS-01, Certbot et Bitnami

Let’s Encrypt n’est pas “un module SSL”, c’est une AC (autorité de certification) et une implémentation du protocole ACME. Leur définition est sans ambiguïté : “Let’s Encrypt is a free, automated, and open Certificate Authority (CA).” (Let’s Encrypt, About) https://letsencrypt.org/about/. Le protocole derrière, ACME, est standardisé : “This document describes a protocol for automated certificate management.” (RFC 8555) https://www.rfc-editor.org/rfc/rfc8555.

Avant d’émettre, vérifiez que vous avez bien décidé votre canonique (avec ou sans www) : le certificat peut couvrir les deux (-d example.com -d www.example.com), mais les redirections et l’URL PrestaShop doivent être cohérentes. Une bonne règle : couvrir les deux dans le cert, mais n’en servir qu’un en canonique (l’autre redirige).

Méthode 1 — Certbot (Apache/Nginx “classique”)

Si vous avez une stack classique (Apache ou Nginx géré par vous, hors Bitnami), Certbot reste le choix le plus direct.

Sur Ubuntu/Debian :

sudo apt update
sudo apt install -y certbot
# Apache
sudo apt install -y python3-certbot-apache
# ou Nginx
sudo apt install -y python3-certbot-nginx

Émission + configuration automatique Apache :

sudo certbot --apache -d example.com -d www.example.com

Pour Nginx :

sudo certbot --nginx -d example.com -d www.example.com

Si votre vhost est non standard, passez en mode --webroot (plus prédictible) :

sudo certbot certonly --webroot -w /var/www/prestashop -d example.com -d www.example.com

Pré-requis : le domaine doit déjà répondre en HTTP sur /.well-known/acme-challenge/ (donc pas de redirection “casse” challenge sans exception, pas de WAF qui bloque).

Checklist pratique (souvent oubliée) avant certbot :

Le DocumentRoot utilisé pour example.com est bien celui de la boutique (ou, en mode --webroot, que -w pointe vers le bon répertoire).
Pas d’authentification (Basic Auth) globale sur /.well-known/.
Si vous avez un CDN/proxy en amont, testez aussi en contournant ce proxy quand c’est possible (sinon vous déboguez le mauvais composant).

Méthode 2 — Image Bitnami sur Lightsail (`bncert-tool`)

Sur Bitnami, ne réinventez pas la roue : Bitnami fournit bncert-tool, qui automatise la mise en place TLS et la configuration du vhost. Typiquement :

sudo /opt/bitnami/bncert-tool

Le script vous demande les domaines (racine + www), active les redirections, et installe le certificat Let’s Encrypt. Le piège : Bitnami a souvent ses propres chemins (/opt/bitnami/apache2/conf/…) et un service Apache intégré ; si vous installez Certbot “système” sans tenir compte de ces chemins, vous pouvez vous retrouver avec un certificat valide mais jamais servi par le bon vhost.

Si vous hésitez sur “qui sert quoi”, partez d’un test simple : quel serveur répond réellement sur 443 ?

sudo curl -vkI https://127.0.0.1 2>&1 | head -n 30

Cela vous donne des indices sur le serveur (Apache/NGINX) et parfois le certificat servi localement.

HTTP-01 vs DNS-01 (quand vous avez besoin d’un wildcard)

HTTP-01 : simple, mais nécessite port 80 accessible et un vhost qui sert correctement le challenge.
DNS-01 : permet *.example.com (wildcard) et évite l’ouverture HTTP si vous le souhaitez, mais demande une automatisation DNS (API). Si vous êtes sur Route 53 ou Cloudflare, vous pouvez automatiser proprement ; si votre DNS est “manuel” chez un registrar sans API, DNS-01 devient vite du bricolage.

En e-commerce, le wildcard est utile surtout dans ces cas :

environnements multiples (preprod.example.com, staging.example.com) que vous voulez sécuriser sans multiplier les certificats,
multiboutique par sous-domaines,
création dynamique de sous-domaines (plus rare sur PrestaShop, mais possible côté tracking/landing).

Durcissement TLS et hygiène applicative (redirects, headers, mixed content)

Une fois le certificat en place, le “minimum acceptable” est : redirection 301 HTTP→HTTPS, désactivation TLS obsolètes, et élimination du mixed content. Le mixed content sur PrestaShop est rarement “mystique” : c’est souvent une URL de média (logo, CSS, module) enregistrée en dur en HTTP, ou une config de module qui ignore Tools::getShopDomainSsl().

Au niveau serveur, appliquez un profil TLS moderne. Plutôt que d’inventer une liste de ciphers, générez une config à jour via Mozilla SSL Configuration Generator : https://ssl-config.mozilla.org/ (sélectionnez Apache/Nginx, “Intermediate” selon votre base clients). Validez ensuite avec :

openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null | head
curl -I https://example.com

Pour une validation “vue client” plus complète (chaîne, protocoles, configuration), vous pouvez aussi lancer un test externe via SSL Labs : https://www.ssllabs.com/ssltest/

Redirections : une seule source de vérité

Évitez le doublon “PrestaShop force SSL” et 15 règles de redirection différentes (Apache + Nginx + CDN). La stratégie la plus stable :

Redirection http:// → https:// au niveau serveur web (ou CDN si vous maîtrisez parfaitement),
Redirection www → non-www (ou l’inverse) au même endroit,
PrestaShop configuré sur le domaine canonique (valeurs domain/domain_ssl identiques si vous forcez partout).

Sur PrestaShop, activez SSL dans le bon ordre : d’abord certificat + vhost HTTPS, ensuite l’option “Forcer SSL sur toute la boutique”. Un changement trop tôt vous expose à une boucle si votre reverse proxy / load balancer ne transmet pas correctement X-Forwarded-Proto (ou si PrestaShop ne le considère pas car mal configuré). Si vous avez un proxy/CDN devant, vérifiez la gestion des en-têtes, sinon PrestaShop peut générer des URL HTTP derrière un front HTTPS.

Mixed content : où chercher vite

Sur une page qui déclenche un avertissement navigateur, ciblez :

Thème : liens absolus http://... dans templates / CSS.
Modules : configuration d’URL (CDN, endpoints, images) stockée en base.
Assets : logo, favicon, images de CMS parfois stockées avec un schéma en dur.

Une méthode rapide : ouvrir la console navigateur (onglet Security/Console) puis corriger à la source (idéalement pas via réécriture “magique” qui masque le problème).

Enfin, ne posez pas HSTS “en dur” sans phase de validation. HSTS est efficace, mais punitif : une mauvaise config (certificat expiré, domaine secondaire oublié, sous-domaine non couvert) se transforme en indisponibilité côté navigateur. Commencez avec un max-age faible, validez, puis montez progressivement.

Renouvellement automatique et monitoring (sinon vous finirez en incident)

Let’s Encrypt émet des certificats à durée courte, et c’est volontaire : le protocole est pensé pour être automatisé. Si vous utilisez Certbot sur une distro moderne, vous aurez souvent un timer systemd préconfiguré (certbot.timer). Validez explicitement :

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

Ajoutez aussi un contrôle “visible de l’extérieur” de la date d’expiration, car un renouvellement peut réussir localement mais le mauvais vhost peut servir un ancien certificat (mauvaise conf SNI, mauvais fichier chain, etc.) :

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates

Sur Bitnami, la stratégie de renouvellement dépend de l’outil et de la version d’image. Vérifiez la présence de cron/systemd et testez un renouvellement “à blanc”. Dans tous les cas, surveillez la date d’expiration depuis l’extérieur (pas uniquement “localement”), sinon un problème de vhost ou de SNI peut passer sous le radar.

Côté monitoring, le plus simple est un check HTTP/TLS externe (Blackbox exporter, Uptime Kuma, StatusCake, etc.) qui alerte à J-15. Si vous avez déjà industrialisé la supervision boutique (paiement, erreurs 503, disponibilité), rattachez ce check à vos KPI : Monitoring PrestaShop : KPI e-commerce, paiements et prévention des erreurs 503.

Enfin, logguez les renouvellements et gardez un œil sur les limites ACME (rate limits). Réémettre 20 fois le même certificat en phase de test parce que le DNS n’est pas stabilisé est un scénario réel ; l’automatisation n’excuse pas l’absence de garde-fous. Une bonne hygiène : faites vos tests avec un seul domaine, validez la chaîne complète, puis ajoutez www/alias/wildcard.

Dépannage reproductible : DNS, ACME, boucles 301, et erreurs “fantômes”

Quand ça casse, isolez chaque couche et refusez de “deviner”. D’abord DNS :

# Résolution depuis un resolver public
 dig @1.1.1.1 +short A example.com
 dig @8.8.8.8 +short A example.com

Si les resolvers ne renvoient pas la même IP, vous êtes en propagation (ou en split-horizon DNS). Sur Lightsail DNS, contrôlez aussi que vous avez bien délégué les NS au niveau registrar, sinon vous modifiez une zone qui n’est jamais interrogée.

Astuce utile pour éviter les caches locaux : comparez aussi la délégation et la résolution complète (pas seulement +short) quand vous suspectez un problème de zone ou de glue records.

Pour ACME/Let’s Encrypt via HTTP-01, la majorité des échecs se diagnostiquent avec un simple curl sur le challenge :

curl -I http://example.com/.well-known/acme-challenge/test

Si vous obtenez une 301 vers HTTPS, ce n’est pas forcément un problème, mais si derrière vous avez un vhost HTTPS invalide (ou un proxy), le validateur peut échouer. Si vous obtenez 404, votre rewrite ou votre root n’expose pas le bon répertoire. Si vous obtenez 403, un module de sécurité (ou une règle) bloque le chemin.

Pour reproduire “comme Let’s Encrypt”, testez aussi le chemin en forçant le Host sur l’IP, ce qui permet de distinguer un problème DNS d’un problème vhost :

curl -I --resolve example.com:80:IP_PUBLIQUE http://example.com/.well-known/acme-challenge/test

Pour les boucles HTTPS côté PrestaShop, la méthode rapide est de comparer les headers vus par PHP et ceux envoyés par le client. Si vous avez un proxy devant (Cloudflare, load balancer, reverse proxy), assurez-vous que :

le front envoie X-Forwarded-Proto: https
le serveur web le relaie à PHP-FPM (si séparation)
PrestaShop est configuré pour faire confiance au proxy (selon votre architecture)

Une boucle est souvent “juste” : PrestaShop croit être en HTTP et redirige vers HTTPS, mais le proxy réécrit, ou inversement. Dans ce cas, isolez :

test direct serveur (sans proxy si possible),
test via le domaine public,
comparaison des en-têtes Location et des cookies.

Et si derrière vous observez des erreurs 503 après bascule (timeouts, saturation PHP-FPM), traitez-les comme un incident perf classique : logs Apache/Nginx, logs PHP-FPM, saturation CPU/RAM. Référence utile : Erreur HTTP 503 : diagnostiquer PHP et logs Apache/LiteSpeed.

Un dernier point “erreurs fantômes” très courant après migration : vous corrigez DNS et vhost, mais votre navigateur vous renvoie toujours l’ancien comportement. Avant d’incriminer PrestaShop :

testez en navigation privée,
videz cache DNS local (OS),
testez avec curl (qui contourne beaucoup de caches applicatifs),
et si vous avez un CDN/proxy, purgez-le explicitement.