CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF /

HTTPS avec Let’s Encrypt sur XAMPP Windows

Boîtier en aluminium avec voyant ambre et câble noir sur une surface graphite

Verdict : pour publier un domaine avec Apache fourni par XAMPP, win-acme est la voie Windows la plus directe : il valide le domaine, écrit les fichiers PEM attendus par Apache et crée une tâche de renouvellement. Gardez le port 80 accessible pour HTTP-01 et la clé privée hors de htdocs.

Sommaire
  1. Réunir les prérequis utiles
  2. Choisir le bon challenge ACME
  3. Installer win-acme sans détour par Certbot
  4. Reconnaître les fichiers que win-acme écrit
  5. Déclarer le vhost HTTPS dans Apache
  6. Tester la configuration avant le redémarrage
  7. Ajouter la redirection HTTP au bon moment
  8. Contrôler le certificat réellement présenté
  9. Faire recharger Apache après un renouvellement
  10. Résoudre les erreurs qui reviennent souvent

Le montage XAMPP sous Windows n’a pas été exécuté sur cette machine Linux; les commandes Windows doivent donc être vérifiées sur votre installation.

Réunir les prérequis utiles

Let’s Encrypt délivre un certificat pour un nom de domaine public. Commencez par faire pointer le DNS de example.com vers l’adresse publique de votre connexion, puis vérifiez que le routeur transmet les ports TCP 80 et 443 vers le PC qui fait tourner Apache. Une entrée AAAA mal orientée peut envoyer une partie des visiteurs vers une autre machine; contrôlez-la ou retirez-la pendant la mise en service.

Dans XAMPP, le répertoire Web par défaut est C:\xampp\htdocs. L’outil Apache Friends rappelle aussi que XAMPP est destiné au développement, pas à un serveur de production exposé tel quel. Pour un service public, limitez les composants accessibles, protégez l’administration et laissez le pare-feu actif.

Le FAQ Windows de XAMPP donne les chemins de configuration, le rôle de htdocs et les ports utilisés par Apache.

Choisir le bon challenge ACME

Pour un Apache XAMPP public, commencez par HTTP-01. win-acme dépose un fichier temporaire dans /.well-known/acme-challenge/; les serveurs Let’s Encrypt viennent le lire via HTTP. Le port imposé est 80, même si votre application utilise ensuite HTTPS sur 443.

HTTP-01 pour un domaine web classique

HTTP-01 est le choix simple quand le domaine arrive bien sur ce PC. Il ne convient pas à un serveur uniquement local, à une connexion dont le port 80 est filtré ou à un domaine dont plusieurs serveurs répondent avec des contenus différents. Le fonctionnement détaillé des challenges Let’s Encrypt décrit le fichier attendu, les redirections acceptées et la contrainte du port 80.

Ne bloquez pas le port 80 après l’émission. Let’s Encrypt recommande de le conserver pour servir la redirection vers HTTPS; le rappel officiel sur le port 80 explique aussi pourquoi fermer ce port ne protège pas une visite HTTP contre une interception active.

DNS-01 pour un wildcard ou un serveur non public

DNS-01 prouve la maîtrise du domaine avec un enregistrement TXT sous _acme-challenge.example.com. Il permet les certificats wildcard et fonctionne lorsque le serveur Web n’est pas exposé. Choisissez un plugin DNS win-acme seulement si votre fournisseur possède une API adaptée. Une clé DNS trop large sur le PC Web augmente fortement les conséquences d’une compromission; utilisez une autorisation limitée ou effectuez la validation depuis une machine séparée.

Installer win-acme sans détour par Certbot

Téléchargez win-acme depuis son site officiel et décompressez-le dans un dossier stable, par exemple C:\win-acme. Ne le placez ni dans htdocs ni dans un dossier temporaire : la tâche de renouvellement devra retrouver wacs.exe.

Certbot n’est pas le choix à installer sur Windows : ses instructions Apache indiquent que le support Windows a été abandonné en février 2024. Sous Windows, utilisez donc un client ACME maintenu pour cette plateforme, comme win-acme, puis raccordez explicitement ses fichiers au vhost Apache.

La méthode interactive est la plus sûre pour une première demande. Lancez wacs.exe, choisissez M pour la création avec toutes les options, indiquez les noms de domaine manuellement, sélectionnez la validation par système de fichiers, puis choisissez l’export Write .pem files to folder. Le guide Apache de win-acme donne les choix de menu et l’équivalent en ligne de commande.

Quand le domaine et le chemin sont déjà décidés, la commande non interactive devient reproductible :

wacs.exe --source manual --host example.com --validation filesystem --webroot "C:\xampp\htdocs" --store pemfiles --pemfilespath "C:\xampp\apache\conf\ssl.crt"

Remplacez example.com par le nom réellement servi et C:\xampp\htdocs par le DocumentRoot du vhost HTTP. Durant la validation, ouvrez ce fichier de contrôle depuis une autre connexion si win-acme le demande. Une réponse 404 indique généralement un mauvais webroot, une règle de réécriture trop large ou un vhost qui ne reçoit pas le domaine.

Reconnaître les fichiers que win-acme écrit

Avec le plugin pemfiles, win-acme exporte un certificat, une clé privée, un fichier avec certificat et chaîne, ainsi qu’un fichier de chaîne seule. Les noms par défaut suivent le nom commun du certificat :

example.com-crt.pem
example.com-key.pem
example.com-chain.pem
example.com-chain-only.pem

Dans Apache, utilisez le fichier -chain.pem pour présenter le certificat avec sa chaîne et le fichier -key.pem pour la clé privée. Le plugin PemFiles documenté par win-acme précise les noms, le dossier de sortie et l’option de protection de la clé.

Contrôlez les permissions du dossier : le compte qui lance Apache doit pouvoir lire la clé, tandis que le contenu Web ne doit pas pouvoir la servir. N’ajoutez jamais le dossier de certificats sous htdocs et ne placez jamais une clé privée dans un dépôt Git.

Déclarer le vhost HTTPS dans Apache

Dans C:\xampp\apache\conf\httpd.conf, vérifiez que le module SSL et le fichier de vhosts utilisés sont chargés. Selon la version de XAMPP, vous trouverez notamment :

LoadModule ssl_module modules/mod_ssl.so
Include conf/extra/httpd-vhosts.conf

Ajoutez aussi Listen 443 s’il n’existe pas déjà dans la configuration chargée. Ne dupliquez pas une directive Listen déjà fournie par httpd-ssl.conf. Dans httpd-vhosts.conf, adaptez ensuite ce vhost :

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot "C:/xampp/htdocs"

    SSLEngine on
    SSLCertificateFile "C:/xampp/apache/conf/ssl.crt/example.com-chain.pem"
    SSLCertificateKeyFile "C:/xampp/apache/conf/ssl.crt/example.com-key.pem"

    <Directory "C:/xampp/htdocs">
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Les chemins avec des barres obliques sont lisibles par Apache sous Windows et évitent les ambiguïtés d’échappement. ServerName et ServerAlias doivent correspondre aux noms inclus dans le certificat. Le SSL/TLS How-To d’Apache confirme les directives minimales SSLEngine, SSLCertificateFile et SSLCertificateKeyFile.

Tester la configuration avant le redémarrage

Depuis une invite de commandes ouverte dans l’installation XAMPP, demandez à Apache de vérifier sa configuration :

C:\xampp\apache\bin\httpd.exe -t -f "C:\xampp\apache\conf\httpd.conf"
C:\xampp\apache\bin\httpd.exe -S -f "C:\xampp\apache\conf\httpd.conf"

La première commande doit répondre Syntax OK. La seconde permet de voir quel vhost reçoit example.com:443. Corrigez le premier message d’erreur avant de relancer Apache; un chemin de certificat faux bloque le chargement du vhost entier.

Redémarrez ensuite Apache depuis le panneau de contrôle XAMPP. Si le vhost s’ouvre en HTTPS mais affiche le mauvais certificat, vérifiez le couple ServerName/ServerAlias, le port 443 et le chemin réellement sélectionné par la résolution SNI.

Ajouter la redirection HTTP au bon moment

Gardez le vhost HTTP fonctionnel pendant la première validation. Une fois le certificat servi correctement sur 443, faites répondre le port 80 par une redirection vers HTTPS :

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot "C:/xampp/htdocs"
    Redirect permanent / https://example.com/
</VirtualHost>

HTTP-01 suit les redirections HTTP vers HTTP ou HTTPS sur les ports 80 et 443. Si une règle locale, une authentification ou un proxy traite différemment /.well-known/acme-challenge/, laissez ce chemin atteindre le webroot sans protection supplémentaire. Testez le nom avec et sans www avant de conserver la redirection canonique.

Contrôler le certificat réellement présenté

Un fichier PEM présent sur le disque ne prouve pas qu’Apache le sert. Depuis un poste qui possède OpenSSL, envoyez le nom du domaine dans SNI et lisez le certificat retourné :

printf '\n' | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Dans l’invite de commandes Windows, la même lecture s’écrit ainsi :

(echo.| C:\xampp\apache\bin\openssl.exe s_client -connect example.com:443 -servername example.com 2>NUL) | C:\xampp\apache\bin\openssl.exe x509 -noout -subject -issuer -dates

Le 17 septembre 2026, la même vérification appliquée à letsencrypt.org a produit cette mesure indépendante :

subject=CN = letsencrypt.org
issuer=C = US, O = Let's Encrypt, CN = YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
status=200 redirects=0 time_total=0.103666

La commande a donc lu un certificat dont le sujet et l’autorité correspondent au domaine interrogé, puis curl a obtenu HTTP 200 sans redirection. Sur votre domaine, le sujet, les dates et le nom demandé doivent correspondre à votre certificat; une date dépassée ou un nom absent signale un renouvellement non chargé ou un mauvais vhost.

Vous pouvez compléter ce contrôle avec :

curl.exe -I https://example.com/
nslookup example.com
netstat -ano | findstr ":80"
netstat -ano | findstr ":443"

Les deux premières lignes vérifient l’accès public et la résolution DNS. Les deux dernières identifient un port déjà pris quand Apache refuse de démarrer; comparez ensuite le PID avec le Gestionnaire des tâches ou tasklist.

Faire recharger Apache après un renouvellement

Après la première émission, win-acme crée une tâche planifiée qui vérifie chaque jour les renouvellements de tous les certificats qu’il gère. Sa fenêtre de renouvellement par défaut est réglée à 55 jours; la tâche décide ensuite si un certificat doit être renouvelé selon son historique et les informations de l’autorité ACME. Le fonctionnement de la tâche automatique win-acme indique où consulter les journaux et comment lancer une vérification forcée.

Le fichier PEM peut être remplacé sans que le processus Apache déjà lancé relise immédiatement la clé. Ajoutez donc un script d’installation après renouvellement, puis testez-le manuellement :

@echo off
"C:\xampp\apache\bin\httpd.exe" -k restart -f "C:\xampp\apache\conf\httpd.conf"
exit /b %errorlevel%

Enregistrez-le sous C:\win-acme\restart-apache.cmd et associez-le à la demande win-acme :

wacs.exe --source manual --host example.com --validation filesystem --webroot "C:\xampp\htdocs" --store pemfiles --pemfilespath "C:\xampp\apache\conf\ssl.crt" --installation script --script "C:\win-acme\restart-apache.cmd"

Le plugin script exécute un fichier .bat, .ps1 ou .exe après un renouvellement réussi. Sa documentation de paramètres et d’exécution permet d’ajouter les variables utiles si votre script doit copier les PEM vers un autre dossier.

Pour une vérification ponctuelle de la chaîne de renouvellement, utilisez wacs.exe --renew --force --verbose depuis le dossier win-acme, puis relisez les dates avec OpenSSL depuis une machine extérieure. L’option --force sert au diagnostic, pas à une tâche quotidienne : une demande forcée inutile peut rencontrer les limites de l’autorité ACME.

Résoudre les erreurs qui reviennent souvent

Pour vérifier les notions de requête et de réponse utilisées par le diagnostic, l’explication comprendre HTTP aide à lire les codes sans confondre une redirection et un certificat. Pour isoler un problème de route, utilisez aussi diagnostiquer une connexion. Les règles minimales de protection d’une machine exposée sont détaillées dans durcir une installation Linux, utiles pour comparer les principes même si XAMPP tourne sous Windows.

Un certificat valide chiffre la liaison et authentifie le nom demandé; il ne corrige ni un mot de passe faible, ni une application vulnérable, ni un panneau d’administration exposé. Après le premier HTTPS, réduisez donc les services XAMPP accessibles avant d’annoncer l’adresse publiquement.