IIS 7 sert toujours l'ancien certificat SSL

J'ai installé un nouveau certificat SSL dans IIS7, supprimé l'ancien certificat et configuré les liaisons pour le nouveau certificat - donc https est désormais lié au nouveau certificat uniquement.

J'ai redémarré IIS7 (et le serveur Windows 2008 lui-même) et vérifié le certificat à l'aide des commandes:

netsh http show sslcert

Cela ne montrait que le nouveau certificat, comme je m'y attendais

certutil -store MY

Cela ne montrait également que le nouveau certificat et non l'ancien, comme je m'y attendais

J'ai également ouvert mmc et vérifié les certificats là-bas et je ne vois que le nouveau et pas l'ancien.

J'utilise également un compte avec des privilèges d'administrateur.

Cependant - lorsque j'ouvre un navigateur (depuis n'importe quel ordinateur) et que je vais sur le site https, il utilise toujours l'ancien certificat. Même lorsque je supprime l'ancien certificat du navigateur, il reçoit toujours l'ancien et non le nouveau.

Quelqu'un peut-il m'aider à comprendre où je me trompe? Comment puis-je exorciser l'ancien certificat fantôme?

D'abord quelques points qui sont probablement les mêmes pour vous

• J'essayais de mettre à jour un certificat car il a expiré.
• J'ai plusieurs domaines liés à la même IP. Il se trouve qu'il s'agit d'un certificat SAN, mais cela n'est probablement pas pertinent.
• J'essayais d'utiliser le magasin de certificats centralisé. Encore une fois, je pense que cela n'est pas pertinent pour la plupart de ma réponse.
• J'avais déjà tenté de mettre à jour le certificat mais il ne montrait pas la nouvelle date.
• Vous êtes probablement paniqué en ce moment si votre ancien certificat a déjà expiré. Respirez profondément ...

Tout d'abord, je vous recommande vivement d'aller https://www.digicert.com/help/et de télécharger leur outil DigiCert. Vous pouvez également l'utiliser en ligne.

Entrez dans votre site Web https://example.comet il vous montrera la date d'expiration et l'empreinte numérique (ce que MS appelle le hachage du certificat). Il effectue une recherche en temps réel afin que vous n'ayez pas à vous soucier de savoir si votre navigateur (ou serveur intermédiaire) met en cache quelque chose.

Si vous utilisez le magasin de certificats centralisé, vous voudrez être sûr à 100% que le fichier .pfx est la dernière version, alors allez dans le répertoire de votre magasin et exécutez cette commande:

C:\WEBSITES\SSL> certutil -dump www.example.com.pfx

Cela vous montrera la date d'expiration et l'empreinte numérique. Évidemment, si cette date d'expiration est erronée, vous venez probablement d'exporter le mauvais certificat vers le système de fichiers, alors corrigez-le d'abord.

Si vous utilisez CCS, en supposant que cette commande certutil vous donne la date d'expiration prévue (de votre certificat mis à jour), vous pouvez continuer.

Exécutez la commande:

netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt

Vous avez probablement beaucoup de choses ici, il est donc plus facile de l'ouvrir dans un éditeur de texte.

Vous souhaiterez rechercher dans ce fichier le hachage erroné que vous avez obtenu digicert.com(ou l'empreinte numérique que vous avez obtenue de Chrome).

Pour moi, cela a donné les résultats suivants. Vous verrez qu'il est lié à une adresse IP et non à mon nom de domaine attendu. C'est le problème. Il semble que cela (pour une raison quelconque, je ne suis pas sûr) ait priorité sur l'ensemble de liaisons dans IIS pour lequel je viens de mettre à jour example.com.

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Je ne sais même pas d'où vient cette liaison - je n'ai même pas de liaison SSL sur mon site par défaut, mais ce serveur a quelques années et je pense que quelque chose vient d'être corrompu et bloqué.

Vous voudrez donc le supprimer.

Pour être sûr, vous voudrez d'abord exécuter la commande suivante pour être sûr de ne supprimer que cet élément:

C:\Windows\system32>netsh http show sslcert ipport=10.0.0.1:443

SSL Certificate bindings:
-------------------------

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Maintenant que nous avons vérifié qu'il s'agit de l'empreinte numérique «mauvaise», et que l'enregistrement unique attendu, nous pouvons le supprimer avec cette commande:

C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443

SSL Certificate successfully deleted

J'espère que si vous revenez maintenant à Digicert et réexécutez la commande, cela vous donnera l'empreinte numérique de certificat attendue. Vous devriez vérifier tous les noms de SAN si vous en avez juste pour être sûr.

Je veux probablement IISRESET ici pour être sûr qu'aucune surprise plus tard.

Remarque finale: si vous utilisez le magasin de certificats centralisé et que vous voyez un comportement erratique essayant même de déterminer s'il récupère votre certificat à partir de là ou ne vous inquiétez pas - ce n'est pas de votre faute. Il semble parfois récupérer immédiatement de nouveaux fichiers, mais mettre en cache les anciens. L'ouverture et la ré-enregistrement de la liaison SSL après avoir effectué tout type de modification semble la réinitialiser, mais pas à 100% du temps.

Bonne chance :-)

Vérifiez le certificat lié au site dans IIS. Vous pouvez cliquer avec le bouton droit sur le site et choisir de modifier les liaisons. Là, vous devriez voir une liaison pour le port 443 qui est associée à un certificat SSL. Cela indique peut-être toujours l'ancien.

Je viens de comprendre. Le serveur était en fait assis derrière un serveur ISA, nous avons donc également dû installer le nouveau certificat SSL sur le serveur ISA.

J'ai eu le même problème et j'ai également vérifié les fixations. J'avais installé 2 applications dans IIS, l'une utilisant le nouveau certificat, l'autre utilisant l'ancien.

Pour corriger, j'ai dû supprimer complètement le certificat du serveur (puis éventuellement un redémarrage).

Dans le Gestionnaire IIS -> (racine de l'arborescence IIS) -> icône Certificats de serveur, sélectionnez l'ancien certificat et cliquez sur Supprimer dans le volet Actions.

J'ai vécu cela lors d'une mise à niveau IPv6. J'avais IIS fournissant une redirection au cas où quelqu'un tenterait d'accéder à un service via HTTP qui n'était pas en fait un service basé sur un serveur Web. J'ai mis à jour le service réel (un serveur vocal) pour qu'il soit IPv6, mais je n'ai pas réussi à mettre à jour les liaisons pour la redirection pour inclure les adresses IPv6.

Cela a entraîné le basculement des résolutions vers un site de capture globale lié à tous, sur lequel se trouvait le certificat obsolète. Depuis le catch tout simplement 404, il est apparu que le site ne fonctionnait pas, alors qu'en réalité il frappait le mauvais site.

Au cas où quelqu'un tomberait toujours sur ce problème. Le mien a été résolu en allant

C:\inetpub\wwwroot

Ensuite, vous trouverez un fichier web.config, ouvrez-le à l'aide du bloc-notes et supprimez la ligne avec

<httpRedirect enabled="true" destination="http://foo.company.org" />

Enregistrez et réessayez pour accéder à l'hôte local ou au site racine de votre serveur IIS.