En 2016, obtenir un certificat TLS pour un site WordPress coûtait de l’argent et demandait de manipuler des fichiers CSR à la main. Aujourd’hui, Let’s Encrypt délivre des certificats gratuits, reconnus par tous les navigateurs, et l’outil Certbot automatise l’ensemble du processus. Il n’y a plus aucune raison technique ou budgétaire de livrer un site WordPress en HTTP simple en 2020.
Reste que l’automatisation cache un piège classique : un certificat Let’s Encrypt n’est valable que quatre-vingt-dix jours. Sans renouvellement automatique correctement configuré, le certificat expire silencieusement, et le site affiche un avertissement de sécurité à la première visite qui suit l’échéance. C’est l’une des causes les plus fréquentes de sites qui « tombent » sans qu’aucun code n’ait changé.
Installer Certbot sur un VPS nginx
Sur une distribution Debian ou Ubuntu, l’installation passe par les dépôts officiels du projet, ou par snap selon la distribution :
sudo apt update
sudo apt install certbot python3-certbot-nginx
Le greffon python3-certbot-nginx sait lire la configuration nginx existante et y insérer automatiquement les directives nécessaires. Il suffit ensuite de lancer la commande suivante, en remplaçant le nom de domaine par celui du site concerné :
sudo certbot --nginx -d exemple.fr -d www.exemple.fr
Certbot interroge alors l’API de Let’s Encrypt, prouve la possession du domaine par un défi HTTP-01 (un fichier temporaire servi depuis le dossier du site), obtient le certificat, puis modifie le bloc server nginx pour écouter sur le port 443 et rediriger le trafic HTTP vers HTTPS.
Vérifier et forcer le renouvellement automatique
Depuis quelques versions, Certbot installe lui-même une tâche systemd timer (ou un cron, selon l’installation) qui vérifie deux fois par jour si un certificat approche de son expiration. Le renouvellement effectif ne se déclenche que dans les trente derniers jours avant l’échéance, pour ne pas solliciter inutilement l’infrastructure de Let’s Encrypt.
Il est indispensable de vérifier que ce mécanisme fonctionne réellement, plutôt que de faire confiance à l’installation par défaut :
sudo certbot renew --dry-run
Cette commande simule un renouvellement sans réellement modifier le certificat en place. Si elle échoue, le vrai renouvellement échouera aussi trois mois plus tard, généralement un week-end, au pire moment.
Le piège de la redirection HTTPS mal faite
Certbot ajoute une redirection automatique de HTTP vers HTTPS, mais dans WordPress, l’URL du site (options siteurl et home) doit elle aussi pointer vers la version HTTPS. Sans cette cohérence, certaines ressources continuent d’être chargées en HTTP, ce qui déclenche des avertissements de « contenu mixte » dans la console du navigateur et peut casser des scripts bloqués par les politiques de sécurité modernes.
La correction se fait directement en base, ou via WP-CLI pour éviter toute erreur de syntaxe SQL :
wp option update siteurl 'https://exemple.fr'
wp option update home 'https://exemple.fr'
wp search-replace 'http://exemple.fr' 'https://exemple.fr'
Certificats wildcard et défi DNS-01
Pour un site qui utilise plusieurs sous-domaines — un espace membre, une API, un environnement de préproduction — un certificat wildcard couvrant *.exemple.fr évite de multiplier les certificats individuels. Il exige en revanche un défi DNS-01 : Certbot doit pouvoir créer un enregistrement TXT temporaire dans la zone DNS, ce qui nécessite un greffon spécifique à votre fournisseur DNS ou une API compatible.
- Le défi HTTP-01 suffit pour un domaine simple et ses sous-domaines listés un par un.
- Le défi DNS-01 est obligatoire pour un certificat wildcard.
- Certains hébergeurs mutualisés gèrent Let’s Encrypt automatiquement depuis leur panel, sans accès SSH nécessaire.
Un certificat TLS qui fonctionne aujourd’hui ne garantit rien pour dans trois mois. La seule preuve fiable, c’est un renouvellement testé, pas une case cochée à l’installation.
Notre check-list finale
Avant de livrer un site, trois vérifications s’imposent : la commande certbot renew --dry-run passe sans erreur, les options siteurl et home pointent bien vers la version HTTPS, et aucune ressource du site n’est chargée en HTTP pur — vérifiable en un coup d’œil dans les outils de développement du navigateur. Ces trois points évitent la quasi-totalité des incidents liés au TLS sur un site WordPress hébergé sur VPS.
