Tcpdumpを使用してクライアント証明書を取得すると、証明書の長さがゼロになる
モバイルアプリをプロキシしようとしています（ Fiddler を使用）。これにより、接続先のサーバーにクライアント証明書が送信されます。 Tcpdump でトラフィックをキャプチャし、クライアント証明書を取得してそれをフィドラーで使用すれば、これをバイパスするのに十分だと思います。
ただし、プロキシを使用せずにTcpdumpを使用してパケットをキャプチャすると、サーバーが証明書を送信し、クライアント証明書を要求し、クライアントが空の証明書を送信します（証明書の長さは0）。 SSLプロセス全体の後、アプリケーションデータは正常に送信され、その後、アプリは正常に動作します。証明書の長さ0が受け入れられた場合、証明書はすべて受け入れられると思いましたが、そうではありません。
確かに偽の証明書をFiddlerに渡しましたが、同様のエントリが再び表示されます（証明書の長さ0）、そのため、クライアントが証明書を送信する方法について何か不足していると思います。
SSLプロセスの後、サーバーEncrypted Alertが表示され、アプリがまったく機能しません。それで、なぜ私は0証明書を送信しても証明書の長さは？偽物であっても、Tcpdumpに表示されるべきではありませんか？
[〜＃〜] tls [〜＃〜] では、独自の証明書を提示した後、サーバーがクライアント証明書を要求する場合があります（CertificateRequestメッセージ）。要求には、サーバーが証明書の検証に使用するCA名のリストが含まれています。次に、クライアントは一致する証明書を含むCertificateメッセージで応答する必要があります。クライアントは、所有する証明書をスキャンして、指定された名前の1つであるCAによって直接または間接的に発行された証明書を探します。サーバー。
クライアントが一致する証明書を持っていない場合、空のリストを含むCertificateメッセージを送信する必要があります（これは観察されます）（SSL 3.0では、クライアントはCertificateメッセージ全体ですが、TLS 1.0以降は空のCertificateが必須です）。
クライアントが証明書を提示しない場合、次に何をするかはサーバーが決定します。それでもサーバーは接続を受け入れます。 IIS構成では、これが「証明書の要求」と「証明書の要求」の違いです。可能な動作の中で、サーバーはSSLレベルで接続を受け入れる場合があり、その後、トンネル内のアプリケーションレベルの認証プロトコルにフォールバックします（外部からは、「暗号化されたアプリケーションデータ」として表示されます）。
したがって、クライアント側に一致する証明書がないか、クライアントが自分の証明書が一致していることを通知しません。中間CAがない場合（ルート->中間CA->エンドエンティティで、サーバーはルートの名前を送信しますが、クライアントは "エンドエンティティ"しか認識しません）。