Wir haben einen IIS ARR-Server, der die Last auf zwei verschiedene einzelne IIS-Server ausgleicht.
Bei den betreffenden Servern handelt es sich um unsere internen Staging-Server. Vor drei Monaten habe ich ein kostenloses Let’s Encrypt SSL-Zertifikat zur Verwendung auf diesen Servern erstellt. Wie bei Let’s Encrypt ist es nach 3 Monaten abgelaufen. Also bin ich heute dazu gekommen, ein neues Zertifikat zu erstellen, und habe die alten Zertifikate auf dem ARR-Server und beiden Lastenausgleichsservern ersetzt.
Nachdem ich das getan und dann in einem beliebigen Browser (einschließlich des Inkognito-Modus) zur Site zurückgekehrt bin, wird immer noch das alte, ungültige Zertifikat angezeigt. Ich habe die Site sogar auf Laptops aufgerufen, die noch nie zuvor auf dieser Site waren, nur um zu sehen, ob das alte Zertifikat in meinem Browser zwischengespeichert war. Sogar diese Laptops haben die Site mit der Warnung „Nicht sicher“ geladen.
Dies sind die Schritte, die ich unternommen habe:
Auf dem ARR-Server:
- Öffnen Sie in IIS auf dem Server „Serverzertifikate“
- Entfernen Sie das alte Zertifikat
- Importieren Sie das neue Zertifikat
- Überprüfen Sie, ob das neue Ablaufdatum 3 Monate entfernt ist
- IISReset
Auf den beiden Servern mit Lastenausgleich:
- Öffnen Sie in IIS auf dem Server „Serverzertifikate“
- Entfernen Sie das alte Zertifikat
- Importieren Sie das neue Zertifikat
- Überprüfen Sie, ob das neue Ablaufdatum 3 Monate entfernt ist
- Gehen Sie auf der Site zu Bindungen
- Überprüfen Sie SSL und stellen Sie sicher, dass es sich um das neue SSL-Zertifikat handelt.
- IISReset
Doch obwohl alle Spuren des alten Zertifikats entfernt wurden, einschließlich der Löschung der eigentlichen Datei, wird es, egal was ich tue, in jedem Browser (z. B. Chrome, FF) auf jedem Computer geladen und zeigt weiterhin das alte Zertifikat an.
Ich weiß nicht, was ich sonst tun soll.
Falls das hilft:
(Ich sollte hinzufügen … es gibt SEHR VIELE genau dieser Fragen in vielen verschiedenen Foren. Ich habe Dutzende davon gelesen. Keine davon hat mich zu einer Lösung geführt.)
Antwort1
Sie müssen das neue Zertifikat unter der Standardwebsite für den HTTPS 443-Port auswählen. (Bindungen)
Antwort2
Wenn Ihr Load Balancer die SSL-Offload übernimmt, ist es das Gerät, das die SSL-Verbindung beendet und den Handshake durchführt. Sie müssen sicherstellen, dass der Load Balancer über das richtige Zertifikat verfügt.
Antwort3
Wie in vielen anderen Posts, die ich gelesen habe und in denen Leute das gleiche Problem hatten, stellte sich heraus, dass die Lösung hier letztendlich (mehr oder weniger) nichts mit der Installation des neuen SSL-Zertifikats zu tun hatte.
Kurze Antwort: Ein Neustart aller drei Server (Load Balancer und eigentliche Inhaltsserver) war erforderlich. Dadurch wurde anscheinend der Cache des Servers endlich vom alten Zertifikat gelöscht.
Lange Antwort: Einer der IIS-Inhaltsserver (nicht der ARR-Lastausgleichsserver) schien eine ungültige IP-Adresse zu haben. Das bedeutet, dass die statische IP-Adresse, die wir ihm zugewiesen hatten, anscheinend an anderer Stelle im Netzwerk verwendet wurde. Dies führte dazu, dass der ARR-Server nur den anderen Inhaltsserver verwendete. All dies führte zu seltsamen Problemen beim Bereitstellen der Site im Allgemeinen (gelegentliche 502-Fehler), die ich dem neuen SSL-Zertifikat zuschrieb, und es machte es auch schwierig, die gesamte Site nach einem Neustart wieder online zu bringen.
Fazit: Die Installation des neuen SSL-Zertifikats war nicht das eigentliche Problem. Nachdem wir das eigentliche Problem gelöst und alle Server neu gestartet hatten, war das Problem behoben.
Antwort4
Dieser Befehl hat bei mir funktioniert. Ich habe 3–4 Tage lang versucht, das Problem zu lösen, dass das alte SSL-Zertifikat nach der Installation des neuen immer noch im Browser angezeigt wird.
netsh http delete sslcert ipport={private IP des Servers}:443