客户端认证只是没有足够好的成本/收益权衡。它们让用户非常困惑，因此支持成本上升。而且它们仍然只是比特，因此是“你知道的东西”，并且容易受到浏览器上的一系列软件攻击、分发方案、网络钓鱼等。

硬件令牌方案（双因素身份验证）更适合良好的身份验证。单点登录 (SSO) 方案可能是联合的，并且可能由硬件令牌支持，可以解决更多问题并且更易于部署。

对于用户来说，管理大量证书要比当前棘手的多密码问题复杂得多，而且浏览器也不能很好地支持选择正确的证书。如果一个用户在很多网站上使用一个证书，那么就会存在隐私问题，因为使用证书可以识别用户。

几十年来，我们很多人都认为最终用户 PK-crypto 的时代即将到来，尤其是像我这样迷恋 RSA 之美的人。事实证明，它的发展方式、服务台和开发成本以及现实世界 PKI 的微妙和复杂性以及法律纠葛不断吞噬着好处。

设备似乎比钻头更贵，但如果钻头不能完成工作，或者有效使用它们会消耗生产力，则不会。

我为少数网站使用浏览器证书，但正如您所说，大多数不是公共网站。

客户端证书的主要困难在于分发它们。也就是说，如果我不认识你，我怎样才能安全地给你“全能”证书，让你可以访问我的系统？
当然，公司系统更容易，对一小部分合作伙伴开放的系统也是如此。但是密钥分配始终是一个难以解决的难题。考虑到私钥方面和证书保护，这比仅在两方之间共享密码要困难得多，...

当然，实际上有解决方案，我什至将一个用于“公共”网站。（它恰好在身份业务中，所以对他们来说是值得的开销......）。该解决方案基于通过密码进行的主要身份验证，在我完全通过身份验证后，我可以选择下载我的证书——假设我知道如何处理它。
也好不到哪里去，因为密码通道仍然打开......但这至少让我有可能将密码更改为不可能和无法使用的东西，并且只有 CSC......

但这并不是微不足道的，而且要正确实施有点复杂。分发仍然会困扰大多数用户。

据我了解，在实践中使用客户端证书存在许多问题。以下是我听到的一些问题：

1. 获取客户证书。用户最初获得客户端证书是一件痛苦的事。显然，网站不希望在用户开始使用他们的网站之前设置不必要的障碍。（即使让站点生成客户端证书并将其提供给客户端也不是用户熟悉的操作——更不用说它存在安全问题，因为理想情况下，只有客户端应该知道客户端的私钥。）现代浏览器提供创建或导入私钥和客户端证书的方法，但用户体验很糟糕。

2. 我听说有些服务器显然不能很好地支持客户端证书（例如，http://osdir.com/ml/encryption.cryptlib/2005-09/msg00000.html）。

3. 流动性是个问题。尽管存在所有问题，但密码非常便携；客户证书不是。即使客户端设法生成私钥并为其获取客户端证书，如果他们想开始使用第二台计算机，他们也必须进行复杂而令人困惑的舞蹈才能将私钥和证书转移到第二台计算机计算机。如果他们的第一台计算机死机（或遭受硬盘故障）并且他们必须重新安装操作系统或购买新计算机，并且如果客户没有备份他们的私钥，他们将无法保存他们的私钥密钥和证书到他们的新计算机上；他们搞砸了。站点可以创建一种备份的身份验证方法，以便丢失私钥的用户可以生成并提交新的私钥，但是这种身份验证的备份方法很容易成为链条中最薄弱的环节。如果您的备份方法很容易被击败，那么您的主要身份验证方法有多强大并不重要。

4. 目前尚不清楚浏览器是否对客户端证书提供足够的支持。我不知道是否所有各种浏览器（包括移动浏览器）都充分支持客户端证书。

5. 无论如何，PKI 模型已经被很好地破坏了。假设是 CA 在向用户提供客户端证书之前会验证用户的身份（例如，他们的真实姓名），并且协议是围绕这个假设设计的。然而，今天的 CA 并没有真正验证身份。这造成了设计假设与现实之间的不匹配。

6. 客户端证书会给用户带来隐私风险。在某些浏览器中，它们可以跨域跟踪用户。（所有浏览器都确保 cookie 仔细防御这种威胁：只有设置 cookie 的域才能读取它。但是，浏览器没有为 SSL 客户端证书提供类似的保护。）我不知道现代浏览器是否有效地解决了这个问题问题，但据我所知，这是一个客户端证书相对不成熟的领域。

7. 如果客户端生成并签署自己的客户端证书，则会出现烦人的技术问题。根据 TLS 协议，服务器应该首先询问它愿意接受的 CA 列表；客户端随后使用该 CA 颁发的客户端证书（如果有）进行响应。（请注意，这发生在客户端发送 HTTP 请求、任何 HTTP cookie、用户名或任何其他识别信息之前。）这意味着，如果您想使用客户端颁发的（自签名）客户端证书，那么服务器必须在客户端验证或识别自己之前知道客户端正在使用的 CA 的名称。这很棘手。

8. 最后，馅饼上的樱桃：客户端证书不能解决网络钓鱼问题。它们可以防止客户的私钥被盗，但不能防止其他个人信息被盗。坏人仍然可以建立一个虚假的银行网站（丢弃发送给它的任何客户证书）。网络钓鱼站点不会获知用户的私钥，但如果用户认为他们已经连接到真实的银行站点，他们可能会输入他们的银行帐号、SSN、PIN 等，从而将这些信息泄露给攻击者。

所有这些都转化为较差的可用性和增加的支持成本（例如，帮助台呼叫）。简而言之，您可以使用客户端证书，至少在原则上是这样；只是，在实践中，这样做对每个人来说都不方便，而且可用性很差。

更根本的是，有一个先有鸡还是先有蛋的问题：在许多网站开始使用客户端证书之前，浏览器制造商不会高度重视使客户端证书可用；在浏览器使客户端证书可用之前，网站不会采用它们。换句话说，如果我们想使用客户端证书来解决一般的身份验证问题，我们既要说服所有浏览器制造商对浏览器进行重大更改，又要说服网站采用新技术。在所有这些各方做出协调的改变之前，任何人都不会受益。这是采用的一个巨大障碍。

Web 上的安全身份验证有更好的解决方案，包括 HTTPS、安全持久 cookie 和基于电子邮件的恢复。但是，这超出了您的问题范围。

最后评论：安全 Web 身份验证的基本挑战是可用性、可用性、可用性。使系统对用户运行良好——并且在普通用户可能使用它们时是安全的——是非常具有挑战性的，这才是最重要的。加密只是这个问题的一小部分。

我认为主要是它们没有被使用，因为普通人（即，不是你，因为你问这个问题）无法理解它们的用法。有一些商业网站使用它们，但它们通常用于非常特殊的目的或用于自动化。例如，Oracle 使用客户端证书来验证最终用户是否具有有效的软件包更新支持合同。但即使是技术含量高的用户获得正确的密钥交换也可能具有挑战性。

话虽如此，我使用客户端证书来保护我向公众开放的部分网站，我认为它们很棒。