除非服务器通过消息请求它，否则客户端不会发送证书Certificate Request（参见标准，第 7.4.4 节）。如果服务器不要求证书，则客户端发送 aCertificate和CertificateVerify消息可能意味着服务器立即终止（带有unexpected_message警报）。该标准的措辞在该主题上并不太清楚，但它仍然在第 7.4 节中包含此段落：

握手协议消息按照它们必须发送的顺序如下所示；以意外的顺序发送握手消息会导致致命错误。但是，可以省略不需要的握手消息。请注意排序的一个例外：证书消息在握手中使用了两次（从服务器到客户端，然后从客户端到服务器），但仅在其第一个位置进行了描述。不受这些排序规则约束的一个消息是 HelloRequest 消息，它可以随时发送，但如果它在握手过程中到达，客户端应该忽略它。

这相当强烈地表明Certificate来自客户端的意外消息不会被忽略，而是会“导致致命错误”。

现在您可以想象一个中间人实体进行的主动修改，该实体在来自服务器的流中注入额外的Certificate Request消息，并阻止来自客户端的Certificateand Certificate Verify。这是可能的，因为初始握手是在必要时使用未受保护的记录执行的。

但是，这会使Finished交换消息时握手失败。这些消息受到保护（它们发生在切换到新协商的安全参数之后）。消息的内容是Finished迄今为止发送的所有握手消息的哈希值。由于客户端和服务器没有看到相同的消息（从客户端的角度来看，有额外Certificate Request的Certificate和Certificate Verify消息），哈希值不匹配，客户端和服务器将断开连接。

因此，不仅不清楚攻击者通过强制服务器未要求的客户端身份验证会获得什么，而且由于Finished计算消息的方式，它也根本不起作用。

如果服务器不请求，是否有人知道是否可以通过客户端证书执行身份验证？

不。如果服务器没有请求客户端证书并且客户端尝试发送它，那么服务器很可能会简单地中止连接尝试，因为它与预期的回复不匹配。

如果可能的话，是否有人知道允许强制客户端证书身份验证的客户端？

如果没有请求，如果客户端可以强制服务器接受证书，我会觉得很好奇。因此，该问题的答案必须是相当有条件的否定。

例如; RFC5246 中的第 7.4.7 节规定客户端密钥交换消息必须是第一个消息，除非已请求证书。由于没有请求证书并且客户端仍然尝试发送证书，因此服务器不得继续与客户端协商连接。