Objectif
Renouveler un certificat HTTPS sur IIS en conservant l’ancien certificat disponible jusqu’à validation, en contrôlant les bindings IIS et HTTP.sys, les noms SNI et la chaîne de confiance, puis en vérifiant depuis un client externe que chaque site présente la nouvelle empreinte.
Prérequis
- Nouveau certificat PFX/P12 ou certificat avec clé privée importable sur le serveur.
- Mot de passe du PFX conservé dans un coffre et non dans un script persistant.
- Liste des sites IIS, bindings HTTPS, host names et éventuels SNI.
- Ancien certificat encore valide et export/empreinte disponible pour rollback.
- Accès administrateur IIS/PowerShell et fenêtre de changement.
Procédure pas à pas
Inventorier les sites et bindings HTTPS
Listez les sites, leurs host headers et les bindings 443. Relevez les empreintes actuellement associées et identifiez les sites qui partagent le même certificat. Cette étape évite de remplacer une empreinte commune sans comprendre son périmètre.
Import-Module WebAdministrationGet-Website | Select Name,State,PhysicalPathGet-WebBinding -Protocol https | Select protocol,bindingInformation,sslFlags- Tous les bindings HTTPS et leurs noms sont connus.
Contrôler le certificat actuel dans le magasin
Relevez l’ancien certificat dans Cert:LocalMachineMy ou WebHosting selon votre architecture. Notez Subject, SAN
Get-ChildItem Cert:LocalMachineMy | Select Subject,Thumbprint,NotAfter,HasPrivateKey- L’empreinte de rollback est documentée.
Importer le nouveau certificat sans retirer l’ancien
Importez le PFX dans le magasin utilisé par IIS. Préférez une SecureString pour le mot de passe et évitez de l’inscrire dans l’historique. Vérifiez ensuite HasPrivateKey, dates et thumbprint. Si le certificat est fourni via une PKI interne, assurez-vous que la chaîne intermédiaire/racine est installée dans les magasins appropriés.
$pwd = Read-Host 'Mot de passe PFX' -AsSecureStringImport-PfxCertificate -FilePath 'C:Tempnewcert.pfx' -CertStoreLocation Cert:LocalMachineMy -Password $pwd- Le nouveau certificat est présent avec sa clé privée.
Vérifier les SAN et l’expiration
Contrôlez que tous les host names servis par le binding sont présents dans le certificat. Une migration réussie sur www.example.tld ne valide pas nécessairement api.example.tld. Comparez également NotBefore/NotAfter et l’autorité émettrice.
Get-ChildItem Cert:LocalMachineMy<THUMBPRINT> | Format-List Subject,DnsNameList,Issuer,NotBefore,NotAfter,Thumbprint,HasPrivateKey- Tous les FQDN attendus sont couverts.
Sauvegarder la configuration IIS
Avant de toucher aux bindings, créez une sauvegarde IIS ou exportez les informations nécessaires. Une sauvegarde appcmd permet de restaurer ApplicationHost.config si une erreur plus large est commise. Notez néanmoins qu’un rollback de certificat simple doit idéalement se limiter à réassocier l’ancienne empreinte.
%windir%system32inetsrvappcmd add backup BOAI-before-cert-renewal%windir%system32inetsrvappcmd list backup- La configuration IIS est récupérable en cas d’erreur de binding.
Basculer le binding vers le nouveau certificat
Utilisez IIS Manager ou PowerShell selon votre standard. Pour un binding SNI, conservez exactement host name, IP, port et sslFlags. Ne créez pas un second binding concurrent sur le même tuple. Si vous utilisez IISAdministration, New-IISSiteBinding permet d’associer explicitement une empreinte lors de la création d’un nouveau binding.
- Le binding cible référence le nouveau certificat sans modifier les autres sites.
Contrôler HTTP.sys et les bindings SSL
HTTP.sys gère la terminaison TLS sous IIS. En cas de doute, comparez les bindings avec netsh http show sslcert. Une incohérence entre IIS et HTTP.sys peut expliquer un site qui continue à présenter l’ancien certificat ou ne répond plus en HTTPS.
netsh http show sslcert- Le couple IP:port/hostname attendu pointe vers la nouvelle empreinte.
Tester localement puis depuis l’extérieur
Testez d’abord le site avec son host name depuis le serveur, puis depuis un poste externe passant par le chemin réel. Vérifiez l’empreinte, les dates, la chaîne et le contenu HTTP. Si un load balancer existe devant IIS, confirmez si le certificat est terminé sur le LB ou sur IIS avant de conclure.
curl.exe -Iv https://example.tld/openssl s_client -connect example.tld:443 -servername example.tld </dev/null 2>NUL | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256- Le site présente le nouveau certificat et l’application répond.
Retirer l’ancien certificat après observation
Conservez l’ancien certificat tant que tous les sites, nœuds et bindings n’ont pas été confirmés. Une fois la période de sécurité terminée, vérifiez qu’aucun binding ne référence son empreinte puis retirez-le du magasin selon votre politique. Ajoutez une supervision de la nouvelle date d’expiration.
- Aucun binding actif ne dépend de l’ancien certificat avant sa suppression.
Validation
La procédure est validée lorsque :
- Le nouveau certificat possède une clé privée et couvre tous les noms IIS concernés.
- Les bindings IIS/HTTP.sys présentent la nouvelle empreinte sans modifier les autres sites.
- Un test externe valide chaîne, expiration et réponse applicative.
- L’ancien certificat est conservé jusqu’à la fin de la période de rollback.
Retour arrière
- Réassocier l’ancienne empreinte au binding HTTPS concerné.
- Restaurer la sauvegarde appcmd si une modification plus large des bindings a été faite.
- Ne supprimer aucun certificat tant que le service n’est pas revenu.
- Si plusieurs nœuds sont concernés, revenir uniquement sur le nœud en échec et le retirer temporairement du load balancer.
Dépannage / erreurs fréquentes
- Certificat importé mais absent dans IIS : vérifier le magasin LocalMachine et HasPrivateKey.
- Wrong certificate servi : contrôler SNI, host name, sslFlags et netsh http show sslcert.
- Erreur chaîne : installer l’intermédiaire approprié et retester depuis un client externe.
- HTTPS tombe après changement : restaurer l’ancienne empreinte avant d’explorer d’autres modifications.
- Un seul site sur 443 échoue : comparer son binding SNI à ceux qui fonctionnent.