从高层次的角度来看，必须发生三件事：

1. 客户端必须证明它是客户端证书的正确所有者。Web 服务器要求客户端使用其私钥签署某些内容，并且 Web 服务器使用证书中的公钥验证响应。

2. 证书必须根据其签名机构进行验证 这是通过使用签名机构的公钥验证证书上的签名来完成的。此外，还会检查证书吊销列表 (CRL) 以确保证书未被列入黑名单。

3. 证书必须包含将其指定为 Web 服务的有效用户的信息。Web 服务器被配置为查看证书中的特定项目（通常是主题字段）并且只允许某些值。

该标准称为“X.509”，最出名的是其化身为“Internet X.509 公钥基础设施证书和证书撤销列表 (CRL) 配置文件”，更广为人知的是RFC 5280。完整的、标准的证书验证算法在第 6 节的（痛苦的）全部细节中列出。

在您至少阅读过该文档一次之前，您不能期望认真理解 X.509 的工作原理。它会让您感到困惑，但那是因为证书和 PKI 本质上是一个复杂的问题，它需要非常精确的概念来了解什么是身份、身份验证、私钥和信任。X.509 试图预先解决这种复杂性，从而产生了类似 Behemoth 的标准，如 RFC 5280。

将私钥标记为“不可导出”只是一厢情愿；它使非技术用户实际导出他们的密钥稍微困难一些。一个更好的答案是它应该不重要。用户通过展示他对与其证书关联的私钥的控制来验证自己。如果用户想将他的私钥存储在其他地方，那是他的事；就像你把门钥匙放在左裤袋还是右裤袋都没有关系一样。同样，如果您将门钥匙留在门垫下，而某个狡猾的人从那里抓起它，那么您的安全性就会消失，但您的保险公司会指出这是您的错。

证书可以包含各种参数，这些参数可以用来限制证书的使用。例如，可以使用应用程序名称和用户名颁发证书，因此应用程序可以确认证书对特定应用程序有效，然后执行标准 x.509 证书验证，然后将可接受的用户凭据限制为个人的凭据证书发给谁。

这是对客户端证书的稳健利用，它要求发布应用程序的公司指定和/或控制证书的颁发，并且基于证书的身份验证在验证用户凭据的同一架构层终止或传递. [换句话说，SSL/TLS 集中器可能会导致问题。]

注意：证书中的附加字段受到加密保护，因此虽然可见，但在不破坏证书有效性的情况下无法更改它们。因此，不能比欺骗整个证书更容易欺骗包含这些参数。

参考

• 一个直接相关的问题——在 X.509 证书中添加自定义数据
• 微软指南——http:
  //msdn.microsoft.com/en-us/library/ms731899 (v=vs.110).aspx
• 维基百科文章 ——http: //en.wikipedia.org/wiki/X.509#Structure_of_a_certificate

首先，我真的认为您需要确定私钥认证到底发生了什么：

1. 私钥：这是您必须保密的东西，仅供您看到。
2. 公钥：这是用户将使用的东西，以便他们可以与您联系（就像您使用的语言只有私钥所有者知道）。
3. 证书：这是一种验证公钥它实际上是与私钥所有者相关联的东西。

因此，请考虑证书是公开的，您可以放弃而不必担心。

证书如何运作？让我简单地说：在颁发公钥时，CA 会在证书上添加一个“秘密标记”，所以当您想要验证它时，您必须将证书从所有者发送给 CA，以便它可以检查是否“秘密部分”没问题。如果 CA 检查秘密部分并且是一致的，它会给你“OK”以使用公钥，如果不是，你应该怀疑使用它。

考虑看看这个维基媒体图，这样你就可以了解创建和验证的整个过程（包括 CA）：

http://upload.wikimedia.org/wikipedia/commons/9/96/Usage-of-Digital-Certificate.svg

这个其他图表也可能有用：

http://blog.securism.com/wordpress/wp-content/uploads/2009/01/pki-simple-diag.jpeg

此外，考虑到 CA 通常是知名的受信任机构，通常浏览器会包含它们的列表。但是一些实体（通常是公共机构或组织）使用他们自己的 CA，您必须手动将其添加到列表中（请对此非常谨慎，因为恶意 CA 可能会真正破坏您的通信）。

希望这对您有所帮助。

（请随意添加任何语法/句法更正，因为英语不是我的母语）。