# HTTPS en local pour tous vos projets WordPress avec mkcert

> Générer une autorité de certification locale avec mkcert, émettre des certificats par projet et les brancher sur nginx, DDEV ou Docker, cookies sécurisés compris.

- Auteur : Clément Hadrot
- Publié le : 2026-08-13
- Mis à jour le : 2026-08-13
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/https-local-mkcert-wordpress/

## L’essentiel

- mkcert crée une autorité locale reconnue automatiquement par le système
- Un certificat par domaine local, généré en une commande
- Indispensable dès qu'un cookie porte l'attribut Secure

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.

> L'essentiel à retenir : mkcert crée une autorité locale reconnue automatiquement par le système ; Un certificat par domaine local, généré en une commande ; Indispensable dès qu'un cookie porte l'attribut Secure

## 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.