Installer Let's Encrypt sur IIS : HTTPS et renouvellement automatique

Ce guide explique comment installer un certificat TLS Let's Encrypt sur un site IIS hébergé sur un VPS Windows Server. La procédure principale utilise simple-acme. Elle couvre la validation HTTP-01, les certificats wildcard par DNS-01, les liaisons IIS avec SNI, le renouvellement planifié, HSTS, la supervision et les erreurs les plus fréquentes.

Le résultat attendu est le suivant :

http://example.com répond sur le port 80 et redirige vers HTTPS ;
https://example.com et https://www.example.com présentent un certificat valide ;
le certificat contient les bons noms DNS dans ses SAN ;
IIS utilise la bonne liaison sur le port 443 ;
une tâche planifiée vérifie chaque jour si un renouvellement est nécessaire ;
le prochain renouvellement peut réussir sans intervention humaine.

Méthode, périmètre et limites de ce guide

Les informations ont été recoupées le 29 août 2026 avec la documentation officielle de Let's Encrypt, de Microsoft IIS et de simple-acme. Les commandes ont été comparées aux références PowerShell et IIS publiées par Microsoft.

Les versions, les limites d'émission et les durées de validité évoluent régulièrement. Avant d'appliquer cette procédure en production, reproduisez-la sur un VPS de préproduction avec un vrai sous-domaine, et vérifiez les valeurs chiffrées de cet article sur les pages officielles liées au fil du texte.

Ce guide concerne un site IIS public associé à un nom DNS. Il ne traite pas des certificats de contrôleur de domaine, de LDAPS ou d'AD CS, ni d'Exchange, de RDS Gateway ou de SQL Server, ni d'une PKI interne, ni d'un cluster IIS sans déploiement centralisé des certificats, ni d'un proxy qui termine TLS sur une autre machine. Dans ces cas, le certificat peut toujours venir d'une autorité ACME, mais la méthode d'installation et de renouvellement doit être adaptée au service.

Let's Encrypt, ACME, IIS et simple-acme : qui fait quoi ?

Composant	Fonction
Let's Encrypt	autorité de certification publique qui valide le contrôle du nom et signe le certificat
ACME v2	protocole automatisant la validation, l'émission, le renouvellement et la révocation
simple-acme	client ACME tiers qui dialogue avec Let's Encrypt et pilote IIS
Magasin de certificats Windows	conserve le certificat et sa clé privée sur le serveur
IIS et HTTP.sys	associent le certificat à une adresse, un port et un nom d'hôte
Tâche planifiée Windows	lance régulièrement simple-acme pour vérifier les renouvellements

Let's Encrypt délivre des certificats Domain Validation. Ils prouvent le contrôle technique des noms demandés et chiffrent la connexion. Ils ne certifient pas l'identité juridique d'une entreprise et ne corrigent ni une application vulnérable, ni un serveur compromis. Let's Encrypt ne propose pas de certificats OV ou EV, comme l'indique sa FAQ officielle.

Les certificats publics sont également inscrits dans des journaux de Certificate Transparency. Les noms DNS présents dans le certificat ne doivent donc pas être considérés comme secrets. Let's Encrypt explique ce fonctionnement dans sa documentation sur les journaux CT.

simple-acme ou win-acme : lequel choisir ?

win-acme reste le client le plus connu de l'écosystème IIS. simple-acme se présente sur son propre site comme un remplaçant rétrocompatible, développé par la même personne. Au 29 août 2026, simple-acme publie la version 2.4.0 et win-acme distribue toujours sa version 2.2.9.1 de son côté : les deux projets sont accessibles, et passer de l'un à l'autre est un choix, pas une obligation.

Ce guide utilise simple-acme parce que c'est la branche la plus récemment mise à jour. Si vous exploitez déjà win-acme et qu'il renouvelle correctement vos certificats, rien ne vous oblige à migrer dans l'urgence.

La documentation de prise en main confirme que l'outil détecte les liaisons IIS, utilise Let's Encrypt par défaut, effectue une validation HTTP, installe le certificat dans le magasin Windows, crée ou met à jour les liaisons HTTPS et crée une tâche planifiée de renouvellement.

simple-acme n'est pas un produit Microsoft ni un « client officiel Let's Encrypt ». C'est un logiciel tiers open source. Téléchargez-le uniquement depuis le site simple-acme ou son dépôt GitHub lié, puis vérifiez l'intégrité du fichier.

Vous utilisez déjà win-acme

Ne supprimez pas aveuglément win-acme ni son dossier %ProgramData%. Commencez par un inventaire :

Get-ScheduledTask |
    Where-Object TaskName -Match "win-acme|simple-acme" |
    Select-Object TaskName, State, TaskPath

Inventoriez ensuite les renouvellements et l'emplacement de leur configuration. simple-acme est annoncé comme un remplacement compatible, mais une migration de serveur ou de contexte DPAPI exige une vérification des secrets, des chemins, des plugins et des certificats. Suivez la procédure de migration simple-acme et conservez une sauvegarde avant toute modification.

Comprendre HTTP-01, DNS-01 et TLS-ALPN-01

Let's Encrypt doit vérifier que vous contrôlez chaque nom demandé.

Méthode	Validation	Port ou service nécessaire	Wildcard	Usage conseillé
HTTP-01	ressource sous `/.well-known/acme-challenge/`	TCP 80 public	non	un site IIS public sur un seul serveur
DNS-01	enregistrement TXT sous `_acme-challenge`	API DNS publique	oui	wildcard, cluster, port 80 indisponible
TLS-ALPN-01	réponse TLS spéciale	TCP 443 public	non	infrastructures TLS avancées

Pour HTTP-01, Let's Encrypt demande une ressource de la forme :

http://example.com/.well-known/acme-challenge/<JETON>

La validation arrive obligatoirement sur le port 80. Let's Encrypt peut suivre jusqu'à dix redirections, mais seulement vers HTTP ou HTTPS et vers les ports 80 ou 443. HTTP-01 ne permet pas d'obtenir *.example.com. Ces règles sont décrites dans la page officielle Challenge Types.

Pour DNS-01, le client publie un TXT sous :

_acme-challenge.example.com

DNS-01 permet les wildcards et fonctionne sans serveur web public. Pour rester automatisable, il faut toutefois une API DNS ou déléguer _acme-challenge vers une zone qui peut être automatisée. Utilisez des identifiants API à privilèges réduits : donner au serveur web une clé capable de modifier toutes vos zones DNS augmente fortement l'impact d'une compromission.

Prérequis

Vous devez disposer d'un VPS Windows Server à jour, d'un accès administrateur par RDP ou console, d'IIS installé avec un site qui répond déjà en HTTP, d'un domaine ou sous-domaine public contrôlé, d'un enregistrement A et, s'il existe, d'un AAAA correct, des ports TCP 80 et 443 ouverts dans le pare-feu Windows et le pare-feu réseau, d'une connectivité sortante HTTPS vers l'API ACME, d'une adresse e-mail d'exploitation surveillée et d'une sauvegarde de la configuration IIS avant modification.

Nos VPS Windows fournissent un environnement Windows administrable avec un accès administrateur complet. Le détail des versions, ressources et options pouvant évoluer, vérifiez la page produit au moment du déploiement.

1. Auditer Windows Server et IIS

Ouvrez Windows PowerShell en tant qu'administrateur :

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Get-WindowsFeature Web-Server
Get-Service W3SVC

Get-NetFirewallProfile |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Le rôle Web-Server doit être installé et le service W3SVC doit être en cours d'exécution. Si IIS n'est pas encore installé :

Install-WindowsFeature Web-Server -IncludeManagementTools

Install-WindowsFeature exige une console élevée et -IncludeManagementTools installe les outils de gestion, conformément à la référence Windows Server 2025. Si vous partez d'un serveur neuf, notre guide premiers pas avec un VPS Windows couvre la connexion initiale et les mises à jour.

Inventoriez les sites et leurs liaisons :

Import-Module WebAdministration

Get-Website |
    Select-Object Name, Id, State, PhysicalPath

Get-WebBinding |
    Select-Object protocol, bindingInformation, sslFlags

Notez le nom et l'ID du site à sécuriser. Les exemples suivants utilisent :

Paramètre	Exemple
Site IIS	`MonSite`
ID IIS	`2`
Domaine principal	`example.com`
Alias	`www.example.com`
IPv4 publique	`203.0.113.10`, valeur documentaire à remplacer

Les adresses 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24 sont réservées à la documentation. Ne les copiez pas dans une configuration réelle.

Ajouter les liaisons HTTP manquantes

simple-acme peut dériver les noms depuis les liaisons IIS. Chaque nom demandé doit donc être explicite et réellement pointer vers ce serveur.

New-WebBinding `
    -Name "MonSite" `
    -Protocol "http" `
    -IPAddress "*" `
    -Port 80 `
    -HostHeader "example.com"

New-WebBinding `
    -Name "MonSite" `
    -Protocol "http" `
    -IPAddress "*" `
    -Port 80 `
    -HostHeader "www.example.com"

N'exécutez ces commandes que si les liaisons n'existent pas déjà. Microsoft documente New-WebBinding et ses paramètres dans la référence WebAdministration.

Contrôlez le résultat :

Get-WebBinding -Name "MonSite" -Protocol http |
    Select-Object bindingInformation

Une liaison vide du type *:80: accepte tous les noms non capturés par un autre site. Elle peut masquer une erreur de configuration et faire valider le mauvais contenu. Sur un serveur multi-sites, utilisez des noms d'hôte précis.

2. Vérifier le DNS public, y compris IPv6

Depuis le VPS :

Resolve-DnsName example.com -Type A
Resolve-DnsName www.example.com -Type A

Resolve-DnsName example.com -Type AAAA -ErrorAction SilentlyContinue
Resolve-DnsName www.example.com -Type AAAA -ErrorAction SilentlyContinue

Les réponses A doivent correspondre à l'IPv4 publique qui dessert IIS. Si un AAAA existe, le site doit aussi fonctionner sur cette IPv6.

Let's Encrypt préfère IPv6 lors de la première tentative si un enregistrement AAAA est publié. Un serveur IPv6 qui répond avec le mauvais contenu peut faire échouer la validation sans repli vers IPv4. La correction consiste à faire pointer AAAA vers le bon serveur et à servir le même site, ou à supprimer AAAA si l'IPv6 n'est pas utilisée. Il n'existe pas d'option demandant à Let's Encrypt de préférer IPv4. Voir la documentation IPv6 Support.

Vérifiez aussi les éventuelles règles CAA :

Resolve-DnsName example.com -Type CAA -ErrorAction SilentlyContinue

L'absence de CAA n'empêche pas l'émission. Si une politique CAA est présente, elle doit autoriser Let's Encrypt, par exemple :

example.com.  CAA 0 issue "letsencrypt.org"

Pour un contrôle distinct des wildcards, le tag issuewild peut être utilisé. Le nom d'autorité CAA de Let's Encrypt est letsencrypt.org, comme l'indique sa documentation CAA. Une erreur SERVFAIL peut signaler une chaîne DNSSEC incorrecte ou un serveur DNS défaillant.

3. Ouvrir uniquement les ports nécessaires

Créez des règles entrantes pour HTTP et HTTPS :

New-NetFirewallRule `
    -DisplayName "IIS HTTP - TCP 80" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 80 `
    -Action Allow `
    -Profile Any

New-NetFirewallRule `
    -DisplayName "IIS HTTPS - TCP 443" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow `
    -Profile Any

Si ces règles existent déjà, auditez-les au lieu de créer des doublons :

Get-NetFirewallRule -DisplayName "IIS HTTP - TCP 80","IIS HTTPS - TCP 443" |
    Get-NetFirewallPortFilter

Le pare-feu Windows et le pare-feu réseau de l'hébergeur sont deux couches distinctes. Une règle locale correcte ne suffit pas si le filtrage amont refuse le port. Notre guide configurer le pare-feu Windows Server sur un VPS détaille cette séparation.

Pour HTTP-01, le port 80 doit être joignable depuis Internet. Let's Encrypt ne publie pas une plage stable d'adresses de validation à autoriser : une restriction à quelques IP arbitraires provoquera tôt ou tard un échec.

Contrôlez l'écoute locale :

Get-NetTCPConnection -State Listen |
    Where-Object LocalPort -In 80,443 |
    Select-Object LocalAddress, LocalPort, OwningProcess

Puis testez depuis une connexion extérieure au VPS :

Test-NetConnection example.com -Port 80
Test-NetConnection example.com -Port 443

Un test effectué depuis le serveur lui-même ne prouve pas toujours l'accessibilité publique, notamment en présence de NAT, de proxy ou de filtrage géographique.

4. Sauvegarder la configuration IIS

Avant de modifier les liaisons :

$appcmd = "$env:windir\System32\inetsrv\appcmd.exe"
& $appcmd add backup "Avant-LetsEncrypt"
& $appcmd list backup

Cette sauvegarde protège la configuration IIS, pas les contenus du site, la base de données ni les secrets de l'application. Conservez aussi une sauvegarde système selon votre politique. Notre guide sauvegarder son VPS Windows présente plusieurs approches.

5. Télécharger et vérifier simple-acme

Méthode recommandée sur Windows Server 2019 et 2022 : archive officielle

Téléchargez la version Windows x64 depuis la page officielle simple-acme. Choisissez :

la version trimmed pour HTTP-01 et un IIS simple : elle est plus légère mais ne prend pas en charge les plugins ;
la version full si vous avez besoin de plugins externes, notamment pour un fournisseur DNS.

Décompressez l'archive dans un emplacement permanent :

C:\Program Files\simple-acme

Ne laissez pas wacs.exe dans Téléchargements ou dans un dossier temporaire. La tâche planifiée dépend du chemin de l'exécutable.

Calculez le SHA-256 de l'archive avant extraction :

Get-FileHash `
    -Path "C:\Users\Administrator\Downloads\simple-acme.zip" `
    -Algorithm SHA256

Comparez la valeur, caractère par caractère, au hash publié sur la page de téléchargement. Au 29 août 2026, la page officielle indique la version 2.4.0, build 2.4.0.2350. Ne figez pas son hash dans une procédure destinée à durer : il change à chaque version.

Méthode Windows Server 2025 : WinGet

La documentation simple-acme indique que WinGet est disponible sur Windows Server 2025 :

winget install simple-acme

Vérifiez ensuite le chemin réellement installé :

Get-Command wacs.exe -ErrorAction SilentlyContinue

Sur Server 2019 ou 2022, préférez l'archive officielle, sauf si WinGet a été installé et géré explicitement dans votre image.

Vérifier l'exécutable

Set-Location "C:\Program Files\simple-acme"
.\wacs.exe --version

Lancez toujours la première configuration depuis une console administrateur. La documentation d'installation simple-acme précise que les privilèges élevés sont nécessaires pour gérer IIS, créer la tâche planifiée et écouter les requêtes de validation.

6. Tester en staging avant la production

Let's Encrypt recommande son environnement de staging pour les essais. Ses certificats ne sont pas approuvés par les navigateurs, mais les limites sont beaucoup plus adaptées au dépannage. L'URL ACME v2 de test est publiée dans la documentation staging.

Depuis le dossier de simple-acme :

.\wacs.exe --test --verbose

Choisissez le même site et les mêmes noms que pour la production. Un certificat de staging provoquera un avertissement de confiance dans le navigateur : c'est normal.

Après le test :

ouvrez Manage renewals dans simple-acme ;
identifiez le renouvellement lié au serveur de staging ;
annulez-le si vous n'en avez plus besoin ;
exécutez ensuite la procédure de production ;
vérifiez qu'une tâche de production et la bonne liaison IIS sont actives.

Évitez d'utiliser --nocache et --force à répétition. Au 29 août 2026, Let's Encrypt documente notamment 50 nouveaux certificats par domaine enregistré sur 7 jours, 5 certificats pour un ensemble exact d'identifiants sur 7 jours et 5 échecs d'autorisation par identifiant et par compte sur une heure. Les renouvellements coordonnés par ARI sont exemptés de ces limites. Consultez toujours la page Rate Limits au moment du diagnostic, car ces valeurs évoluent.

7. Émettre le certificat avec l'assistant interactif

Lancez :

Set-Location "C:\Program Files\simple-acme"
.\wacs.exe

Pour un site IIS classique :

choisissez N: Create certificate (default settings) ;
sélectionnez le site IIS MonSite ;
sélectionnez uniquement example.com et www.example.com ;
vérifiez qu'aucun nom interne, ancien alias ou environnement de test n'est inclus ;
acceptez les conditions du service ACME ;
fournissez une adresse e-mail d'exploitation ;
laissez HTTP-01 et le module self-hosting par défaut ;
laissez l'installation dans le magasin Windows et les liaisons IIS.

Les lettres et libellés peuvent légèrement changer entre versions. Fiez-vous au sens du choix et à la documentation de la version installée, pas à une capture ancienne.

Le plugin self-hosting de simple-acme lance temporairement un écouteur en mémoire. Il peut partager le port 80 avec IIS et HTTP.sys. Le port reste toutefois nécessaire depuis l'extérieur. Voir la documentation Self-hosting.

À la fin, simple-acme doit valider chaque nom, demander le certificat à Let's Encrypt, placer le certificat et sa clé dans le magasin Windows, créer ou mettre à jour les liaisons HTTPS correspondantes, enregistrer les paramètres du renouvellement et créer la tâche planifiée quotidienne.

8. Variante entièrement automatisée en ligne de commande

Commencez par confirmer l'ID IIS :

Get-Website -Name "MonSite" |
    Select-Object Name, Id

Puis adaptez cette commande :

.\wacs.exe `
    --source iis `
    --siteid 2 `
    --host example.com,www.example.com `
    --validation selfhosting `
    --installation iis `
    --emailaddress [email protected] `
    --accepttos

--source iis déclenche le mode non interactif. --siteid limite la source au bon site et --host filtre précisément les liaisons. Ces paramètres sont documentés dans la source IIS simple-acme et la référence CLI.

Avant d'intégrer cette commande à un outil de déploiement, remplacez chaque valeur d'exemple, exécutez-la d'abord avec --test --verbose, ne passez pas de secret DNS en clair dans l'historique PowerShell, conservez une sortie de journal et utilisez l'option L du gestionnaire de renouvellement pour obtenir la ligne équivalente à une configuration créée manuellement.

La ligne de commande crée un nouveau renouvellement. Pour modifier un renouvellement existant, utilisez le gestionnaire interactif ; ajouter de nouveaux paramètres à --renew ne reconfigure pas l'objet existant.

9. Vérifier le certificat et les liaisons IIS

Vérifier les liaisons

Get-WebBinding -Name "MonSite" |
    Select-Object protocol, bindingInformation, sslFlags,
                  certificateHash, certificateStoreName

Vous devez trouver une liaison HTTPS pour chaque nom :

*:443:example.com
*:443:www.example.com

Sur un VPS qui héberge plusieurs sites sur la même IPv4 et le même port 443, les liaisons doivent utiliser SNI. Dans New-WebBinding, la valeur SslFlags = 1 désigne une liaison SNI ; Microsoft documente les valeurs 0 à 3 dans la référence New-WebBinding.

Vérifier le certificat dans les magasins Windows

$domain = "example.com"
$stores = @(
    "Cert:\LocalMachine\WebHosting",
    "Cert:\LocalMachine\My"
)

Get-ChildItem $stores -ErrorAction SilentlyContinue |
    Where-Object {
        ($_.DnsNameList | ForEach-Object Unicode) -contains $domain
    } |
    Sort-Object NotAfter -Descending |
    Select-Object Subject, Issuer, Thumbprint,
                  NotBefore, NotAfter, HasPrivateKey

Vérifiez que Issuer correspond à la chaîne Let's Encrypt attendue, que HasPrivateKey vaut True, que NotAfter est dans le futur, que DnsNameList contient tous les noms utilisés et que l'empreinte correspond à la liaison HTTPS.

Certains profils modernes peuvent ne pas renseigner le Common Name. Le champ déterminant pour les noms est le Subject Alternative Name ; ne basez donc pas l'audit uniquement sur Subject.

Vérifier HTTP.sys

netsh http show sslcert

Microsoft recommande de comparer la liaison dans ApplicationHost.config avec le magasin SSL de HTTP.sys lors d'un incident. Voir How to Set Up SSL on IIS et la référence netsh http.

Vérifier depuis l'extérieur

Depuis un autre réseau :

curl.exe -I http://example.com/
curl.exe -I https://example.com/
curl.exe -I https://www.example.com/

Après configuration de la redirection, le premier appel doit recevoir un 301 ou 308 vers HTTPS. Les appels HTTPS doivent répondre sans erreur de nom ni de chaîne.

Testez aussi un navigateur sans session précédente, un téléphone en 4G ou 5G, IPv4 et IPv6 si AAAA existe, un analyseur TLS externe reconnu, et les pages comportant des images, scripts et feuilles CSS afin de repérer le contenu mixte HTTP.

10. Configurer la redirection HTTP vers HTTPS

N'activez la redirection qu'après avoir validé le certificat sur chaque nom.

IIS 10 version 1709 et versions ultérieures disposent d'un mécanisme HSTS natif au niveau du site, avec redirection HTTP vers HTTPS. Microsoft précise que la destination utilise le port standard 443. Exécutez :

$appcmd = "$env:windir\System32\inetsrv\appcmd.exe"

& $appcmd set config `
    -section:system.applicationHost/sites `
    "/[name='MonSite'].hsts.enabled:True" `
    /commit:apphost

& $appcmd set config `
    -section:system.applicationHost/sites `
    "/[name='MonSite'].hsts.max-age:300" `
    /commit:apphost

& $appcmd set config `
    -section:system.applicationHost/sites `
    "/[name='MonSite'].hsts.includeSubDomains:False" `
    /commit:apphost

& $appcmd set config `
    -section:system.applicationHost/sites `
    "/[name='MonSite'].hsts.redirectHttpToHttps:True" `
    /commit:apphost

Les attributs et cette syntaxe appcmd sont publiés dans la référence Microsoft HSTS settings for a Web Site.

Commencez avec max-age=300 pendant la validation fonctionnelle. Quand HTTPS et le renouvellement ont été observés, passez à 60 jours, soit 5184000 secondes, surveillez les erreurs de certificat et les sous-domaines, puis augmentez à un an, soit 31536000, si la politique de l'organisation le prévoit.

Pour modifier la durée :

& $appcmd set config `
    -section:system.applicationHost/sites `
    "/[name='MonSite'].hsts.max-age:5184000" `
    /commit:apphost

N'activez includeSubDomains que si tous les sous-domaines fonctionnent durablement en HTTPS. N'activez pas le préchargement HSTS simplement pour améliorer un score : l'inscription à la liste preload est un engagement distinct et difficile à annuler rapidement.

HSTS transforme les erreurs de certificat en échecs non contournables pour les navigateurs qui ont mémorisé la politique. Let's Encrypt recommande un déploiement prudent et avertit de ce risque dans son Integration Guide.

Le port 80 doit-il rester ouvert après la redirection ?

Oui si le renouvellement utilise HTTP-01. Le port 80 peut ne servir qu'à la redirection et à /.well-known/acme-challenge/, mais il doit rester publiquement accessible lors des futures validations. Let's Encrypt sait suivre une redirection valide vers 443, et l'écouteur self-hosting de simple-acme peut partager le port avec IIS.

Si votre politique exige la fermeture permanente de 80, reconfigurez d'abord le renouvellement en DNS-01 ou dans une méthode compatible. Ne fermez pas le port en attendant l'expiration pour découvrir que le renouvellement est cassé.

11. Vérifier et superviser le renouvellement automatique

simple-acme crée une tâche planifiée après le premier certificat réussi. Par défaut, elle s'exécute chaque jour sous le compte SYSTEM, à une heure tirée au hasard entre 9 h et 11 h afin de répartir la charge. Elle renouvelle seulement lorsqu'une condition le demande, notamment la durée restante du certificat, une modification des noms, une révocation, une installation incomplète ou une recommandation ARI. Voir Automatic renewal.

Listez la tâche :

Get-ScheduledTask |
    Where-Object TaskName -Match "simple-acme|win-acme" |
    Select-Object TaskName, State, TaskPath

Affichez son état :

$task = Get-ScheduledTask |
    Where-Object TaskName -Match "simple-acme" |
    Select-Object -First 1

if ($task) {
    Get-ScheduledTaskInfo `
        -TaskName $task.TaskName `
        -TaskPath $task.TaskPath
}

Contrôlez LastTaskResult, LastRunTime et NextRunTime. La tâche doit rester activée et pointer vers le dossier permanent de simple-acme.

Tester sans provoquer des émissions répétées

Un contrôle normal ne force pas un nouveau certificat :

.\wacs.exe --renew --verbose

Cette commande ne renouvelle que les objets arrivés dans leur fenêtre. Pour un test ponctuel de l'ensemble du processus, la documentation propose :

.\wacs.exe --renew --force --verbose

Ne lancez pas --force en boucle et n'ajoutez pas --nocache sans raison. Utilisez le staging pour le dépannage répétitif. Le cache protège partiellement contre les limites, mais ne remplace pas une méthode de diagnostic.

Consulter les journaux

Les journaux se trouvent normalement sous :

%ProgramData%\simple-acme\<serveur-acme>\Log

Pour trouver les fichiers récents :

Get-ChildItem "$env:ProgramData\simple-acme" -Recurse -File |
    Where-Object Extension -In ".log",".txt" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 20 FullName, LastWriteTime, Length

Consultez aussi l'Observateur d'événements Windows. simple-acme conserve ses journaux 120 jours par défaut et peut envoyer des notifications si un serveur SMTP est configuré.

Alerter sur une expiration proche

Ce contrôle local peut être intégré à votre supervision :

$warningDate = (Get-Date).AddDays(21)

$expiring = Get-ChildItem `
    "Cert:\LocalMachine\WebHosting",
    "Cert:\LocalMachine\My" `
    -ErrorAction SilentlyContinue |
    Where-Object {
        $_.HasPrivateKey -and
        $_.NotAfter -lt $warningDate -and
        $_.NotAfter -gt (Get-Date)
    } |
    Sort-Object NotAfter |
    Select-Object Subject, Thumbprint, NotAfter

$expiring

Surveillez la date présentée au client distant, pas seulement les certificats stockés localement. Un ancien certificat peut rester servi si la liaison IIS ou le proxy n'a pas été mis à jour.

Au 29 août 2026, les certificats Let's Encrypt sont valides 90 jours par défaut et la grande majorité de ceux qu'elle émet utilisent cette durée. Un profil court d'environ 6 jours est proposé en option à tous les abonnés. Let's Encrypt annonce par ailleurs vouloir ramener la durée maximale de ses certificats à 45 jours d'ici février 2028, les règles du secteur imposant un maximum de 47 jours à partir du 15 mars 2029. La page officielle sur la durée des certificats montre pourquoi une automatisation surveillée est indispensable.

12. Certificat wildcard avec DNS-01

Pour *.example.com, HTTP-01 ne fonctionne pas. Relancez simple-acme et choisissez M: full options :

source : liaisons IIS ou noms saisis manuellement ;
noms : example.com et *.example.com si les deux sont nécessaires ;
validation : DNS-01 ;
plugin : celui de votre fournisseur DNS ;
clé : RSA ou EC selon votre politique et vos clients ;
stockage : magasin de certificats Windows ;
installation : liaisons IIS.

Le wildcard *.example.com couvre www.example.com ou app.example.com, mais pas le domaine nu example.com et pas a.b.example.com. Demandez explicitement le domaine nu s'il doit être couvert.

La version full de simple-acme est nécessaire pour charger des plugins externes, la version trimmed ne les prenant pas en charge. Les plugins sont installés sous %ProgramData%\simple-acme\plugins. La liste actuelle figure dans la documentation DNS validation.

Sécurité des identifiants DNS

créez un jeton dédié à la validation ACME ;
limitez-le aux zones et actions strictement nécessaires ;
utilisez le coffre de secrets de simple-acme plutôt qu'un argument en clair ;
protégez le dossier %ProgramData%\simple-acme ;
prévoyez la rotation et la révocation du jeton ;
n'utilisez pas une clé globale de compte si un jeton limité existe.

Si votre fournisseur DNS ne propose pas d'API adaptée, déléguez _acme-challenge.example.com par CNAME ou NS vers une zone de validation automatisable. Cela évite parfois de donner au serveur web l'accès à toute la zone principale.

13. Durcir TLS sans casser Windows

Le certificat ne choisit pas seul les versions de TLS et les suites cryptographiques. IIS s'appuie sur Schannel, donc la configuration est largement définie au niveau du système.

Inventoriez les suites :

Get-TlsCipherSuite |
    Select-Object Name, Cipher, Hash, Exchange

Microsoft recommande aux applications d'utiliser les valeurs système par défaut plutôt que d'imposer arbitrairement leurs propres versions de protocole. La documentation TLS registry settings rappelle aussi qu'une modification Schannel affecte d'autres services que le site IIS.

Points de contrôle : installez les mises à jour Windows, conservez TLS 1.2 pour la compatibilité, sachez que TLS 1.3 est pris en charge à partir de Windows Server 2022, ne désactivez les protocoles hérités qu'après inventaire des clients, testez l'application, les API, les agents de supervision et les anciens clients, sauvegardez les paramètres avant toute modification et évitez de copier un script de registre non versionné trouvé sur un blog.

La matrice de support est publiée dans Protocols in TLS/SSL (Schannel SSP). Une politique trop stricte peut aussi empêcher le client ACME de joindre l'API.

14. Dépannage : symptômes, causes et actions

Symptôme	Cause probable	Vérification	Correction
`connection timed out` sur HTTP-01	port 80 filtré en amont	test externe TCP 80	ouvrir le pare-feu Windows et le pare-feu réseau
`unauthorized` avec 404	mauvais serveur ou mauvaise liaison	DNS, journaux IIS, liaisons	corriger `A`/`AAAA` et le host header
validation tente une mauvaise IPv6	`AAAA` ancien ou incohérent	`Resolve-DnsName -Type AAAA`	corriger ou retirer `AAAA`
`CAA forbids issuance`	CAA n'autorise pas Let's Encrypt	`Resolve-DnsName -Type CAA`	autoriser `letsencrypt.org` si conforme à la politique
`SERVFAIL` DNS	DNSSEC ou DNS autoritatif cassé	requêtes sur chaque NS	corriger DNSSEC ou le serveur DNS
écouteur self-hosting impossible	réservation URL ou logiciel non compatible	`netsh http show urlacl`	corriger la réservation ou utiliser filesystem/DNS-01
mauvais certificat servi	liaison SNI ou empreinte incorrecte	`Get-WebBinding`, `netsh http show sslcert`	corriger le host header, SNI et le certificat
le navigateur signale du contenu mixte	ressources encore chargées en HTTP	console développeur	convertir les URL des ressources en HTTPS
renouvellement absent	tâche supprimée ou chemin déplacé	Planificateur de tâches	recréer la tâche depuis simple-acme
renouvellement réussi mais ancien certificat servi	étape IIS non installée ou proxy intermédiaire	liaison IIS et test distant	reconfigurer l'installation, mettre à jour le terminateur TLS
trop de demandes	tests réalisés en production	journal ACME et en-tête `Retry-After`	attendre, respecter `Retry-After` et utiliser le staging

Tester le chemin HTTP-01

La validation par défaut est gérée en mémoire pendant l'exécution de simple-acme. Pour diagnostiquer une route ou un proxy, vous pouvez néanmoins vérifier qu'aucune règle ne bloque le préfixe :

curl.exe -I http://example.com/.well-known/acme-challenge/test

Un 404 hors validation est normal ; un refus réseau, une authentification obligatoire, un blocage WAF ou une redirection vers un port exotique ne l'est pas. Pendant une validation réelle avec --test --verbose, observez la réponse détaillée et les journaux.

Identifier le processus lié au port 80

$connection = Get-NetTCPConnection -LocalPort 80 -State Listen |
    Select-Object -First 1

if ($connection) {
    Get-Process -Id $connection.OwningProcess
}

netsh http show urlacl

Le processus System est courant avec HTTP.sys et IIS ; il ne signifie pas automatiquement qu'un logiciel malveillant occupe le port.

Diagnostiquer un mauvais certificat SNI

Affichez les liaisons HTTPS :

Get-WebBinding -Protocol https |
    Select-Object ItemXPath, bindingInformation, sslFlags,
                  certificateHash, certificateStoreName

Pour plusieurs sites partageant *:443, chaque nom doit avoir sa propre liaison et SNI doit être actif. La liaison vide *:443: peut devenir la liaison par défaut pour des clients sans SNI et servir un certificat inattendu.

15. Maintenance, mise à jour et réponse à incident

Mettre simple-acme à jour

Sur Windows Server 2025 avec WinGet :

winget upgrade simple-acme

Pour une installation manuelle, téléchargez la nouvelle archive officielle, vérifiez le hash, sauvegardez le dossier et remplacez les fichiers du programme. Les renouvellements sont stockés séparément sous %ProgramData% et doivent être conservés. Après mise à jour :

.\wacs.exe --version
.\wacs.exe --list
.\wacs.exe --renew --verbose

Lisez toujours les notes de version avant un changement de branche majeure.

En cas de fuite de clé privée

isolez et analysez le serveur compromis ;
révoquez le certificat ;
corrigez la cause de la fuite ;
générez une nouvelle clé et un nouveau certificat ;
remplacez toutes les liaisons concernées ;
recherchez d'autres certificats ou secrets exposés ;
documentez l'incident.

Dans simple-acme, la révocation est disponible dans Manage renewals > Revoke certificate ou par --revoke avec l'identifiant du renouvellement. Let's Encrypt indique que la révocation est requise lorsqu'une clé privée est compromise et décrit les motifs acceptés dans Revoking Certificates.

Annuler un renouvellement n'est pas la même chose que révoquer un certificat. L'annulation arrête la gestion future ; la révocation signale qu'un certificat déjà émis ne doit plus être approuvé.

Checklist de mise en production

Windows Server et IIS sont à jour.
Le site IIS possède des host headers explicites.
A pointe vers la bonne IPv4 publique.
Tout AAAA publié dessert correctement le même site.
Les ports 80 et 443 sont joignables depuis l'extérieur.
La configuration IIS a été sauvegardée.
simple-acme vient de la source officielle et son hash a été vérifié.
Le staging a été utilisé pour le dépannage initial.
Le certificat contient tous les SAN attendus.
Les liaisons HTTPS utilisent SNI si l'IP est partagée.
HTTP redirige vers HTTPS sans boucle.
HSTS a été déployé progressivement.
La tâche planifiée existe, est activée et a déjà réussi.
Les journaux et l'expiration sont supervisés.
La méthode de validation restera disponible au prochain renouvellement.
Une procédure de révocation et de reprise existe.

Questions fréquentes

Let's Encrypt est-il réellement gratuit sur IIS ?

Oui. Let's Encrypt ne facture pas l'émission de ses certificats DV. Le VPS Windows, le nom de domaine, l'administration et les éventuels services DNS restent payants selon leurs fournisseurs.

Le certificat est-il valable 90 jours ?

Au 29 août 2026, le profil classique reste valable 90 jours par défaut. Un profil court d'environ 6 jours est disponible en option, et Let's Encrypt prévoit de ramener sa durée maximale à 45 jours d'ici février 2028. Ne concevez jamais une exploitation autour d'un renouvellement manuel trimestriel.

Le port 80 est-il obligatoire ?

Il est obligatoire pour HTTP-01, même si l'écouteur interne utilise un autre port derrière une redirection ou un NAT. Il n'est pas nécessaire pour DNS-01. TLS-ALPN-01 utilise 443 mais convient surtout aux infrastructures avancées.

Peut-on fermer le port 80 après l'installation ?

Pas si le renouvellement reste en HTTP-01. Gardez-le accessible pour la redirection et les validations, ou migrez le renouvellement vers DNS-01 avant de le fermer.

Comment obtenir un wildcard `*.example.com` ?

Utilisez DNS-01 avec un plugin API automatisé, disponible dans la version full de simple-acme. Ajoutez aussi example.com au certificat si le domaine nu doit être couvert.

Un certificat wildcard couvre-t-il tous les niveaux ?

Non. *.example.com couvre un seul niveau comme www.example.com, mais pas example.com ni a.b.example.com.

Faut-il choisir RSA ou ECDSA ?

RSA offre une compatibilité très large. ECDSA fournit des clés et signatures plus compactes, mais doit être vérifié avec vos clients les plus anciens. Pour un premier déploiement IIS grand public, le choix par défaut de l'outil est généralement le plus prudent.

HTTPS suffit-il à sécuriser le site ?

Non. HTTPS chiffre le transport et authentifie le nom présenté. Il ne remplace pas les mises à jour, le contrôle d'accès, les sauvegardes, la sécurité applicative, la protection des secrets et la supervision.

Et sur un VPS Linux ?

La démarche est la même, mais l'outil change : sur Nginx ou Apache, on utilise généralement Certbot. Voir notre guide installer un SSL Let's Encrypt avec Certbot sur Nginx ou Apache.

Conclusion

Sur IIS, obtenir un certificat Let's Encrypt prend quelques minutes avec simple-acme. Ce qui demande de l'attention, c'est tout ce qui vient ensuite : la liaison HTTPS correcte sur chaque nom, la redirection sans boucle, HSTS déployé progressivement et surtout un renouvellement qui fonctionnera encore dans trois mois sans vous.

Retenez les trois pièges les plus courants : un enregistrement AAAA qui pointe ailleurs et fait échouer la validation, un port 80 fermé après la mise en HTTPS alors que le renouvellement en dépend, et une liaison IIS qui n'a pas été mise à jour et continue de servir l'ancien certificat. Vérifiez ces trois points et l'automatisation tiendra.