Ich habe ein Problem mit IIS unter Windows Server 2019 und TLS 1.2.
Ich habe die ROOT-CA ersetzt und es sind neue vertrauenswürdige Root-Zertifikate installiert.
Jetzt IIShabe ich auf einigen Sites, wo das require sslauf „True“ eingestellt ist.
Derzeit gibt es zwei Szenarien bei der Verwendung von Firefox:
Ein GET auf jeder Site, die TLS erfordert undvom Kunden(Feuerfuchs)Senden Sie ein Zertifikat, das von der alten Root-Zertifizierungsstelle ausgestellt wurde.und ist immer noch gültig und http200/ok.
ABER
Wennvom Kunden(Bei Firefox, Chrome usw. ist es dasselbe) Senden Sie ein Zertifikat, das von der NEUEN ROOT-CA ausgestellt wurde (ebenfalls gültig). Ich erhalte eine 403.7-Meldung vom Server. (Wird im Browser nicht angezeigt, es wird einfach erneut nach dem Zertifikat gefragt.)
Ich weiß nicht, warum hier 12 Sekunden angezeigt werden. Die Antwort erfolgt sofort und auf dem Client wird mir nicht 403.7 angezeigt, sondern eine zurückgesetzte Verbindung?
Wie kann ich versuchen, mehr zu debuggen?
und auch das Seltsamste:
Wenn ich dasselbe mit demselben von der neuen Stammzertifizierungsstelle ausgestellten Zertifikat mache, aber vom Postboten eine 200/ok-Meldung erhalte, wie finde ich heraus, warum?
und das zweitseltsamste:
Wenn ich dieselbe Site require sslauf einem anderen Windows Server 2019-Server hoste, ist es mit beiden Zertifikaten in Ordnung.
Es handelt sich also um dieses eine Serverproblem mit der neuen Zertifizierungsstelle/dem neuen Herausgeber.
----bearbeiten------
noch etwas Merkwürdiges:
Wenn ich dasselbe mache, aber vom Server, über die Server-IP oder den lokalen Host, und DASSELBE neue Zertifikat sende, ist es ok.
Dieses Problem tritt also NUR auf, wenn wir vom REMOTE-PC-Browser aus wechseln. Ich denke also an einige Netsh-Probleme?
Keine Ahnung, was noch zu prüfen ist.
und auch
Es ist keine neue Stammzertifizierungsstelle auf den beiden Maschinen, dem Client oder dem Server installiert und in mmc>certs sichtbar. Die vertrauenswürdige Stammzertifizierungsstelle der Maschine ist auch im Zwischenzustand ok usw.
Auf IIS ist nur ein SSL-Zertifikat für die HTTPS-Bindung konfiguriert, das mit der Endpunkt-URL übereinstimmt und von der neuen/alten Stammzertifizierungsstelle ausgestellt wurde, kein Unterschied – Verbindung vom Browser zurückgesetzt und von Postman ok. Und auch wenn ich dieses neue Client-Zertifikat auf den Server importiere, damit ich die Kette überprüfen kann, ist die Zertifikatskette ok und vertrauenswürdig.
Wenn es vom lokalen Host mit demselben Client-Zertifikat funktioniert, sind die IIS-Einstellungen meiner Meinung nach 100 % in Ordnung. Es muss also etwas anderes sein? Vielleicht etwas mit Netsh? Habe es auch überprüft und es ist dasselbe wie auf der zweiten Maschine, die einwandfrei funktioniert.
Bitte geben Sie einen Rat, was noch zu prüfen ist oder wo das Problem liegen könnte?
Antwort1
Haben Sie auch die Zertifikate auf den Websites durch neue Stammzertifizierungsstellen ersetzt? Wenn Sie die Stammzertifizierungsstelle ändern, ändert sich die gesamte Zertifikatskette, sodass die Zertifikate selbst dies auch widerspiegeln müssen
Zum Testen würde ich ein neues Zertifikat von der neuen Stammzertifizierungsstelle ausstellen und dieses in die SSL-Bindung der beteiligten Sites importieren. Stellen Sie außerdem sicher, dass Sie den Browser-Cache leeren und IIS nach dem Ändern der Zertifikate neu starten.
Eine andere, komplexere Möglichkeit wäre, das aktuelle Zertifikat zu exportieren, als Textdatei zu öffnen, es zu dekodieren und zu prüfen, ob die neue Stammzertifizierungsstelle darin enthalten ist.