IIS 7 sert toujours l'ancien certificat SSL


27

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?

Réponses:


28

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 :-)


3
Vous êtes un Simon parmi Simons. Dans notre cas, il s'est avéré que notre serveur avait «mis en cache» le certificat expiré sous [::1]:443alors que la mise à jour du certificat dans IIS ne mettait à jour l'enregistrement que pour 0.0.0.0:443. Merci!
tuespetre

1
Cela a résolu mon problème avec plusieurs domaines sur la même IP; n'utilise pas le magasin de certificats centralisé.
Chris F Carroll

1
J'ai dû l'utiliser plusieurs fois. Le logiciel de gestion d'hébergement Web PLESK perturbe parfois les liaisons de certificats et je finis par avoir besoin des commandes netsh ci-dessus pour supprimer la liaison incriminée. Je ne sais pas quelles versions sont toutes affectées, mais j'utilise la version actuelle de PLESK Onyx sur Windows Server 2016.
BenSwayne

Dans mon cas, c'était par nom d'hôte et par port. Ainsi, pour filtrer et supprimer par nom d'hôte, les commandes seraient: "netsh http show sslcert hostnameport = www.example.com: 443" et "netsh http delete sslcert hostnameport = www.example.com: 443"
Karthik Jayapal

14

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.


J'ai vérifié et le certificat dans les liaisons pour le port 443 est le nouveau certificat, pas l'ancien. Merci pour votre suggestion.
joechip

1
Bizarre, je n'ai jamais vu ça arriver. Bien que je ne supprime jamais les anciens certificats. Comment êtes-vous sûr d'obtenir toujours l'ancien certificat? Montre-t-il qu'il est expiré?
Tatas

Oui, dans le navigateur, vous pouvez vérifier les détails du certificat (date d'expiration, etc.) et son ancien que IIS7 sert.
joechip

1
J'ai vu ça avec - Chrome. Chrome met en cache l'ancien certificat et le montre à l'utilisateur.
TomTom

3

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.


3

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.


1
De même, nous avions en fait un site STOPPED supplémentaire qui faisait référence à l'ancien certificat, et une fois que nous avons mis à jour ce site pour utiliser le nouveau, le site réel en direct a commencé à afficher le nouveau certificat!
Action Dan

1

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.