我在 X 公司工作，我们想与 Y 公司进行 B2B 交易。这样做时，Y 需要客户端身份验证；他们已经提供了服务器端身份验证 - 所以这将是一个相互的 SSL 交易。
我的理解是，我只需要提供我的 CA 签名证书作为客户端 HTTPS 通信的一部分。这样做时，非对称加密保证(即公钥/私钥技术)确保我就是我声称的那个人——实际上，不可能冒充我。 (根 CA 确保我就是我，这就是他们签署我的证书的原因，并且有可能证明我没有“制造”证书)。
这是我的问题:这就是我需要向 Y 公司提供的全部信息吗？
或者，我是否必须提前向他们提供另一个 key ，以便他们可以确保我不是一个恰好“获得”根签名证书的流氓我(X公司)？看起来，如果一个人必须向他希望在客户端参与的所有各方提供这个额外的 key ，这似乎会使客户端 SSL 不像服务器端 SSL 那样可扩展。我的猜测是不可能“获得”客户端证书；客户端证书的实际传输由交易的某些状态进一步编码(这不是可逆工程，不可行)。
这是否有意义，我是对还是错？如果我错了，Y 实际上是否需要从连接到它的每一方获得一个“额外的”预通信 key ？ (他们想验证哪些)？
谢谢。
===
感谢下面的回复，至少前两个到目前为止是有帮助的(其他人可能会稍后到达)。
让我更详细地谈谈我的技术问题。
假设公司 Y 试图“重新使用”我的客户端证书，以在与另一家公司(例如“Z”)的另一项客户端交易中冒充我。这可能吗？我在想 - 再一次，也许表述不当 - 客户端证书传输的某些部分 防止整个 key 被泄露，即“重用”a 在技术上是不可行的收到客户端证书，因为您无法(可行地)对与客户端证书通信的通信进行反向工程。
如果不是这种情况，Y 不能重新使用证书，在与 Z 通信(客户端)时冒充 X 吗？
ps:我意识到安全从来都不是 100%，只是想了解这里技术上什么是可行的，什么不是。
非常感谢!
===
更多技术细节，我非常感谢任何额外的输入 - 这非常有帮助。
从外行的角度来看，我担心的是当客户发送他的客户证书时，他发送了什么？好吧，他必须使用他的私钥加密该证书。他用公钥发送密文，然后接收方可以使用该公钥解密私钥编码的有效负载，对吗？这是有道理的，但后来我想知道 - 是什么阻止了某人听到该通信并简单地在重放攻击中重新使用私钥编码的有效负载。只需重播发送的确切 1 和 0。
这是我认为可以防止的——它可以在 TLS RFC 的多个地方找到，但例如在 F.1.1 中:
F.1.1. Authentication and key exchange TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked. The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the certificate verify and finished messages, encryption keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished message, parties thus prove that they know the correct pre_master_secret.
我相信是与 session 相关的随机化阻止了这些重放攻击。
听起来不错还是我把事情搞混了？
最佳答案
只要您保证私钥安全(并且 CA 保证他们的签名 key 安全)，“Y 公司”就不需要任何其他信息来验证您。换句话说，他们可以确定请求确实来自证书中指定的主题。
但是，这并不意味着您有权做任何事情。实际上，大多数使用客户端证书的系统都有一个“带外”过程，您可以在其中提供在客户端证书中指定的“主题”专有名称，然后系统会为该名称分配一些特权。
事实上，由于一些实际限制，一些系统实际上将权限与证书本身相关联(使用颁发者的名称和证书序列号)。这意味着如果您获得新证书，则可能需要重新注册它，即使它具有相同的主题名称也是如此。
证书仅向依赖方保证您具有特定名称。该方需要一些额外的机制来确定您可以做什么。
与基于“ secret ”(对称) key (例如密码)的身份验证机制不同，服务器只需要用于非对称身份验证的公共(public)信息。私有(private)签名 key 应该永远被泄露；客户端身份验证当然不需要。
通过基于密码的对称身份验证，客户端和服务器可以访问相同的字节串—— key 。使用公钥密码术，只公开 key 对中的公钥。相应的私钥从未公开过，也没有发现从公钥中推导出私钥的实用方法。
只要您妥善保管私钥，Y 公司的服务器就无法伪造看似来自您的请求。
通过要求客户端对包含服务器为每次握手随机生成的数字(这是“ServerHello”消息的“随机”成员)的消息进行数字签名，可以击败客户端身份验证重放攻击。如果在先前 session 中用于验证客户端的数据包被重新使用，服务器将无法验证签名，并且不会验证重放攻击。
RFC 2246, Appendix F.1.1.2可能是更有帮助的引用——尤其是第三段:
When RSA is used for key exchange, clients are authenticated using the certificate verify message (see Section 7.4.8). The client signs a value derived from the master_secret and all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.
关于authentication - 客户端SSL理论题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1668433/