Certaines fonctionnalités WordPress se comportent différemment selon que le site est servi en HTTP ou en HTTPS, et ce n’est pas qu’une question d’apparence de cadenas dans le navigateur. Un cookie marqué avec l’attribut Secure — de plus en plus fréquent avec les extensions de paiement, d’authentification à deux facteurs ou certains blocs qui utilisent l’Interactivity API — n’est tout simplement jamais envoyé par le navigateur sur une connexion non chiffrée. Tester ce genre de fonctionnalité en local, sur un simple http://mon-site.test, peut donner l’impression d’un bug alors que le code fonctionne très bien : c’est l’absence de HTTPS qui bloque le cookie.
mkcert résout ce problème sans la lourdeur habituelle des certificats auto-signés, qui déclenchent des avertissements de sécurité que le navigateur refuse d’ignorer discrètement. Son principe : créer une autorité de certification locale, l’installer dans le magasin de confiance du système d’exploitation, puis émettre des certificats signés par cette autorité pour n’importe quel domaine local.
Installation et autorité locale
# macOS avec Homebrew
brew install mkcert
mkcert -install
# Linux avec certutil pour Firefox et NSS
sudo apt install libnss3-tools
mkcert -install
La commande mkcert -install génère une autorité de certification racine propre à la machine et l’ajoute au magasin de confiance système (et à celui de Firefox, qui gère le sien séparément via NSS). C’est cette étape, réalisée une seule fois par machine de développement, qui permet ensuite à n’importe quel certificat émis par mkcert d’être accepté sans avertissement par le navigateur.
Émettre un certificat par projet
mkcert site-client-atelier.test "*.site-client-atelier.test" localhost 127.0.0.1
# génère deux fichiers dans le dossier courant :
# site-client-atelier.test+3.pem (certificat)
# site-client-atelier.test+3-key.pem (clé privée)
Le caractère générique (*.site-client-atelier.test) permet de couvrir aussi les sous-domaines, utile pour un réseau multisite ou pour un sous-domaine d’API séparé du site principal.
Brancher le certificat sur nginx
server {
listen 443 ssl;
server_name site-client-atelier.test;
ssl_certificate /chemin/vers/site-client-atelier.test+3.pem;
ssl_certificate_key /chemin/vers/site-client-atelier.test+3-key.pem;
root /var/www/site-client-atelier/public;
index index.php;
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Brancher mkcert sur DDEV
DDEV intègre nativement mkcert : dès que mkcert est installé et son autorité enregistrée sur la machine, DDEV génère et applique automatiquement un certificat de confiance pour chaque projet, sans configuration supplémentaire à écrire. Un simple ddev start suffit à obtenir un site accessible en HTTPS avec un certificat déjà reconnu.
Brancher mkcert sur un environnement Docker Compose maison
Pour un environnement Docker Compose personnalisé, il suffit de monter les fichiers générés par mkcert dans le conteneur qui exécute le serveur web, en les référençant depuis la configuration :
# docker-compose.yml (extrait)
services:
nginx:
image: nginx:alpine
volumes:
- ./certificats/site-client-atelier.test+3.pem:/etc/nginx/certs/cert.pem:ro
- ./certificats/site-client-atelier.test+3-key.pem:/etc/nginx/certs/key.pem:ro
- ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
ports:
- "443:443"
Le cas des cookies sécurisés dans wp-config.php
Une fois le site accessible en HTTPS localement, il reste à s’assurer que WordPress lui-même sait qu’il tourne en HTTPS, faute de quoi certains cookies restent tout de même émis sans l’attribut Secure. Deux constantes à vérifier dans wp-config.php, ou plus simplement le réglage de siteurl et home en https:// :
wp option get siteurl
wp option get home
# doivent tous deux renvoyer une URL en https:// pour que WordPress
# considère la connexion comme sécurisée de bout en bout
Un site local qui tourne en HTTP alors que la production est en HTTPS n’est jamais un environnement de test complet. On l’a compris tardivement sur un projet de paiement, où un bug de cookie n’apparaissait qu’en production — impossible à reproduire localement tant que le certificat n’était pas en place.
Renouvellement et durée de vie
Les certificats émis par mkcert ont une durée de validité longue par défaut (plusieurs années), ce qui évite d’avoir à les régénérer régulièrement comme on le ferait avec Let’s Encrypt en production. Seule l’autorité racine elle-même doit être réinstallée si l’on change de machine de développement, via un nouveau mkcert -install.
En résumé
mkcert transforme la mise en place de HTTPS local d’une corvée pleine d’avertissements de sécurité ignorés en une paire de commandes exécutées une fois par machine puis une fois par projet. Pour tout projet qui manipule des cookies sécurisés, des API de paiement ou des fonctionnalités qui se comportent différemment selon le protocole, ce n’est plus une option de confort mais un prérequis pour un test local fiable.
