サーバーが要求しなくてもSSL / TLSクライアント証明書認証を強制しますか？
通常、サーバーは、サーバー証明書メッセージでクライアント証明書が必要か、または必要かどうかを指定します。
サーバーが要求しない場合に、クライアント証明書を介して認証を実行できるかどうか誰かが知っていますか？
そして、可能であれば、クライアント証明書認証を強制することを許可するクライアントを誰かが知っていますか？
サーバーがCertificate Requestメッセージで証明書を要求しない限り、クライアントは証明書を送信しません（ 標準 、セクション7.4.4を参照）。サーバーが証明書を要求しない場合、クライアントからのCertificateおよびCertificateVerifyメッセージの送信は、サーバーからの即時終了を意味する可能性があります（unexpected_messageアラートを使用）。標準の表現はその主題について明確ではありませんが、セクション7.4にこの段落が含まれています。
以下に、ハンドシェイクプロトコルメッセージを送信する必要がある順序で示します。予期しない順序でハンドシェイクメッセージを送信すると、致命的なエラーが発生します。ただし、不要なハンドシェイクメッセージは省略できます。順序の1つの例外に注意してください。証明書メッセージはハンドシェイクで2回使用されます（サーバーからクライアントへ、次にクライアントからサーバーへ）。ただし、最初の位置でのみ説明されています。これらの順序ルールに拘束されないメッセージは、HelloRequestメッセージです。これはいつでも送信できますが、ハンドシェイクの途中で到着した場合、クライアントによって無視される必要があります（SHOULD）。
これは、クライアントからの予期しないCertificateメッセージが無視されず、「致命的なエラーが発生する」ことをかなり強く示唆しています。
Man-in-the-Middle エンティティによるアクティブな変更を想像できます。このエンティティは、サーバーからのフローに追加のCertificate Requestメッセージを挿入し、クライアントからのCertificateおよびCertificate Verifyをブロックします。保護されていないレコードを使用して、必然的に最初のハンドシェイクが実行されるため、これは可能です。
ただし、これにより、Finishedメッセージが交換されたときにハンドシェイクが失敗します。これらのメッセージは保護されています（新しくネゴシエートされたセキュリティパラメータへの切り替え後に表示されます）。 Finishedメッセージの内容は、これまでに送信されたすべてのハンドシェイクメッセージのハッシュです。クライアントとサーバーが同じメッセージを見ていないため（クライアントの観点から、余分なCertificate Request、CertificateおよびCertificate Verifyメッセージがありました）、ハッシュ値は一致せず、クライアントとサーバーは接続をドロップします。
したがって、サーバーが要求しなかったクライアント認証を強制することによって攻撃者が何を得るかが不明確であるだけでなく、Finishedメッセージの計算方法が原因でまったく攻撃されません。
サーバーが要求しない場合に、クライアント証明書を介して認証を実行できるかどうか誰かが知っていますか？
いいえ。サーバーからクライアント証明書が要求されず、クライアントがそれを送信しようとした場合、サーバーは期待される応答と一致しないため、接続試行を単に中止する可能性が非常に高くなります。
そして、可能であれば、クライアント証明書認証を強制することを許可するクライアントを誰かが知っていますか？
証明書が要求されていない場合に、クライアントがサーバーに強制的に証明書を受け入れさせることができるとしたら、それ以上に興味があると思います。したがって、その質問への答えはかなり適格なものでなければなりません。
例えば; RFC5246のセクション7.4.7では、証明書が要求されていない限り、クライアントの鍵交換メッセージを最初のメッセージにする必要があると述べています。証明書が要求されておらず、クライアントがまだ証明書を送信しようとしているため、サーバーはクライアントとの接続のネゴシエーションを継続してはなりません。