Frage IIS 7 Immer noch altes SSL-Zertifikat bereitstellen


Ich habe ein neues SSL-Zertifikat in IIS7 installiert, das alte Zertifikat entfernt und die Bindungen für das neue Zertifikat eingerichtet - https ist jetzt nur an das neue Zertifikat gebunden.

Ich habe IIS7 (und den Windows 2008 Server selbst) neu gestartet und das Zertifikat mit folgenden Befehlen überprüft:

netsh http show sslcert

Dies zeigte das neue Zertifikat nur, wie ich es erwartet hatte

certutil -store MY

Dies zeigte auch nur das neue Zertifikat und nicht das alte, wie ich es erwartet hatte

Ich öffnete auch mmc und überprüfte die Zertifikate dort und ich sehe nur das neue und nicht das alte.

Ich verwende auch ein Konto mit Administratorrechten.

Jedoch - wenn ich einen Browser (von jedem Computer) öffne und auf die https-Seite gehe, benutzt er immer noch das alte Zertifikat. Selbst wenn ich das alte Zertifikat aus dem Browser entferne, wird immer noch das alte und nicht das neue gesendet.

Kann mir jemand helfen, herauszufinden, wo ich falsch liege? Wie kann ich das alte Phantomzertifikat exorzieren?


20
2017-10-11 15:37


Ursprung




Antworten:


Zuerst ein paar Punkte, die wahrscheinlich für dich gleich sind

  • Ich habe versucht, ein Zertifikat zu aktualisieren, weil es abgelaufen ist.
  • Ich habe mehrere Domänen an die gleiche IP gebunden. Sie sind zufällig ein SAN-Zertifikat, aber das ist wahrscheinlich irrelevant.
  • Ich habe versucht, den zentralisierten 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 das neue Datum wurde nicht angezeigt.
  • Sie sind wahrscheinlich gerade in Panik, wenn Ihr altes Zertifikat bereits abgelaufen ist. Tief durchatmen...

Zuerst würde ich empfehlen, stark zu gehen https://www.digicert.com/help/ und laden Sie ihr DigiCert-Tool herunter. Sie können es auch online verwenden.

Geben Sie auf Ihrer Website ein https://example.com und es zeigt Ihnen das Ablaufdatum und den Fingerabdruck (was MS den Zertifikatshash nennt). Es wird eine Echtzeit-Suche durchgeführt, sodass Sie sich keine Gedanken darüber machen müssen, ob Ihr Browser (oder Zwischenserver) etwas zwischenspeichert.

Wenn Sie den zentralisierten Zertifikatspeicher verwenden, sollten Sie 100% sicher sein, dass die PFX-Datei die neueste Version ist. Wechseln Sie also in Ihr Geschäftsverzeichnis und führen Sie folgenden Befehl aus:

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

Dies zeigt Ihnen das Ablaufdatum und den Hash / Fingerabdruck. Offensichtlich, wenn dieses Verfallsdatum falsch ist, hast du wahrscheinlich das falsche Zertifikat in das Dateisystem exportiert, also geh und repariere das zuerst.

Wenn Sie das CCS verwenden, können Sie fortfahren, vorausgesetzt, dieser certutil-Befehl gibt Ihnen das erwartete Ablaufdatum (des aktualisierten Zertifikats).

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, so dass es einfacher ist, es in einem Texteditor zu öffnen.

Sie sollten diese Datei nach dem WRONG-Hash durchsuchen, von dem Sie erhalten haben digicert.com (oder den Daumenabdruck von Chrome).

Für mich ergab sich 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 der Bindung in IIS hat, für die 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 kam - ich habe nicht einmal SSL-Bindungen auf meiner Standard-Website, aber dieser Server ist ein paar Jahre alt und ich denke, dass etwas gerade korrumpiert und festgefahren ist.

Also wirst du es löschen wollen.

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, dass dies der "schlechte" Fingerabdruck ist, und wir erwarten, dass ein einzelner Datensatz mit diesem Befehl gelöscht werden kann:

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

SSL Certificate successfully deleted

Hoffentlich, wenn Sie jetzt zu Digicert zurückkehren und den Befehl erneut ausführen, erhalten Sie den erwarteten Fingerabdruck des Zertifikats. Sie sollten alle SAN-Namen überprüfen, wenn Sie irgendwelche haben, um sicher zu sein.

Wahrscheinlich möchte IISRESET hier sicher keine Überraschungen später haben.

Schlussbemerkung: Wenn Sie den zentralisierten Zertifikatsspeicher verwenden und ein unberechenbares Verhalten feststellen, wenn Sie versuchen, selbst festzustellen, ob Ihr Zertifikat von dort abgerufen wird oder nicht, machen Sie sich keine Sorgen - es ist nicht Ihre Schuld. Es scheint manchmal neue Dateien sofort aufzunehmen, aber alte zu cachen. Das Öffnen und erneute Speichern der SSL-Bindung nach jeder Änderung scheint sie jedoch nicht zu 100% zurückzusetzen.

Viel Glück :-)


17
2018-04-08 08:37



Du bist ein Simon unter Simons. In unserem Fall stellte sich heraus, dass unser Server das abgelaufene Cert unter "zwischengespeichert" hatte [::1]:443 während das Aktualisieren des Zertifikats in IIS nur den Datensatz für aktualisiert 0.0.0.0:443. Vielen Dank! - tuespetre
Dadurch wurde mein Problem mit mehreren Domänen auf derselben IP-Adresse behoben. keinen zentralisierten Zertifikatspeicher verwenden. - Chris F Carroll
Ich musste das ein paar Mal benutzen. Die PLESK-Webhosting-Management-Software vermasselt gelegentlich die Zertifikatsbindungen und ich benötige letztendlich die obigen netsh-Befehle, um die fehlerhafte Bindung zu entfernen. Ich bin mir nicht sicher, welche Versionen alle betroffen sind, aber ich verwende die aktuelle Version von PLESK Onyx auf Windows Server 2016. - BenSwayne


Überprüfen Sie das Zertifikat, das an die Site in IIS gebunden ist. Sie können mit der rechten Maustaste auf die Site klicken und Bindings bearbeiten auswählen. Dort sollten Sie eine Bindung für Port 443 sehen, die einem SSL-Zertifikat zugeordnet ist. Das kann immer noch auf den alten zeigen.


11
2017-10-11 15:41



Ich habe überprüft und das Zertifikat in den Bindungen für Port 443 ist das neue Zertifikat, nicht das alte. Danke für Ihren Vorschlag. - joechip
Seltsam, ich hatte noch nie so etwas. Obwohl ich die alten Zertifikate nie entferne. Wie bist du sicher, dass du immer noch das alte Zertifikat bekommst? Zeigt es, dass es abgelaufen ist? - Tatas
Ja, im Browser können Sie die Details des Zertifikats (Ablaufdatum, usw.) und die alte, die IIS7 liefert, überprüfen. - joechip
Ich habe das mit gesehen - Chrome. Chrome speichert das alte Zertifikat und zeigt es dem Benutzer an. - TomTom


Ich habe es gerade ausgearbeitet. Der Server saß tatsächlich hinter einem ISA-Server, also mussten wir auch das neue SSL-Zertifikat auf dem ISA-Server installieren.


3
2017-10-12 17:54





Ich hatte das gleiche Problem und überprüfte auch die Bindungen. Ich hatte 2 Apps in IIS installiert, eines benutzte das neue Zertifikat, eines benutzte das alte.

Um es zu beheben, musste ich das Zertifikat komplett vom Server entfernen (dann möglicherweise einen Neustart).

Wählen Sie im IIS-Manager -> (IIS-Baumstamm) -> Serverzertifikats-Symbol das alte Zertifikat aus und klicken Sie im Bereich Aktionen auf Entfernen.


3
2018-06-17 15:02



Ebenso hatten wir eine zusätzliche STOPPED-Seite, die auf das alte Zertifikat referenzierte, und sobald wir diese Seite aktualisiert hatten, um die neue zu verwenden, begann die aktuelle Live-Site mit dem neuen Zertifikat! - Action Dan


Das habe ich während eines IPv6-Upgrades erlebt. Ich hatte IIS eine Umleitung für den Fall, dass jemand versuchte, über HTTP auf einen Dienst zuzugreifen, der eigentlich kein Webserver-basierter Dienst war. Ich aktualisierte den eigentlichen Dienst (einen Sprachserver) als IPv6, jedoch konnte ich die Bindungen für die Umleitung nicht aktualisieren, um die IPv6-Adressen einzuschließen.

Dies führte dazu, dass die Auflösungen auf einen global gebundenen Catch auf alle Sites übertraten, die das veraltete Zertifikat hatten. Da die Catch alle einfach 404 waren, schien es, dass die Seite nicht funktionierte, obwohl sie in Wirklichkeit die falsche Seite traf.


1
2017-10-12 15:12