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

Question

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

• 服务器生成密钥库和信任库.该密钥库被用于存储服务器的证书和私钥.该信任存储用于存储(从证书机构(CA)或受信任的客户端证书的证书)其它凭证.

• 一个企业社会责任是提高了,然后传递给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流程：（来源）

\n\n

\n

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

\n

\n\n

\n\n

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

\n\n

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

\n\n

你的第四个问题（这个过程是否真正验证了客户端的身份）：是的！正如您在第二个问题的答案中看到的，证书是通过检查签名来验证的。签名是完整证书的哈希值。标准X.509包含识别主题的信息。通过检查签名，主体得到验证。标准X.509证书包含以下信息：\n主题名称、主题公钥信息、公钥算法、发行者唯一标识符（可选）、...

\n\n

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

\n\n

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

\n\n

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

\n\n

\n
• 证书和最终吊销由CA
\n
• 该证书对公众的每个信赖方均有效CA，例如 Verisign
\n
• 大多数公众CA都提供创建证书的标准化方法
\n

\n