Windows Server 2025 / Comment configurer HTTPS dans IIS et vérifier les certificats

Pour configurer HTTPS dans IIS, il faut un certificat correspondant au nom demandé, sa clé privée sur le serveur et une liaison HTTPS utilisant ce certificat. Vérifiez aussi la confiance du client, la période de validité, les conditions de révocation et le certificat réellement présenté après le renouvellement.

Vérifiez séparément le nom, la clé, la confiance et la liaison

HTTPS protège le trafic web avec le protocole Transport Layer Security (TLS). Le serveur présente un certificat liant une identité à une clé publique, tandis que les clients valident son nom, sa période de validité et la chaîne d'émission. La clé privée correspondante doit être disponible sur le serveur.

Élément Vérification en laboratoire
Nom web.lab.example.test dans le Nom alternatif du sujet (SAN)
Magasin WEB1 Ordinateur local → Personnel
Clé Clé privée correspondante disponible
Confiance CLIENT1 fait confiance à la chaîne émettrice
Liaison LabSite / HTTPS / 8443 / certificat prévu

Utiliser une adresse IP peut entraîner un échec de la correspondance de nom pour un certificat de nom DNS. Le nom privé .test est destiné au laboratoire ; les services réels nécessitent des noms contrôlés par l'organisation et une autorité de certification appropriée. Guide IIS HTTPS sépare la préparation du certificat de la configuration de liaison.

Créez un certificat de test isolé

Vérifiez d'abord LabSite et DNS web.lab.example.test → 172.24.50.30. Cet exemple utilise un certificat auto-signé pour un test isolé et non public. Les clients ne lui font pas automatiquement confiance, et cet exercice ne remplace pas l'émission et la validation en production.

Exécutez ces commandes dans une session PowerShell avec élévation de privilèges sur WEB1 et enregistrez l'empreinte. La durée de vie d'un mois est un choix de laboratoire ; voir New-SelfSignedCertificate pour les certificats de test et les options de stockage.

$labCertificate = New-SelfSignedCertificate -DnsName 'web.lab.example.test' -CertStoreLocation 'Cert:\LocalMachine\My' -FriendlyName 'LabSite HTTPS test' -NotAfter (Get-Date).AddMonths(1)
$labCertificate | Select-Object Subject,Thumbprint,NotAfter,HasPrivateKey

Dans certlm.msc → Personnel → Certificats, inspectez le SAN, l'expiration, l'empreinte et la clé privée associée. Distinguez les certificats portant le même nom convivial par leur empreinte. Enregistrez l'élément créé au lieu d'accumuler des copies indistinguables.

Ajoutez la liaison HTTPS sur le port 8443

  1. Dans le Gestionnaire IIS → WEB1 → Certificats de serveur, actualisez et localisez le nouveau certificat.
  2. Ouvrez LabSite → Liaisons → Ajouter et sélectionnez https, IP 172.24.50.30 et port 8443.
  3. Entrez web.lab.example.test et sélectionnez Exiger l'indication du nom du serveur.
  4. Sélectionnez LabSite HTTPS test, en confirmant qu'il correspond à l'empreinte enregistrée.
  5. Vérifiez qu'aucune liaison ne fait doublon et contrôlez l'état du site.
  6. Créez la règle de pare-feu Lab-IIS-HTTPS-8443 pour le profil Domaine, TCP entrant 8443, et sous-réseau distant 172.24.50.0/24 uniquement.

L'indication du nom du serveur (Server Name Indication, SNI) permet à un client de fournir le nom demandé lors de la négociation TLS. Elle aide à sélectionner le certificat lorsque plusieurs sites partagent une adresse IP et un port. Examinez les attributs de liaison et SNI. Le port 8443 sépare cet exercice du HTTP 8080 ; le port HTTPS par défaut est 443.

Vérifiez la confiance et le certificat réel sur CLIENT1

Accédez à https://web.lab.example.test:8443/. Un avertissement est attendu tant que CLIENT1 ne fait pas confiance à ce certificat auto-signé. Inspectez l'empreinte, le nom et la période de validité du certificat présenté plutôt que de considérer les avertissements contournés comme une validation réussie.

  1. Sur WEB1, exportez uniquement le certificat identifié en tant que .cer public sans sa clé privée.
  2. Transférez-le à CLIENT1 via un chemin de laboratoire de confiance ; ne distribuez pas de PFX contenant la clé privée.
  3. Comparez son empreinte digitale avec la valeur enregistrée sur WEB1.
  4. Importez uniquement ce certificat de test dans Utilisateur actuel → Autorités de certification racine de confiance sur CLIENT1 isolé. Ne le déployez pas sur les PC de production ni dans une stratégie de domaine.
  5. Rouvrez le navigateur et vérifiez que la même URL s'ouvre sans avertissement de certificat.

L'ajout d'un certificat au magasin de confiance lui accorde cette confiance. N’ajoutez jamais un certificat non vérifié simplement pour faire disparaître une erreur. Si la validation échoue toujours, vérifiez le SAN, l’heure, l’expiration, le certificat réellement présenté, ainsi que toute politique supplémentaire du navigateur ou organisationnelle.

Test-NetConnection -ComputerName web.lab.example.test -Port 8443

Une connexion TCP réussie ne valide pas TLS. Inspectez l'empreinte réelle du certificat et la chaîne dans le navigateur et confirmez le contenu attendu de la page.

Vérifiez la liaison lors du renouvellement et du nettoyage

Importer un certificat de remplacement dans le magasin ne garantit pas qu'IIS le présentera. Vérifiez la nouvelle clé, les noms, la chaîne et la date d’expiration, mettez à jour la liaison et vérifiez la nouvelle empreinte depuis un client séparé. Conservez l’ancien certificat jusqu’à ce que les dépendances et les besoins de restauration soient compris.

  • Désignez un responsable, une méthode de renouvellement et des alertes en cas d’échec.
  • Laissez du temps pour l’approbation, le déploiement et la validation avant l’expiration.
  • Assurez-vous que les clients peuvent accéder aux services de vérification de révocation nécessaires.
  • Surveillez les mises à jour des liaisons ainsi que la création de certificats lors de l'automatisation du renouvellement.

Pour le nettoyage, supprimez la liaison HTTPS de test et la règle 8443, puis ne retirez que le certificat de test identifié après vérification des dépendances. Supprimez de CLIENT1 l'entrée de confiance ajoutée, en vous fondant sur l'empreinte enregistrée. Ne supprimez pas d'autres racines ou certificats portant des noms similaires. Décidez séparément s’il faut conserver HTTP ou mettre en œuvre une redirection HTTPS vérifiée.