it-swarm.com.de

IIS 7 Immer noch altes SSL-Zertifikat

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

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

netsh http show sslcert

Dies zeigte nur das neue Zertifikat, wie ich erwartet hatte

certutil -store MY

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

Ich habe auch mmc geöffnet und dort die Zertifikate überprüft und sehe nur das neue und nicht das alte.

Ich verwende auch ein Konto mit Administratorrechten.

Wenn ich jedoch einen Browser (von einem beliebigen Computer aus) öffne und zur https-Site gehe, wird weiterhin das alte Zertifikat verwendet. Selbst wenn ich das alte Zertifikat aus dem Browser entferne, wird das alte und nicht das neue Zertifikat gesendet.

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

27
joechip

Zuerst 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, zu https://www.digicert.com/help/ Zu gehen und das DigiCert-Tool herunterzuladen. Sie können es auch online verwenden.

Geben Sie auf Ihrer Website https://example.com Das Ablaufdatum und den Fingerabdruck ein (was MS den Zertifikat-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 daher in Ihr Speicherverzeichnis 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/Fingerabdruck. Wenn dieses Ablaufdatum falsch ist, haben Sie wahrscheinlich nur das falsche Zertifikat in das Dateisystem exportiert. Korrigieren Sie es also zuerst.

Wenn Sie das CCS verwenden und diesen Befehl certutil annehmen, erhalten Sie das erwartete Ablaufdatum (Ihres aktualisierten Zertifikats). Sie können fortfahren.

Führen Sie den folgenden Befehl aus:

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

Sie haben wahrscheinlich eine Menge Dinge hier, so dass es einfacher ist, sie in einem Texteditor zu öffnen.

Sie sollten diese Datei nach dem FALSCHEN Hash durchsuchen, den Sie von digicert.com Erhalten haben (oder nach 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 der Bindung hat, die in IIS, das ich gerade für example.com Aktualisiert habe, festgelegt wurde.

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 denke, etwas ist gerade beschädigt und steckt fest.

Sie möchten es also löschen.

Um auf der sicheren Seite zu sein, sollten Sie zuerst den folgenden Befehl ausführen, um sicherzustellen, dass Sie nur dieses eine Element 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 dies der "schlechte" Fingerabdruck ist, und der erwartete einzelne Datensatz kann mit diesem Befehl gelöscht werden:

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, wenn Sie welche haben, nur um sicherzugehen.

Wahrscheinlich möchte ich hier IISRESET, um sicher zu sein, dass es später keine Überraschungen gibt.

Letzter Hinweis: Wenn Sie den zentralen Zertifikatspeicher verwenden und ein unberechenbares Verhalten feststellen, das versucht, festzustellen, ob Ihr Zertifikat von dort abgeholt wird oder nicht, machen Sie sich keine Sorgen - es ist nicht Ihre Schuld. Es scheint manchmal neue Dateien sofort aufzunehmen, aber alte zwischenzuspeichern. Das Öffnen und erneute Speichern der SSL-Bindung nach einer Änderung scheint sie zurückzusetzen, jedoch nicht zu 100%.

Viel Glück :-)

28
Simon

Ü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 Bindungen bearbeiten auswählen. Dort sollte eine Bindung für Port 443 angezeigt werden, die einem SSL-Zertifikat zugeordnet ist. Das könnte immer noch auf den alten hinweisen.

14
Tatas

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

Um dies zu beheben, musste ich das Zertifikat vollständig vom Server entfernen (dann möglicherweise einen Neustart).

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

3
Andy Joiner

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

3
joechip

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

Dies führte dazu, dass die Auflösungen auf eine global gebundene Catch-All-Site übergingen, auf der sich das veraltete Zertifikat befand. Da der Fang alle nur 404 war, schien es, dass die Site nicht funktionierte, obwohl sie in Wirklichkeit die falsche Site traf.

1
AJ Henderson

Für den Fall, dass noch jemand auf dieses Problem stößt. Meins wurde gelöst, indem ich zu ging

C:\inetpub\wwwroot

Dann finden Sie eine web.config-Datei, öffnen sie mit dem Editor und entfernen die Zeile mit

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

Speichern Sie und versuchen Sie erneut, auf den lokalen Host oder die Root-Site Ihres IIS Servers) zuzugreifen.

0