相互认证-设置，流程，验证

Question

我正在实现单个客户端托管的应用程序（CLIENT）与我的spring boot 2应用程序（SERVER）之间的相互身份验证。我了解以下步骤：

• 服务器会生成一个密钥库和信任库。 密钥库用于存储服务器的证书和私钥。 truststore 用于存储其他凭据（来自证书颁发机构（CA）的证书或受信任的客户端证书）。

• 为服务器引发 CSR ，然后将其传递给CA。 CA从CSR生成签名证书。这是服务器密钥库中安装的。

• 客户端（具有自己的密钥库和信任库）将其公共密钥提供给服务器。然后将其安装在服务器信任库中。

从客户端到服务器发出https请求时：

1. 客户端发出访问受保护资源的请求。
2. 服务器以其公共证书作为响应。
3. 客户端验证该证书（在信任库中查找并检查它是否由受信任的CA签名）。
4. 客户端向服务器出示其公共证书。
5. 然后，服务器根据其信任库验证证书。
6. 假设验证成功的客户端被授予对受保护资源的访问权限。

所以我有些事情让我有些困惑...

• 上面概述的步骤大致正确吗？
• 服务器如何验证客户端证书？ （我认为它会在信任库中查找该证书，但不确定此后实际发生了什么。）
• 我已经看到了将CA证书安装在服务器信任库中而不是实际客户端的公共证书的示例〜是否存在用例何时应该或不应该这样做？对于我的用例，已经向我提供了来自客户端（第三方）的签名证书。签名的CA与签署服务器证书的CA不同。
• 此过程是否确实对客户端进行身份验证，即该客户端现在可以访问服务器保护的资源，但是可能出示其他证书的另一个客户端将没有访问权限？ （例如提供用户名和密码的更安全的方法）
• 所有这些通用名称（CN）检查在哪里？我注意到在Spring Boot X.509中，您可以从CN派生一个用户名，然后使用它从用户详细信息服务中查找适当的用户详细信息。
• 如果出于任何原因破坏了客户端证书，只需将其从服务器的信任库中删除即可管理该证书？
• 在使用受信任的CA的情况下，有一个优势，例如verisign可以通过自签名证书生成客户证书？即证书是直接从受信任的第三方传递给我的，然后安装。

Answer 1

关于您的第一个问题，是的，您所概述的步骤是正确的！以下是带有图形概述的常规mutualSSL流：（source）

  

  
1. 客户端请求访问受保护的资源。
  
2. 服务器将其证书提供给客户端。
  
3. 客户端验证服务器的证书。
  
4. 如果成功，则客户端将其证书发送到服务器。
  
5. 服务器验证客户端的凭据。
  
6. 如果成功，则服务器将授予对客户端请求的受保护资源的访问权限。
  

您的第二问题（服务器如何验证客户端证书？）： 服务器在签名的帮助下验证客户端证书。签名通常是完整证书的哈希值。哈希值使用相应的CA（证书颁发机构）的私钥签名。服务器借助CA的公共证书来验证客户端证书的签名。

您的第三问题（服务器信任库，其中包含客户端的公钥/证书或相应的CA证书？）： 如果使用例如自签名证书，则可能必须将客户端的公钥/证书直接导入到服务器信任库中。如果您的客户端使用CA签名证书，则服务器只存储CA公钥/证书，因为它用于验证客户端证书。

您的第四个问题（此过程是否确实对客户端进行身份验证）：是的！正如您在第二个问题的答案中看到的那样，通过检查签名来验证证书。签名是完整证书上的哈希。标准X.509包含用于标识主题的信息。通过检查签名，可以验证主题。标准X.509证书除其他外还包含例如这个信息： 主题名称，主题公共密钥信息，公共密钥算法，颁发者唯一标识符（可选），...

您的第五问题（ CN检查在哪里？）：在证书检查期间执行CN（通用名）验证。 CN标识当前证书的有效主机名。它仅限于一个条目。作为扩展，引入了SAN（主题备用名称）。证书可以包含多个SAN。 CN（和SAN）条目是证书的一部分，并在证书签名检查的帮助下进行了验证。

您的第六个问题（如果仅出于从服务器信任库中删除客户端证书的原因而对客户端证书造成了损害？）：因此，{{1} }使用所谓的revocation lists。例如，如果您使用的是自签名证书，也可以只从服务器信任库中删除受感染的证书条目。

您的第七问题（在使用受信任的CA的情况下（例如，verisign相比自签名证书产生客户证书有优势吗？）：使用CA签名证书而不是自签名证书存在一些优点。

• 证书和最终的撤销由CA
管理
• 该证书对公众CA的每个依赖方均有效，例如威瑞信（Verisign）
• 大多数公众CA提供了创建证书的标准化方法