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

Question

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

• 服务器生成密钥库和信任 库 。 密钥库用于存储服务器的证书和私钥。 用于存储（从证书机构（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流程:( 来源 ）

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

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

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

您的第四个问题（ 此过程是否实际验证了客户端 ）：是的！ 正如您在第二个问题的答案中所看到的，通过检查签名来验证证书。 签名是完整证书的哈希。 标准X.509包含识别主题的信息。 通过检查签名，主体被认证。 标准X.509证书包含例如此信息： 主题名称，主题公钥信息，公钥算法，发行者唯一标识符（可选），...

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

您的第六个问题（ 如果客户端证书由于某种原因而受到损害，只需将其从服务器的信任库中删除即可管理？ ）：因此， CA使用所谓的revocation lists 。 如果您使用的是自签名证书，那么从服务器信任库中删除受损的证书条目也是可以的。

您的第七个问题（ 在我使用可信CA的情况下是否有优势，例如verisign通过自签名证书生成客户端证书？ ）：使用CA签名证书而不是自签名证书存在一些优势。

• 证书和最终的撤销由CA管理
• 该证书对公共CA每个依赖方都有效，例如Verisign
• 大多数公共CA都提供了创建证书的标准方法