私は最近、SSL クライアント証明書を提供し、別の署名証明書で SOAP メッセージ本文に署名する必要がある 2 つの大きなエンティティを使用して XML メッセージングを実装する必要がありました。冗長性は別として、異なる証明書を使用してメッセージ本文に署名すると、追加の保護が提供されますか?
質問を明確にし、私と EJP の間の長年にわたる誤解を指摘するために編集しました。
相互認証 (クライアント証明書) で SSL を使用することに加えてメッセージに署名することの価値は、否認防止が得られることです。ただし、メッセージの署名にクライアント証明書が使用されているかどうか、または別の署名証明書が使用されているかどうかがわかります。
メッセージに署名すると、トランザクションに対して法的強制力のある否認防止が提供されます。そのクライアントとそのクライアントだけがそのメッセージを送信できたという証拠があり、法廷で署名の検証を繰り返して証明することができます。SSL は、より低いレベルで技術的に同じことを提供しますが、署名を取得する方法がないため、法廷でそれを作成することはできません。実際のデジタル署名とは対照的に、証拠を手渡すことになります。これは法的署名であり、したがって一応の証拠です。
私がそれを「保護」と呼ぶかどうかはわかりませんが、それらは2つの異なるものです。SSL証明書は、暗号化/送信の目的でIDを検証するのに役立ちます。
SOAP署名を使用すると、エンドユーザーは、作成者（ユーザー）がXMLに署名してからXMLが変更されていないことを確認できます。
トランスポート層セキュリティでは、セキュリティはトランスポート層で終わります。SOAP メッセージに署名することで、アプリケーション層にエンドツーエンドの認証を提供します。
SSL クライアント証明書がないと、インターネット上の誰でもバックエンド サーバーと通信できます。これにより、攻撃面が増加します。
アプリケーション レイヤーのセキュリティがなければ、攻撃者が SSL ロード バランサーやリバース プロキシを制御できたらどうなるか想像してみてください。(認証なしでバックエンド サーバーに任意の SOAP メッセージを送信できますか?!)
したがって、どちらもある程度の価値を提供しているようです。
もう 1 つの質問は、キー (つまり、SSL クライアント証明書と SOAP 署名証明書) はどのように保護されているかということです。攻撃者が両方のキーの制御を取得するのが些細なことである場合、このアプローチの利益は減少します。
接続を認証するためとは異なる鍵を SOAP メッセージに署名するために使用することで、PKI の実行方法に関する柔軟性も高まります。たとえば、ネットワーク管理チームは組織ごとに 1 つの SSL クライアント証明書を発行する必要があるかもしれませんが、アプリケーション チームはその組織内のエンティティごとに 1 つの SOAP メッセージ署名証明書を必要とする場合があります。