問題タブ [ssl-client-authentication]

現在、サーバーとクライアントで相互 SSL を有効にする際に問題があります。

サーバー側では、ClientAuth を有効にして tomcat を構成し、クライアントの証明書をトラストストアに構成します。

したがって、ssl ハンドシェイク中に、サーバーの証明書要求を確認できます。

サーバーがサブジェクト識別名で証明書を要求していることがわかります。ただし、クライアント側では、クライアントがキーをフィルター処理するときに、DN を発行者 DN として扱います。コードはこちらを参照してください: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6- b14/sun/security/ssl/SunX509KeyManagerImpl.java#378

したがって、これは問題につながります：

そのため、握手は失敗しました。

証明書情報の一部を次に示します。

ここでの私の質問は、なぜサーバーはサブジェクト DN でクライアント証明書を要求するのに、クライアントは IssuerDN でフィルタリングするのですか?

それらが正常に接続できるようにするには、クライアントの親証明書を使用してサーバーのトラストストアを構成する必要があります。サブジェクト DN は発行者と同じになります: DC=com、DC=ドメイン、CN=ドメイン。com セキュリティ

これに関するアイデアはありますか？これについては誤解があるかもしれませんが、それでも理由を知りたいです。

別の会社のサーバーへの相互認証を使用して TCP TLS 1.0 接続を成功させる C# アプリケーションがあります。SslStream クラスを使用して実装されます。私たちは、この非常に大きな組織の多くのクライアントの 1 つにすぎません。

上記のこの TCP リンクは、TLS 1.2 + SHA2 アップグレードを受ける必要があります。私たちの側で必要なすべての手順を実行し、ローカルサーバーでのテストに成功した後でも、リモートサーバーへの接続の試みはすべて失敗しています. 長い調査の結果、TLS ハンドシェイク中に、サーバーが署名ハッシュ アルゴリズム = SHA1-RSA のオプションのみを含む証明書要求を送信していることが明らかになりました(下の図を参照)。私たちの証明書は SHA256 です。その結果、SslStream は証明書をサーバーにまったく送信せず、サーバーはこれをハンドシェイクの失敗と見なし、接続を閉じます。

この煩わしさの理由は、相手方が非常に古い (10.x) バージョンの F5 ファイアウォールを使用して SSL を終了しているためです。クライアントの SHA2 証明書をサポートしていますが、証明書要求で SHA1/RSA 署名ハッシュ アルゴリズムのみを送信します。

上記の事実を認めながらも、相手方はすぐに F5 をアップグレードすることができません。彼らは、要求された署名ハッシュ アルゴリズムを無視し、とにかく SHA256 証明書を送信することを提案しました。それらに接続している他のクライアントは、どうにかしてそれを行うことができたようです。

残念ながら、.Net の SslStream は、TLS ハンドシェイクに対してそのレベルの微調整を提供していません。

したがって、質問: SHA1RSA ベースの証明書に対するサーバーの要求をまったく無視することは可能ですか? どのようなオプションがありますか? TLS 1.2 を実装する SslStream の代替手段はありますか? オープンソースのサードパーティ ソリューションはありますか? どんな提案も役に立ちます。前もって感謝します。