部署客户端证书可能适合这里。使用证书而不是用户名的优点有点简单。任何人都可以从任何客户端设备输入用户名。如果您使用用户名与 guid 的组合，则客户端从已知/授权客户端设备连接的“安全性”或保证取决于 guid 的强度和唯一性。如果有办法克隆或欺骗 guid（mac 地址可以很容易地被欺骗），那么保证级别就会降低。

客户端证书可以部署到客户端，有或没有有效性检查（除了有效性日期、cn、ski/aki、指纹等）。每次客户端连接/尝试进行身份验证时，诸如 ocsp 之类的按需有效性检查机制将要求服务器应用程序与 ocsp 服务器进行检查。但是从描述中，我没有读到有效性检查与能够将证书绑定到客户端设备一样重要。

客户端证书（一般证书）的一个重要细节是可以导出，并且大多数实现不会锁定证书的可移植性。无论是否或如何存储客户端证书，如果没有适当的措施，证书都可以轻松地从设备复制到设备。一些实现将证书存储在文件系统上（以 .cer、.der、.key、.crt 结尾的文件通常表明证书存储在文件系统中）。更强的实现（依赖于应用程序）可以将证书和密钥存储在密钥库（即 java 密钥库）中。密钥存储可以添加额外的保护，例如确保私钥不可导出。但是，密钥未导出的保证仅与密钥存储本身一样强大。硬件密钥存储（即智能卡、usb hsm、ironkey、

顺便说一句，以上几点也会影响服务器密钥。大多数实现将私钥存储在软件密钥存储中，并且通常标记为可导出。此外，私钥通常不受密码保护，因此任何有权访问服务器的人都可以带着私钥离开。如果可以复制证书，则它不提供不可否认性。

要回答您的问题，如果有一种利用各种硬件 ID（guid、序列号、存储在 HSM 中的证书等）的好方法，那么这可能比使用基于软件的 ID（包括客户端证书）提供更多的保证. 使用为私钥访问启用密码保护的客户端证书提供了更强的验证，因为客户端不仅需要访问私钥，还需要密码才能使用它。

如果您决定使用客户端证书，则必须构建或使用现有的 PKI 基础架构。Codomo、Entrust、Symantec（以前的 vrsn、thawte 和 geotrust）、Godaddy 等供应商提供公共和私人基础设施供使用。然而，实现基于软件的客户端证书的成本可能会高于使用基于软件的硬件 ID 甚至可能是基于硬件的唯一 ID。

如果有的话，请确定您想要的保证级别，并确定软件、软件 + 密码或硬件是否足够。

使用客户端证书身份验证，秘密（私钥）永远不会离开客户端，也不会到达服务器。无论你是否信任服务器（无论如何你都应该先检查一下），你的私钥都不会泄露。与传统的基于表单或 HTTP 基本身份验证相比，这是一个优势。

您甚至可以使用一些硬件加密令牌/智能卡，其设计方式使私钥永远不会离开令牌（TLS 握手中涉及的签名发生在机上）。

如果您在公钥基础设施的上下文中使用客户端证书（很可能），您还可以享受 PKI 提供的好处。这对于大型结构最有用，但您可以：

• 识别您以前从未注册过的用户的身份。

  这就是证书颁发机构的用途。如果您信任 CA，则您信任它颁发的证书。如果未知用户在没有预先存在的帐户的情况下登录到您的系统，并且如果他们提供您信任的证书，您将能够识别他们的身份，正如 CA 所保证的那样。您可能希望也可能不希望从用户那里获得更多详细信息，但主要身份将已向 CA 声明，并且将在那里留下管理痕迹。

• 证书声明的相同身份可用于多个独立网站（前提是它们信任相同的 CA），可能用作单点登录的一种形式。

• CA 可能会直接吊销受损的证书。

• 通过 CA，您可以将证明用户身份的问题与提供服务本身的问题解耦。OpenID 等其他方法也可以实现这一目标，但很难提供与 CA 所能做的相同级别的保证（前提是 CA 正确地完成了他们的工作）。保证级别将根据 CA 的质量而有所不同。

  这样做的一个好处是，您可以使用不同的密钥向同一用户重新颁发新证书（如果以前的证书已过期或私钥已泄露），并在所有信任此证书的系统中保持相同的标识符（主题）加利福尼亚州。

（您也可以在 PKI 的上下文之外使用客户端证书，但您必须定义自己的信任规则，这可能非常繁琐。）

客户端证书也可以独立于在 SSL/TLS 之上运行的协议使用。例如，如果适用，您甚至可以将它们用于 S/MIME。

另一个优点是，因为身份验证不会发生在 HTTP 级别，所以它实际上是无状态的，如果像 REST 架构风格这样的东西对您很重要的话。

一些 Web 服务也可能将其用于消息级别的安全性，从而可能会在必要时为某些消息的不可否认性留下审计跟踪。

主要的缺点是您需要让您的用户了解公钥密码学的基本概念。如果您不使用硬件令牌（而只是将证书和私钥保存在用户的软件中），这一点尤其重要。

• 与密码不同，用户不会记住私钥/证书。他们需要使用安装了证书的机器（或者有适合硬件解决方案的读卡器）。为了偷工减料，有些人可能会不小心照料他们的私钥（他们通常自己受密码保护）。

• 在解释时，“证书”的概念可能会令人困惑。甚至专家有时也会缩短句子。如果您说“使用您的证书登录”，您的实际意思是“使用私钥和您的证书登录”：此表达式中隐含了私钥。相反，如果有人告诉你“把你的证书发给我”，那么你就不应该使用你的私钥。如果您四处寻找文档，您会发现许多对 PKCS#12 文件（.p12或.pfx）和 PEM 证书文件（.pem或.crt，通常是）的引用。通常，前者包含私钥，而第二个不包含（尽管它也可能包含）。所有这些概念都会让用户感到困惑，除非他们知道自己在做什么。

• 浏览器的客户端证书用户界面通常很差。从 UI 的角度来看，退出一个您已经使用客户端证书（例如 HTTP Basic）进行身份验证的网站是非常困难的。（它使 CSRF 保护更加重要。）如果您的客户端是“机器”而不是通过浏览器的用户，那么这不是什么大问题。

在基础架构方面，如果您不愿意为您的客户端证书使用商业 CA 的服务，您将不得不部署自己的 CA。请注意，用于验证客户端的 CA 可以独立于用于验证服务器的 CA。您可以使用由知名 CA 颁发的证书来运行网站，但让它信任来自您自己的 CA 的客户端证书。存在各种用于 CA 管理的工具，包括开源工具。有些甚至可以在浏览器中生成密钥，以便在浏览器中准备好私钥（这样做的缺点是用户必须在证书颁发后重新使用相同的浏览器来导入证书）。

服务器的配置需要对证书（CA证书，服务器证书）有一定的了解，但实际上并没有那么复杂。大多数服务器以一种或另一种方式支持这种方式。

客户端证书只为您提供身份验证。您可能仍需要获取更多属性（例如，从 LDAP 或针对证书主题的数据库）。您当然需要在此之上具有授权逻辑，就像任何其他身份验证系统一样。通常将主题 DN 映射到系统中的本地标识符。

（还有更高级的用法，您可以使用代理证书委托身份验证，或通过属性证书传递授权令牌，但这些更不常见，并非所有软件堆栈都接受。）