HTTP 基本認証資格情報またはクライアント証明書資格情報を使用して要求を受け入れることができる、セルフホステッド WCF サービスに単一の SSL エンドポイントが必要です。
IIS ホステッド サービスの場合、IIS は「クライアント証明書を受け入れる」と「クライアント証明書が必要」を区別します。
WCFWebHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;は、IIS の「証明書が必要」設定に類似しているようです。
クライアント証明書の資格情報を受け入れるが、すべてのクライアントからそれらを要求しないように、WCF セルフホステッド サービスを構成する方法はありますか? セルフホステッド WCF サービス用の IIS "Accepts client certificates" の WCF アナログはありますか?
それはうまくいかないと思います。
空の証明書が作成されるか、証明書への割り当てられていない参照が受け入れられるようにクライアントに影響を与えることができない場合は、サーバー側からこの特殊なケースを検証し、ログ ファイルに記録する方法はありません。IIS の動作を模倣する必要があり、事前に確認する必要があります。それは推測です。専門知識なし。
通常行うことは、a) 提供された証明書のチェーンをたどって証明書を検証しようとすることです b) 提供された証明書がない場合は、クライアントを二重および三重にチェックし、発生をログに記録します。
「.net」では交渉をコントロールする機会が与えられないと思います。
真ん中の男に扉を開けるイモ。それが、MSがそれを許可していないと思う理由であり、Javaも同様です。
最後に、サービスを IIS の背後に置くことにしました。WCF はとにかく 'IIS' (http.sys) を使用します。IIS にもう少し処理させても、大きな違いはありません。
SBB は、これを便利な方法で実行できる数少ないライブラリの 1 つです。交渉のすべてのステップにアクセスできます。
DelphiとELDOS SecureBlackbox（「前」のWCF ... net 3.0）を使用すると、そのように機能しました。現在、サーバー側で広範な調査を行う必要があり、人々は両面アプローチに移行しています。
Java では、単純にすべてを信頼する TrustManager を作成する必要があります。
IIS が残っているオプションだと思います。