SSL 证书验证过程

• 服务器在本地生成私钥和公钥对，并创建CSR（证书签名请求）。

• CA 收到 CSR 后进行验证，然后颁发证书。此证书包含服务器的公钥、颁发者信息、公司信息、到期日期和数字签名（即 CA 使用其私钥对证书数据进行加密的哈希值）。

• 客户端已将 CA 的根证书（包括CA 的公钥）预先安装在其受信任的根存储中，作为操作系统/浏览器设置的一部分。

• 客户端访问例如“www.server.com”

• 在 HTTPS 握手过程中，服务器会使用其 SSL 证书进行响应。

• 客户端从其受信任的根存储中获取CA 的公钥，并使用它来解密服务器证书上的数字签名。如果成功，则解密值将存储为hash1。如果解密失败，则该过程在此处停止。

• 客户端使用指定的哈希算法计算收到的证书数据（不包括数字签名）的哈希值。此值存储为hash2。

• 客户端比较hash1和hash2。如果它们相同，则证书通过验证，连接继续。如果它们不同，则终止连接。

多级证书验证怎么样？

它类似于单级证书流程。只是：

• 这次需要验证“证书链”，而不是验证单个证书

• 更高级别的公钥将用于验证较低级别的

• 证书链验证从下向上开始

流程如下：

• 服务器生成三个私钥/公钥对。

• 服务器为每个级别创建 CSR，其中包括公钥和公司信息（与上面类似）。

• CA颁发证书：根CA颁发祖父证书，祖父签署父亲证书，父亲签署孩子证书。

• 客户访问例如“www.grandfather.father.child”

• 在 HTTPS 握手期间，服务器使用证书链（子、父亲、祖父）进行响应。

• 客户端会从本地的可信根中取出存储的公钥，然后进行验证（每一级的哈希比较过程和上面的单级证书过程类似）：

1. 使用父证书的公钥验证子证书。

2. 使用祖父证书的公钥验证父证书。

3. 使用根 CA 的公钥验证祖父证书。

• 完毕。

那么为什么自签名证书不受信任

自签名证书可能适用于调试目的，但它们绝不能用于生产或任何面向公众的登台环境。

1. 缺乏信任：自签名证书不是由受信任的证书颁发机构 (CA) 签名的。在 SSL/TLS 握手期间，客户端尝试使用受信任根存储中的 CA 公钥来验证服务器的证书。对于自签名证书，客户端的受信任根存储中没有相应的公钥。这会导致数字签名解密失败。

2. 验证失败：由于解密失败（如上所示），客户端无法验证证书，导致连接失败。

3. 安全风险：缺乏信任和缺乏第三方验证使得自签名证书不安全并且容易受到中间人攻击（我们将在下一篇文章中更详细地讨论这个问题）。

原文始发于微信公众号（KK安全说）：为什么自签名证书不可信