HTTPS en local avec WSL2 et Apache.

Développer en local, c’est bien. Développer en local dans des conditions proches de la production, avec HTTPS, c’est mieux. Mais c’est souvent une source de frustration : navigateurs qui hurlent, certificats auto-signés refusés, configurations complexes… Après avoir exploré de nombreuses pistes, je te présente ma méthode pour mettre en place des certificats SSL locaux parfaitement valides sur un environnement Windows 11, WSL2 et Apache.

Fini les avertissements de sécurité, place au cadenas vert !

Image par skylarvision de Pixabay

Notre objectif est de faire en sorte que les navigateurs sur Windows fassent entièrement confiance aux certificats utilisés par notre serveur Apache qui tourne, lui, dans WSL2. Pour cela, nous allons utiliser l’excellent outil mkcert.

La clé du succès réside dans 3 étapes cruciales :

Installer mkcert à la fois sur Windows et sur WSL2.
Synchroniser l’autorité de certification (CA) pour que WSL2 utilise celle de Windows.
Générer les certificats de la bonne manière, avec le bon utilisateur et pour les bons domaines.

Étape 1 : installation de mkcert

Sur Windows

Le plus simple est d’utiliser le gestionnaire de paquets Chocolatey. Ouvre un terminal PowerShell en tant qu’administrateur :

# Installe mkcert
choco install mkcert

# Crée une autorité de certification (CA) locale et l'installe dans Windows
mkcert -install

Sur WSL2

Ouvre un terminal WSL2 (Ubuntu, par exemple) :

# Met à jour les paquets et installe les dépendances
sudo apt update && sudo apt install -y libnss3-tools

# Télécharge et installe la dernière version de mkcert
curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
chmod +x mkcert-v*-linux-amd64
sudo mv mkcert-v*-linux-amd64 /usr/local/bin/mkcert

Étape 2 : La synchronisation

C’est l’étape la plus importante. Nous allons dire à WSL2 de ne pas utiliser sa propre autorité de certification, mais celle que nous venons de créer sur Windows.

Partager la CA avec WSL2

Dans un terminal PowerShell (sur Windows) :

setx WSLENV "CAROOT/up:$Env:WSLENV"

Cette commande partage le chemin de la CA de Windows avec WSL2. Ferme et rouvre ton terminal WSL2 pour que le changement soit pris en compte.

Rendre la CA de confiance dans WSL2

Pour que les outils en ligne de commande comme curl ou git dans WSL2 fassent aussi confiance à notre CA, il faut l’enregistrer manuellement. Dans votre terminal WSL2 :

# 1. Obtient le chemin de la CA partagée
CAROOT=$(mkcert -CAROOT)

# 2. Copie le certificat racine au bon endroit
sudo cp "$CAROOT/rootCA.pem" /usr/local/share/ca-certificates/mkcert_rootCA.crt

# 3. Mets à jour le magasin de confiance de WSL2
sudo update-ca-certificates

La sortie doit vous indiquer « 1 added ». À partir de maintenant, Windows et WSL2 partagent et font confiance à la même autorité de certification.

Étape 3 : Générer les cerificats

C’est ici que se cachent deux pièges courants : utiliser *.localhost et générer les certificats avec sudo. Voici comment les éviter.

Le bon domaine : `.test`

Les navigateurs modernes ont des règles de sécurité très strictes pour le domaine .localhost, et n’aiment pas les certificats wildcard (*) pour ce dernier. La solution la plus propre est d’utiliser le domaine de premier niveau .test, réservé pour le développement. Bon moi j’aime bien garder monsite.localhost, c’est possible, mais il faudra générer un certificat pour chacun des sous-domaines.

Le bon utilisateur : `toi` (pas `root`)

Les certificats ne doivent pas être créés par root. Nous utiliserons sudo uniquement pour déplacer les fichiers à la fin.

La commande parfaite

Dans votre terminal WSL2 :

# 1. Place-toi dans ton dossier personnel
cd ~

# 2. Génére le certificat SANS sudo.
#    Nous créons un certificat valide pour "monsite.test" et tous ses sous-domaines.
mkcert "monsite.test" "*.test"

# 3. Crée un dossier pour les certificats et déplacez-les avec sudo
sudo mkdir -p /etc/ssl/local_certs/
sudo mv monsite.test+1.pem monsite.test+1-key.pem /etc/ssl/local_certs/

# 4. Assure-toi qu'Apache puisse les lire
sudo chmod 644 /etc/ssl/local_certs/*

Étape 4 : Configuration d’Apache et Windows

Il ne reste plus qu’à dire à Apache d’utiliser ces certificats et à Windows de savoir où trouver notre site.

Virtual Host Apache

Voici un modèle pour ton fichier de configuration (/etc/apache2/sites-enabled/monsite.test.conf) :

<VirtualHost *:443>
    ServerName monsite.test
    ServerAlias *.monsite.test
    DocumentRoot /var/www/monsite

    SSLEngine on
    SSLCertificateFile      /etc/ssl/local_certs/monsite.test+1.pem
    SSLCertificateKeyFile   /etc/ssl/local_certs/monsite.test+1-key.pem

    # ... reste de votre configuration (logs, directory, etc.)
</VirtualHost>

# N'oubliez pas une redirection de HTTP vers HTTPS
<VirtualHost *:80>
    ServerName monsite.test
    ServerAlias *.monsite.test
    Redirect permanent / https://monsite.test/
</VirtualHost>

Active le site (sudo a2ensite monsite.test.conf) et le module SSL (sudo a2enmod ssl), puis redémarre Apache (sudo systemctl restart apache2).

Fichier hosts de Windows

Enfin, modifie le fichier C:\Windows\System32\drivers\etc\hosts (en tant qu’administrateur) pour ajouter vos domaines locaux (moi j’aime bien utiliser les Power Toys pour cela, ça va plus vite) :

127.0.0.1  monsite.test
127.0.0.1  api.monsite.test

Conclusion

Et voilà ! En suivant ces étapes, tu dispose d’un environnement de développement local sous WSL2 avec des certificats HTTPS reconnus par tous vos navigateurs. Plus d’alertes, juste un flux de travail propre et sécurisé.

Les points clés à retenir :

Utilise .test, pas .localhost, pour une compatibilité maximale.
Synchronise la CA entre Windows et WSL2, y compris pour les outils en ligne de commande.
Génére les certificats en tant qu’utilisateur, puis déplace-les avec sudo.

J’espère que ce guide te fera gagner autant de temps qu’il m’en a fallu pour consolider cette méthode. Bon développement !