我喜欢 this.josh 的答案，但我想补充几点：

• TLS 不使用证书来保护通道 - 这是通过协商的对称密钥完成的。TLS 使用证书（服务器或客户端）身份验证和密钥加密。
• 我同意用于加密的证书不应与用于身份验证的证书相同 - 但是，在这种情况下，我认为可以肯定地说用于 TLS 的证书用于身份验证，而不是加密。确实，如果您深入研究它，就会对证书进行密钥加密，而且我敢肯定，如果您获得高端系统，最终会遇到不同意我的人，但似乎就像在许多用例中通过 TLS 之上的质询/响应协议一样矫枉过正。
• 暗示在前面的答案中，但我会说它是空白的 - 默认情况下，TLS 通常只是服务器身份验证。要获得客户端身份验证，您需要为此打开一个开关，并在此过程中指定：
  • 客户端身份验证可以使用哪些凭据 - 例如数字证书。
  • 如何检查凭证 - 例如，根据签署证书的受信任证书颁发机构进行验证，并根据 OCSP 或 CRL 源验证证书状态 - 这是 PKI 的一个完整领域，我想如果你深入了解这个Stack Exchange 你会发现更多关于这个。

通常，检查客户端和服务器上提供的证书的所有因素是确保连接到该通道的实体是它所说的实体的最佳途径。典型的机制包括：

• 受信任的签署者- 证书通常由证书颁发机构 (CA) 签署。该证书颁发机构被信任在证书颁发之前验证请求者。大多数具有广泛分布的信任需求的系统都信任一组 CA 来颁发凭据。他们通过保留一组 CA 证书来做到这一点，这样当最终实体出现带有受信任的 CA 签名证书时，他们可以检查是否有一个已批准（已知）的 CA 签署了证书。
• 状态- 当 CA 签署证书时，它还负责使状态保持最新 - 它通过发布 CRL（证书撤销列表）来做到这一点，该 CRL 可能会或可能不会通过 OCSP（请求/响应协议）快速呈现查询。然后端点在收到证书时验证证书的状态，以确保证书根据其颁发的 CA 仍然有效。
• 自签名证书- 如果证书不是由 CA 签名的，则它是自签名的。这是一种超级便宜的方法，但它使配置成为一种负担。自签名证书声称自己的优点，因此验证它的一方（应用程序）必须通过手头保存每个证书的副本来单独手动信任每个自签名证书。便宜，如果你有一个非常小的安装就足够了，但它的扩展性非常小。
• 有效性- 在所有情况下，证书从开始日期到结束日期都是有效的，应进行审查以确保当前有效性。

认证与授权

身份验证- 是它所说的实体吗？只要证书是有效的身份证明，情况就是如此。即使我 16 岁，我的驾照只要是由我的居住州正确签发的，就仍然有效。然而，这并不意味着我有权购买酒类（如果我住在美国，至少我必须年满 21 岁）。

授权是允许实体做它想做的事吗？如果我超过 21 岁，我有权购买酒类。从技术上讲，我只需要超过 21 岁，但我通过身份验证来证明这一点——我的驾照或护照或州签发的身份证。

听起来你两个都想要。您希望每一方都证明其身份（身份验证）并属于某个受限组（由您的公司创建）。因此，您需要的不仅仅是 TLS 客户端身份验证 - 您还需要一些额外的检查标准来验证授权。

我可以想到几种方法来解决这个问题：

• 设置受信任的用户列表 - 使用 PKI，典型的方法是为每个客户端或服务器列出主题 DN（可分辨名称）。可扩展性与您存储此列表的位置直接相关 - 公共存储 - 像 LDAP 服务器 - 是一个不错的选择，因此所有服务器都可以检查一个公共位置。

• 确保您的证书具有质量 - DN 中的组织值浮现在脑海中 - 它通常是描述实体来自的组织的值。例如，我的个人数字证书将我的公司名称作为“O”值，因为我的公司支付了我的费用来获取它们。然后您可以构建一些添加的代码（或者在非常智能的服务器中，您可以配置它......）以检查“O = your company“ - 你很好 - 只要你能保证没有其他人可以用你的公司名称在“O”值中制作证书。一种方法是一些高端商业证书颁发机构，你可以在其中设置与该 CA 提供商签订协议和帐户，并且您在公司中有指定的批准人来做文书工作。该人证明在 CA 制作证书之前，每个证书请求都来自您的公司。您可以运行你自己的 CA 也是一样——本质上你是在权衡时间和金钱。

警告：我在这里掩盖了很多细节。弄清楚身份验证和授权控制应该是“多么安全”以及应该如何管理它们是一项全职工作。事实上，这是一个完整的行业。我在这里抛出的是基本概念的草根概念。如果你告诉我你正在整合一些东西来保护数百万或数十亿美元的企业投资、人类生命或我们所知道的世界状况——我会告诉你离线联系我，我有一个由聪明人组成的好团队，他们可以帮您解决这个问题……收费。整个区域很快就变成了先有鸡还是先有蛋的场景，因为围绕检查这些东西的每一个沟通和程序都需要小心处理，因为任何系统的强大程度取决于其最薄弱的环节。我在这里提出的假设是你没有什么大的东西，你主要是在一个新的系统上工作，它只需要一点保护——相当于在你的房子周围竖起一扇漂亮的门。不是大门、看门狗、安全摄像头和一个拿着尖刺棍棒的大个子。:)

现在...密钥存储

密钥存储有两个主要元素：

• 它必须有多安全才能免受攻击？
• 它需要如何访问？

“安全”通常在 FIPS 合规级别中进行评级 - 这是一种测试关键存储机制的方式，并且它们满足某些不断升级的安全要求。低端是软件存储 - 密钥使用几种商业支持的存储机制之一，它位于您的硬盘驱动器上（价格 = 免费或硬盘驱动器上一小部分内存的价格）。高端是一个大而昂贵的盒子（HSM - 硬件安全模块），它将以这样一种方式保存您的密钥，以至于没有人可以将密钥从盒子中取出......永远......当他们尝试时，如果他们太努力了，盒子会自动归零，抹掉钥匙。中间有层次。

您想要支付多少安全费用完全是一个风险/成本决定。你必须计算出你必须松动的东西和你想要支付的东西。

“如何访问”有几个要素：

• 软件密钥在盒子上很容易访问 - 有几种商业支持的存储方式，大多数服务器支持大多数存储机制。PKCS12 和 JKS 是两个例子。
• 硬件密钥通常由 PKCS 11 协议访问（但还有其他协议），大多数高端服务器都内置了这个，但有时您需要扩展来处理这个或自定义构建代码的 API。此外，您还有鸡/蛋问题 - 您通常需要密码才能访问您的 HSM - 您存储该密码的位置和方式是另一个安全领域。
• 对于客户，您也有行动不便的问题。如果“客户端”是一个固定点 - 您拥有与服务器相同的硬件/软件选项，但如果“客户端”是指人类，那么您还需要考虑用户移动性和与任何 GUI 机制的兼容性（例如，浏览器）。它仍然归结为 HW/SW，但通常将 HW 元素称为“令牌”，因为可移除性成为关键特性。

在任何情况下，您都可以将您的证书存储在任何地方——它们是可以广泛传播的公共信息。关键元素是您的私钥——它必须存储在只有使用它的实体才能到达的地方。

谁可以使用单一证书

这取决于您存储密钥的方式以及您愿意接受的风险。网络可访问 HSM 上的密钥在技术上可以由一组服务器使用，这将使所有服务器看起来像一个服务器（对于 Web 应用程序来说非常酷）。但是，如果您需要确切证明哪个客户端或服务器执行了特定操作，那么每个实体必须有 1 个证书。此外，您只能撤销证书 - 因此您需要一定程度的分离，如果您认为密钥存储已被泄露，您可以只禁用一件事。

通常，如果您发现自己将私钥放在多个地方，这是一个检查点 - 这是一个严重的风险，也是您想要获得另一个证书的一个很好的指标。从那里开始，IMO 的分离级别主要取决于您想要跟踪的级别以及您对控制访问的任何其他需求。

是的，您可能希望使用传输层安全性 (TLS)来替代安全套接字层 (SSL)，因为它是一种使用良好且经过审查的网络通信安全性。证书部分是一个公钥基础设施，涉及公钥/私钥对和衍生数据的生成、分发、用户和退休。

听起来您正在为仅与经过身份验证的服务器对话的客户端应用程序构建原型。对远程服务器进行身份验证与仅保护通信通道不同。即使您最终使用证书来验证服务器，也不应该使用相同的证书来保护通信通道和验证服务器。

一种认证方法是质询响应协议。常见的质询响应协议是安全远程密码 (SRP)。SRP 可通过多种语言和平台访问。

“每个应用程序都应该有自己的证书吗？” 这取决于您是否需要对每个客户端进行唯一身份验证。如果您决定确实需要唯一身份验证，那么您需要了解密钥的负担。您需要的密钥数量直接与客户端数量成正比。对于十个客户来说，这可能不是一个负担，但对于一万个客户来说却是一个挑战。

你需要回答：

• 谁将生成密钥？
• 谁将签署密钥：您将使用 CA 还是创建自己的 CA？
• 密钥将如何分配？
• 密钥将如何失效？
• 密钥有效期是多久？
• 您将如何处理密钥更新、恢复和替换？

“证书存储在哪里？”

对于大多数操作系统和平台，都内置了密钥存储机制。

• Java 密钥库
• Windows 加密API
• OpenSSL 为您提供 PKCS 11 和 12
• Linux 有 GPG、LUKS、dm-crypt 等。