security - 相互认证 - 设置、流程、验证

标签 security spring-boot spring-security https mutual-authentication

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

  • 服务器生成 keystore 信任库 keystore 用于存储服务器的证书和私钥。用于存储其他凭据(来自证书颁发机构 (CA) 的证书或受信任的客户端证书)的信任库

  • 为服务器提出CSR,然后将其传递给 CA。 CA 从 CSR 生成签名证书。这是安装在服务器 keystore 中的。

  • 客户端(拥有自己的 keystore 和信任库)向服务器提供其公钥。然后将其安装在服务器信任库中。

当客户端向服务器发出 https 请求时:

  1. 客户端发出访问 protected 资源的请求。
  2. 服务器使用其公共(public)证书进行响应。
  3. 客户端验证该证书(在信任库中查找并检查它是否由受信任的 CA 签名)。
  4. 客户端向服务器出示其公共(public)证书。
  5. 然后,服务器根据其信任库验证证书。
  6. 假设验证成功,客户端被授予对 protected 资源的访问权限。

所以我有一些事情有点困惑......

  • 上述步骤大体上正确吗?
  • 服务器如何验证客户端证书? (我认为它会查看该证书的信任库,但不确定之后实际发生的情况)。
  • 我见过在服务器信任库中安装 CA 证书而不是实际客户端的公共(public)证书的示例 ~ 是否存在应该或不应该这样做的用例?对于我的用例,我已获得客户端(第三方)签名的证书。签署该证书的 CA 与签署服务器证书的 CA 不同。
  • 此过程是否真正对客户端进行身份验证,即该客户端现在可以访问服务器 protected 资源,但另一个可能提供不同证书的客户端将无法访问? (例如提供用户名和密码的更安全的方法)
  • 通用名称 (CN) 检查在哪里发挥作用?我注意到,在 Spring Boot X.509 中,您可以从 CN 派生用户名,然后使用它从用户详细信息服务中查找适当的用户详细信息。
  • 如果客户端证书由于某种原因遭到泄露,是否可以通过将其从服务器的信任库中删除来进行管理?
  • 在我使用受信任的 CA(例如,CA)的场景中是否有优势? verisign 通过自签名证书生成客户端证书?即证书直接从受信任的第三方传递给我,然后安装。

最佳答案

关于您的第一问题,是的,您概述的步骤是正确的!以下是带有图形概述的常规 mutualSSL 流程:( source )

  1. A client requests access to a protected resource.
  2. The server presents its certificate to the client.
  3. The client verifies the server’s certificate.
  4. If successful, the client sends its certificate to the server.
  5. The server verifies the client’s credentials.
  6. If successful, the server grants access to the protected resource requested by the client.

mutual SSL flow

您的第二问题(服务器如何验证客户端证书?): 服务器借助签名验证客户端证书。签名通常是哈希值,是完整证书的构建。哈希值使用相应CA(证书颁发机构)的私钥进行签名。服务器借助CA的公共(public)证书验证客户端证书的签名。

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

您的第四问题(此过程是否真正对客户端进行身份验证):是的!正如您在第二个问题的答案中看到的,证书是通过检查签名来验证的。签名是完整证书的哈希值。标准X.509包含识别主题的信息。通过检查签名,主体得到验证。标准 X.509 证书包含以下内容:此信息: 主题名称、主题公钥信息、公钥算法、发行者唯一标识符(可选)...

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

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

您的第七问题(在我使用可信 CA(例如威瑞信)生成客户端证书而不是自签名证书的情况下,是否有优势?):使用 CA 签名证书而不是自签名证书有一些优点。

  • 证书和最终吊销由CA管理
  • 该证书对公共(public) CA 的每个依赖方均有效,例如威瑞信
  • 大多数公共(public)CA提供创建证书的标准化方法

关于security - 相互认证 - 设置、流程、验证,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52798697/

相关文章:

spring - 为什么我的集成测试提示 Spring Boot 中缺少 RestTemplate 接线?

Spring Rest请求方法 'GET '不支持

mysql - spring jpa application.properties useSSL

grails - 如何将LDAP用户与Spring Security在Grails中创建的PERSON表集成在一起?

PHP make 文件仅在代码中可用

php - Symfony2 获取位于 security.yml 中的 access_control 参数

azure - 在 Azure Function App 前面使用 Web 应用程序防火墙

php - 加密 MySQL 表中数据的好方法?

java - Spring security BASIC 身份验证在 Weblogic 上提示两次输入用户名/密码

java - 登录/使用 Api 与 Spring Security 基本身份验证不起作用