相互認証用のクライアント証明書を要求するWebサーバーがあります。適切な証明書がクライアントブラウザにロードされていると思います。ただし、ブラウザが証明書を見つけることができず、IEからページにアクセスすると、「このページは表示できません」というエラーが表示されます(クロムとFFでも失敗します)。サーバーがクライアントブラウザに要求している証明書を正確に把握するのに役立つツールはありますか?
一部のネットワークモニターを試してみましたが、交換できない多くのデータがあり、検出できません。
サーバーが最初のハンドシェイク中に証明書を要求する場合は、Wiresharkを使用して、Certificate Request
TLSメッセージ(Server Hello Done
の直前)を探します。このパッケージの詳細を調べると、受け入れ可能なCAのリストを示すcertificate_authorities
リストが表示されます。ローカルチェーンは、これらのいずれかに一致する必要があります。
表示されるCertificate Request
メッセージがない場合は、再ネゴシエートされたハンドシェイクにある可能性があります。この場合、この2番目のハンドシェイクは暗号化されるため、すぐには表示されません。 Wiresharkの最近のバージョンでは、プレマスターシークレットを使用できます( "を参照してください)Wiresharkの(Pre)-Master-Secretセクションの使用SSL wikiページ 、そして この答え もちろんです)これは一般により複雑ですが、これは可能です。
より一般的には、問題をデバッグするために、Firefoxを使用するときに、SSLDEBUG
(およびSSLDEBUGFILE
)などの他の NSS環境変数 も確認します。
さらに、openssl s_client -connect my.Host.example:443 -servername my.Host.example
を使用して(必要に応じてさまざまな詳細レベルで)、サーバーへのブラウザー接続をシミュレートできます。これにより、少なくともCertificate Request
メッセージでアドバタイズされるCAがわかります。サーバーが再ネゴシエーションを使用する場合、多かれ少なかれこのように見える(必要なものに適応した)最小限のHTTPリクエストを書く必要があるかもしれません:
GET /my/protected/resource HTTP/1.1
Host: my.Host.example
(一部の複雑な設定では、ブラウザのリクエストから表示される他のヘッダーを、開発者ツールを使用してコピー/貼り付けする必要がある場合があります。)
(-prexit
オプションも便利な場合があります this answer にクレジットしてください。)
コメントから、手動でのHTTPリクエストの偽造は機能しないようですので、curl --verbose https://my.Host.example/my/protected/resource > /dev/null
を使用することもできます(--trace
や--trace-ascii
などのデバッグレベルを使用することもできます。必須、curlのmanページを参照)。これはこのようなものを生成するはずなので、うまくいけばどこかにCertificate Request
が表示されるはずです:
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server key exchange (12):
{ [data not shown]
より現実的なリクエストが必要な場合は、開発者ツールを開いた後でChrome=から実際のリクエストを作成します。それを右クリックして[cURLとしてコピー]を使用し、貼り付けて、 curlで使用します(--verbose
またはその他を追加):これにより、必要なヘッダーがコピーされます。例のビデオ here があります。
最近このような問題に直面しました。より新しいバージョンのFirefoxを使用している場合の症状はPR_END_OF_FILE_ERROR
私が疑い、最終的に見つけたのは、デスクトップ上のインターネット保護ソフトウェアでした。
特定のものはMcAfee Online Threat Preventionでした。私の疑いは、元のリクエストを何らかの方法でインターセプトして再作成しましたが、相互認証との互換性がないため、セッションが終了します。
これが原因で、AiProtectionまたはAsusルーター上のTrend Microが有効になっている場合に何かが同じ問題を引き起こす可能性があると思います。マカフィーやインターネット保護ソフトウェアがインストールされていない場合は、注意が必要です。
これは「説明に基づく最も可能性の高い問題」なので、「トラブルシューティングの方法」ではありませんが、秘密鍵とクライアント証明書をインストールしましたか?
ブラウザーのキーストア(WindowsではIEまたはChrom [e | ium]の場合、Windowsキーストアです)で、両方のクライアント証明書および対応する秘密鍵がインストールされます。
証明書マネージャーのGUIで証明書を確認する場合([検索の開始]を使用するか、certmgr.msc
;おそらく「システム証明書」ではなく「ユーザー証明書」ストアが必要です)、証明書アイコンの左上に小さな鍵のアイコンがあるはずです(証明書アイコン自体が長方形で、右下に小さなリボンがあります)。証明書を開くと、[全般]タブの下部に小さな鍵のアイコンが表示され、「この証明書に対応する秘密鍵があります」と表示されます。
そうでない場合、証明書はクライアント証明書として使用できません。サーバーが証明書をブラウザーに提示するときにサーバーが証明書の秘密キーを必要とするのと同様に、ブラウザーがサーバーに提示するときにブラウザーは証明書の秘密キーを必要とします。秘密鍵がないと、ブラウザーは証明書をTLS相互認証のオプションとして表示しません。
この問題を修正するには、証明書の作成に使用した秘密鍵を見つけて、コンピューターにインストールします。 .PFXまたは.P12(または同様の)ファイルの証明書とバンドルされる可能性があります。証明書が別のマシンからエクスポートされた場合は、秘密鍵とともにエクスポートされたことを確認してください(デフォルトでは、Windowsは秘密鍵をエクスポートしません)。秘密鍵を取得できない場合-それが失われた場合、またはそのパスフレーズが失われた場合、またはエクスポート不可とマークされている場合(そして、とにかくかなりハッキーな手順を実行してエクスポートしない場合)は、それが存在する場合-新しいキーを使用して新しい証明書署名リクエストを作成し、証明書を再度発行する必要があります。
ブラウザーが証明書を信頼または提示しない可能性があるその他の考えられる理由:
お役に立てば幸いです。