要使用 SSL 进行基于证书的客户端身份验证，客户端必须“拥有”证书，即有权访问私钥和相应的证书（由服务器接受的 CA 颁发）。当客户端是 Web 浏览器时，没有办法对其进行转义：浏览器必须知道密钥本身。

浏览器有两种方式“知道”私钥+证书对：

1. 让 CA 生成密钥对，创建证书，并将整个打包为 PKCS#12/PFX 文件，然后将其导入浏览器。
2. 让浏览器生成密钥对，将公钥发送给生成证书的 CA；然后将证书导入浏览器。

第二种方法通常被认为是“更好”的通用方式。特别是，如果证书必须在以后以具有法律约束力的方式用于签署文件，那么密钥生命周期的细节对于法律价值很重要；细节很复杂，并且很大程度上取决于当地法律，但是，粗略地总结一下，如果私钥曾经存在于用户计算机以外的系统上，即使是暂时的，那么它将无法工作。但是，在身份验证场景中，尤其是对于 SSL/TLS 会话，这可能不是问题。

<keygen>元素是实现第二种模型的 HTML5 方式。它实际上比 HTML5 更早，并且起源于 Netscape Navigator。有关如何使用它的详细信息，请参阅此页面和该文件。对于 Internet Explorer，您必须使用 Microsoft 特定的方式，这种方式称为 Xenroll，但已被弃用，取而代之的是 CertEnroll（有关介绍，请参阅此博客文章）。事实证明，微软不愿意<keygen>正式实施，因为他们不喜欢它所做的事情。

无论如何，如果您进行 SSL 级别的证书身份验证，那么您必须与浏览器支持的用户界面和体验相抗衡——从人体工程学的角度来看，这并不是完全最佳的。替代方案包括在SSL 隧道中进行一些身份验证，在 Web 上下文中，这意味着用户输入的内容（密码或 click-o-matic 等效项）或 Javascript 技巧。Javascript 的问题在于它无法访问客户端操作系统存储库以获取私钥（以及与智能卡的接口），除非使用了一些非标准功能。

SSL/TLS 中基于证书的身份验证不一定比其他身份验证方法“更安全”。证书允许将标识与认证分开。这是一个很好的特性，但在整体架构不需要这种分离的系统中是无用的。

我认为使用 keygen 元素有很多缺点，因为它已经在您的帖子中列出。如果您有一个应该易于访问并与许多客户端兼容的 Web 服务，那么使用 keygen 实现客户端身份验证是非常困难的，这是一个非常新且不是很成熟的解决方案。

最好的解决方案是向您的客户提供加密令牌，并带有由您的 CA 签名的预加载证书。当然，这会增加很多复杂性，因为您必须管理客户端证书的生成和分发，如果您有很多客户端并且没有 CA 的基础架构，这可能很难做到。此解决方案的优势是为您的客户提供非常强大的身份验证机制。

如果您只是想防止 MITM 攻击，在大多数情况下，使用 SSL 和良好的用户/密码访问机制可能就足够了。

这在很大程度上取决于您拥有什么资源，您要保护什么，以及您的应用程序的用户是谁以及谁是您的应用程序的用户。回答这些问题将是构建安全系统过程的第一步。

更新：

关于您描述的威胁模型，我认为您的模型不会提供针对受损 CA 的保护。这是一个例子：

• CA 遭到入侵，并为您的域颁发了证书
• 客户端的 DNS 受到攻击，因此在查询您的域时，它会以攻击者的 IP 进行响应
• 客户端尝试连接，它与流氓服务器建立连接，然后连接到您的服务器
• 恶意服务器充当客户端，从新设备连接并生成新的客户端证书。
• 即使真正的客户端发送了他现有的证书，流氓服务器也会忽略它。

上面描述的攻击假设客户端可以拥有多个证书（一个用于他连接的每个设备）。如果您不想实现此行为，那么普通客户很难将证书复制到他正在使用的每台设备上，当然，用户体验也会很差。

总而言之，保护 CA 是一项艰巨的任务，我认为只要不大规模实施 DNSEC 等新技术，就无能为力了。

另一方面，知名 CA 的黑客攻击并不是每天都会发生的事情。只要确保您没有从无名 CA 购买证书，并且您目前应该足够安全。