Comment configurer un HTTPS (SSL) de confiance sur WampServer pour Windows

Pourquoi exécuter le HTTPS sur localhost ?

Beaucoup de développeurs exécutent leurs sites locaux en simple http:// pendant des années. Alors pourquoi s’embêter avec le HTTPS sur localhost ?

Parce que les fonctionnalités modernes des navigateurs présupposent de plus en plus un contexte sécurisé. Celles-ci se comportent différemment — ou refusent simplement de fonctionner — en HTTP simple :

• Les service workers et l’API Cache
• Les cookies sécurisés et SameSite=None (nécessaires à de nombreux flux OAuth et SSO)
• Les URI de redirection OAuth/OpenID qui exigent https://
• L’API Payment Request, la géolocalisation, l’accès à la caméra et au microphone
• HTTP/2, que les navigateurs ne négocient que par TLS

Si votre application de production utilise l’une de ces fonctionnalités, tester en HTTP revient à tester un chemin de code différent de celui de vos utilisateurs. Exécuter un HTTPS de confiance en local supprime cet écart.

Pourquoi un certificat auto-signé affiche-t-il « Votre connexion n’est pas privée » ?

Réponse brève : la confiance est une chaîne, et un certificat auto-signé n’a aucune chaîne.

Votre navigateur fait confiance à un site lorsque son certificat est signé par une autorité de certification (AC) à laquelle votre système d’exploitation fait déjà confiance. Un certificat auto-signé se signe lui-même — aucune autorité fiable ne se porte garante — et le navigateur fait donc ce qu’il faut : il vous avertit. Cliquer sur « Continuer quand même (dangereux) » fonctionne, mais vous vous entraînez à ignorer l’avertissement même qui vous protège ailleurs.

La solution professionnelle n’est pas de fabriquer un « meilleur » certificat auto-signé. C’est de créer votre propre petite autorité de certification, de dire à votre ordinateur d’y faire confiance une fois, puis de signer le certificat de chaque site avec elle. C’est précisément ce que font les étapes manuelles ci-dessous — et ce que WAMP SSL Automator fait pour vous.

Ce qu’il vous faut

• WampServer installé et en cours d’exécution sur Windows 10 ou 11. Son Apache intégré fournit l’openssl.exe utilisé ci-dessous.
• Des droits d’administrateur, car vous allez écrire dans le magasin de certificats de Windows, le fichier hosts et la configuration d’Apache.
• Un projet servi par Apache, par exemple C:\wamp64\www\myapp\public.

Tout au long de ce guide, le domaine d’exemple est myapp.test. Le suffixe .test est réservé aux tests et ne se résoudra jamais sur l’internet public, ce qui en fait un choix idéal pour le développement local.

Option A — la méthode manuelle (et ses pièges)

Voici la version honnête du processus à la main, pour que vous voyiez chaque rouage.

1. Créer une AC racine locale

Ouvrez un terminal où OpenSSL est disponible (WampServer le fournit dans C:\wamp64\bin\apache\apache<version>\bin). Générez une clé d’AC et un certificat d’AC auto-signé :

openssl genrsa -out myCA.key 4096
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 3650 -out myCA.crt -subj "/CN=My Local Dev CA"

2. Approuver l’AC dans Windows

Importez myCA.crt dans le magasin racine de confiance de la machine. Dans une console PowerShell élevée :

Import-Certificate -FilePath myCA.crt -CertStoreLocation Cert:\LocalMachine\Root

Piège : importer dans le magasin de l’utilisateur courant au lieu de LocalMachine\Root, ou oublier de s’exécuter en mode élevé, laisse l’AC non approuvée et l’avertissement persiste.

3. Émettre un certificat pour votre domaine — avec un SAN

Les navigateurs modernes ignorent l’ancien champ Common Name et exigent un Subject Alternative Name ainsi qu’un Extended Key Usage serverAuth. Créez un fichier d’extensions myapp.ext :

subjectAltName = DNS:myapp.test
extendedKeyUsage = serverAuth

Générez ensuite une clé, une CSR, et signez-la avec votre AC pour 825 jours au maximum :

openssl genrsa -out myapp.key 2048
openssl req -new -key myapp.key -out myapp.csr -subj "/CN=myapp.test"
openssl x509 -req -in myapp.csr -CA myCA.crt -CAkey myCA.key -CAcreateserial -out myapp.crt -days 825 -sha256 -extfile myapp.ext

Piège : un SAN manquant, un EKU serverAuth manquant, ou une validité supérieure à 825 jours feront tous rejeter par Chrome et Edge un certificat qui « semble pourtant correct ».

4. Configurer un vhost SSL Apache

Assurez-vous que mod_ssl est activé, puis ajoutez un vhost :443 dans httpd-vhosts.conf et une redirection :80 :

<VirtualHost *:80>
  ServerName myapp.test
  Redirect permanent / https://myapp.test/
</VirtualHost>

<VirtualHost *:443>
  ServerName myapp.test
  DocumentRoot "C:/wamp64/www/myapp/public"
  SSLEngine on
  SSLCertificateFile "C:/wamp64/certs/myapp.crt"
  SSLCertificateKeyFile "C:/wamp64/certs/myapp.key"
  <Directory "C:/wamp64/www/myapp/public">
    Require local
  </Directory>
</VirtualHost>

Piège : une seule directive mal saisie et Apache ne démarrera pas — mettant tous les sites de votre pile hors ligne jusqu’à ce que vous la trouviez.

5. Mapper le domaine dans le fichier hosts

Modifiez C:\Windows\System32\drivers\etc\hosts (en tant qu’administrateur) et ajoutez :

127.0.0.1 myapp.test

6. Redémarrer Apache et croiser les doigts

Redémarrez le service wampapache. Si vous avez oublié quelque chose aux étapes 1 à 5, vous le découvrez maintenant — généralement avec une pile hors ligne plutôt qu’un message utile.

Ça fonctionne, mais cela fait beaucoup d’étapes précises et sensibles à l’ordre, à répéter pour chaque nouveau projet. C’est l’écart que l’outil comble.

Option B — la méthode en un clic

WAMP SSL Automator effectue pour vous chaque étape ci-dessus, dans le bon ordre, avec un filet de sécurité :

• Il génère et approuve l’AC racine locale une fois, puis la réutilise.
• Il émet chaque certificat de domaine avec le profil SAN + EKU + 825 jours exact qu’exigent les navigateurs.
• Il fusionne les blocs vhost dans votre configuration existante au lieu de l’écraser, et met à jour le fichier hosts dans des sections balisées.
• Il exécute httpd -t avant de redémarrer, et revient en arrière automatiquement en cas d’échec — en restaurant des sauvegardes horodatées des deux fichiers.
• Il récupère ensuite chaque domaine en HTTPS et indique N/N OK.

Vous ajoutez vos domaines, cliquez sur Générer la configuration SSL, et regardez le journal. Voyez le pipeline complet en neuf étapes pour savoir exactement ce qui s’exécute.

Comment vérifier que le HTTPS fonctionne ?

Ouvrez https://myapp.test dans Edge ou Chrome. Vous devriez voir un cadenas normal et aucun avertissement. Pour vérifier en ligne de commande :

curl -I https://myapp.test

Une réponse fiable sans erreur de certificat signifie que la chaîne est bonne. Si vous utilisez Firefox, activez security.enterprise_roots.enabled dans about:config une fois pour qu’il lise aussi le magasin de confiance de Windows.