Zunächst ein paar Punkte, die für Sie wahrscheinlich gleich sind
- Ich habe versucht, ein Zertifikat zu aktualisieren, da es abgelaufen ist.
- Ich habe mehrere Domains an dieselbe IP gebunden. Sie sind zufällig ein SAN-Zertifikat, aber das ist wahrscheinlich irrelevant.
- Ich habe versucht, den zentralen Zertifikatspeicher zu verwenden. Wieder denke ich, dass dies für die meisten meiner Antworten irrelevant ist.
- Ich hatte bereits versucht, das Zertifikat zu aktualisieren, aber es zeigte nicht das neue Datum an.
- Sie sind wahrscheinlich gerade in Panik, wenn Ihr altes Zertifikat bereits abgelaufen ist. Tief durchatmen...
Zuerst würde ich dringend empfehlen, das https://www.digicert.com/help/DigiCert-Tool herunterzuladen. Sie können es auch online verwenden.
Geben Sie auf Ihrer Website https://example.comdas Ablaufdatum und den Fingerabdruck ein (was MS den Zertifikats-Hash nennt). Es führt eine Echtzeitsuche durch, sodass Sie sich keine Sorgen machen müssen, ob Ihr Browser (oder Ihr Zwischenserver) etwas zwischenspeichert oder nicht.
Wenn Sie den zentralen Zertifikatspeicher verwenden, möchten Sie zu 100% sicher sein, dass die PFX-Datei die neueste Version ist. Wechseln Sie in Ihr Geschäftsverzeichnis und führen Sie den folgenden Befehl aus:
C:\WEBSITES\SSL> certutil -dump www.example.com.pfx
Dies zeigt Ihnen das Ablaufdatum und den Hash / Daumenabdruck. Wenn dieses Ablaufdatum falsch ist, haben Sie wahrscheinlich nur das falsche Zertifikat in das Dateisystem exportiert. Korrigieren Sie das zuerst.
Wenn Sie CCS verwenden, können Sie unter der Annahme, dass dieser Befehl certutil das erwartete Ablaufdatum (Ihres aktualisierten Zertifikats) angibt, fortfahren.
Führen Sie den Befehl aus:
netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt
Sie haben wahrscheinlich eine Menge Zeug hier drin, so dass es einfacher ist, es in einem Texteditor zu öffnen.
Sie möchten diese Datei nach dem falschen Hash durchsuchen, den Sie von digicert.com(oder dem Fingerabdruck, den Sie von Chrome erhalten haben).
Für mich ergab dies folgendes. Sie werden sehen, dass es an eine IP gebunden ist und nicht an meinen erwarteten Domainnamen. Das ist das Problem. Es scheint, dass dies (aus welchem Grund auch immer ich nicht sicher bin) Vorrang vor dem Bindungssatz in IIS hat, für den ich gerade aktualisiert habe 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
Ich weiß nicht einmal, woher diese Bindung stammt - ich habe nicht einmal SSL-Bindungen auf meiner Standardwebsite, aber dieser Server ist ein paar Jahre alt, und ich glaube, etwas ist gerade beschädigt und hängt fest.
Also wollen Sie es löschen.
Um auf der sicheren Seite zu sein, sollten Sie zuerst den folgenden Befehl ausführen, um sicherzugehen, dass Sie nur diesen einen Eintrag löschen:
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
Jetzt haben wir überprüft, ob es sich um einen "schlechten" Fingerabdruck handelt, und es ist zu erwarten, dass ein einzelner Datensatz mit dem folgenden Befehl gelöscht werden kann:
C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443
SSL Certificate successfully deleted
Wenn Sie jetzt zu Digicert zurückkehren und den Befehl erneut ausführen, erhalten Sie hoffentlich den erwarteten Fingerabdruck des Zertifikats. Sie sollten alle SAN-Namen überprüfen, um sicherzugehen.
Wahrscheinlich möchte ich hier zurücksetzen, um sicher zu sein, dass es später keine Überraschungen gibt.
Schlussbemerkung: Wenn Sie den zentralen Zertifikatspeicher verwenden und ein fehlerhaftes Verhalten feststellen, um festzustellen, ob Ihr Zertifikat von dort abgerufen wird, oder keine Sorge, es ist nicht Ihre Schuld. Es scheint, als würde es manchmal sofort neue Dateien aufnehmen, aber alte zwischenspeichern. Das Öffnen und erneute Speichern der SSL-Bindung nach einer Änderung scheint sie zurückzusetzen, jedoch nicht in 100% der Fälle.
Viel Glück :-)
[::1]:443während die Aktualisierung des Zertifikats in IIS nur den Datensatz für aktualisiert hat0.0.0.0:443. Vielen Dank!