IIS 7 Servant 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. Ils se trouvent être un certificat SAN mais ce 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 fortement d'aller à https://www.digicert.com/help/ et en téléchargeant leur outil DigiCert. Vous pouvez également l'utiliser en ligne.
Entrez dans votre site Web https://example.com et 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 de digicert.com (ou l'empreinte 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 la liaison définie dans IIS que je viens de mettre à jour pour 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 vous assurer que vous ne supprimez 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, nous avons vérifié qu'il s'agit de l'empreinte numérique `` mauvaise '' et nous prévoyons de le supprimer avec cette commande:
C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443
SSL Certificate successfully deleted
Espérons 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 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 de nouveaux fichiers immédiatement, 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 pointe peut-être toujours vers l'ancien.
J'ai eu le même problème et j'ai également vérifié les fixations. J'avais 2 applications installées dans IIS, une utilisant le nouveau certificat, une utilisant l'ancien.
Pour corriger, j'ai dû supprimer complètement le certificat du serveur (puis éventuellement un redémarrage).
Dans IIS Manager -> (racine de l'arborescence IIS) -> icône Certificats de serveur, sélectionnez l'ancien certificat et cliquez sur Supprimer dans le volet Actions.
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 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, cependant, je n'avais pas mis à jour les liaisons pour la redirection pour inclure les adresses IPv6.
Il en est résulté que les résolutions ont basculé vers un site de capture globale lié à tous qui contenait 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.