Windows Server 2019 上の IIS と TLS 1.2 に問題があります。
ROOT CA を置き換え、新しくインストールされた信頼されたルート証明書があります。
現在、true に設定されているIISサイトがいくつかあります。require ssl
現在、Firefox を使用するシナリオは 2 つあります。
TLSを必要とするサイトでのGETとクライアントから（ファイアフォックス）OLD ROOT CAによって発行された証明書を送信するそしてまだ有効であり、http200/ok です。
しかし
もしクライアントから(Firefox / Chrome なども同様) 新しいルート CA によって発行された証明書を送信します (これも有効)。サーバーから 403.7 を受け取ります。(これはブラウザーでは表示されず、証明書を再度要求するだけです)
ここで 12 秒と表示される理由がわかりません。応答は即時で、クライアントでは 403.7 は表示されず、接続がリセットされたことが分かります。
さらにデバッグするにはどうすればいいですか?
そしてまた奇妙なことに:
新しいルート CA によって発行された同じ証明書を使用して同じ取得を実行しましたが、Postman からは 200/ok が返されます。その理由を調べるにはどうすればよいですか?
そして二番目に奇妙なことは:
他の Windows Server 2019 サーバーと同じサイトをホストする場合はrequire ssl、両方の証明書で問題ありません。
したがって、これは新しい証明書 CA / 発行者に関する 1 つのサーバーの問題です。
- - 編集 - - -
もう一つ奇妙なこと：
同じ取得をサーバーから、サーバー IP またはローカルホスト経由で実行し、同じ新しい証明書を送信すると、問題ありません。
つまり、リモート PC ブラウザーからアクセスする場合にのみこの問題が発生するので、netsh の問題が考えられます。
他に何をチェックすればよいのか分かりません。
そしてまた
両方のマシン、クライアント、またはサーバーに新しいルート CA がインストールされておらず、mmc>certs machine に中間の信頼されたルート CA も正常などとして表示されます。
IIS では、エンドポイント URL に一致する https バインディングの SSL 証明書のみが構成されており、新しいルート CA と古いルート CA によって発行され、違いはありません (ブラウザーから接続がリセットされ、Postman からは正常)。また、この新しいクライアント証明書をサーバーにインポートしてチェーンをチェックすると、証明書チェーンは正常で信頼済みになります。
私見ですが、同じクライアント証明書を使用してローカルホストから動作する場合、IIS 設定は 100% 正常であるため、他に何か問題があるはずです。おそらく netsh に関する問題でしょうか。また、確認しましたが、正常に動作する 2 番目のマシンと同じです。
さらに何をチェックすればよいか、どこに問題がある可能性があるかアドバイスをお願いします。
答え1
サイトの証明書も新しいルートCAに置き換えましたか。ルートCAを変更すると、証明書チェーン全体が変更されるため、証明書自体もそれを反映する必要があります。
テストのために、新しいルート CA から新しい証明書を発行し、関連するサイトの SSL バインディングにインポートします。また、証明書を変更した後は、ブラウザのキャッシュをクリアして IIS を再起動してください。
もう1つのより複雑なオプションは、現在の証明書をエクスポートし、テキストファイルとして開いてデコードし、新しいルートCAがそこに含まれているかどうかを確認することです。