SSL证书（CA）的具体客户端验证流程是怎样的？

前置基础认知 #

非对称加密体系有两类核心使用场景，你对公钥可用于解密签名的认知是完全正确的：

• 加密传输场景：公钥加密内容，只有对应私钥可解密，保障数据传输私密性
• 数字签名场景：私钥对信息哈希值做签名（可理解为私钥加密哈希值），公钥可解密签名得到原始哈希值，用于验证信息来源合法性、未被篡改

补充说明：你最初提到的「服务器证书用于匹配浏览器缓存的已安装证书条目」认知存在偏差：客户端不会提前缓存所有站点的服务器证书，匹配的是证书链上层的CA证书，最终追溯到本地预存的信任根证书。

完整校验分步流程 #

步骤1：获取并解析服务器下发的证书链 #

TLS握手阶段服务器会下发完整的证书链，结构为终端实体证书（服务器证书）→ 1~N级中间CA证书，根证书通常不会下发，因为所有正规CA的根证书都会预存在操作系统、浏览器的信任根列表中。
单份证书的核心结构可简化为两部分：

• 明文主体信息：包含绑定域名、有效期、服务器公钥、证书颁发者信息、证书用途等
• 数字签名：颁发该证书的CA用自身私钥，对证书明文主体信息的哈希值做签名得到的内容

步骤2：构建完整信任链 #

客户端从最末端的服务器证书开始，向上追溯构建完整信任链：

• 读取当前证书的颁发者字段，匹配上级CA证书的主体字段，匹配成功就将上级证书加入信任链
• 重复追溯过程，直到匹配到客户端本地预存的信任根CA证书为止
• 若追溯过程中找不到匹配的上级证书，直接判定证书无效，返回不安全提示

步骤3：逐层验签 #

从根证书开始，由上到下逐层校验每一层证书的签名合法性：

• 取上级CA证书的公钥，对下级证书的数字签名做验签操作：即用公钥解密签名得到CA签名时生成的明文哈希值，同时客户端自行对下级证书的明文主体信息做相同算法的哈希计算
• 对比两个哈希值，完全一致则该层证书未被篡改，验签通过
• 任意一层验签失败，直接判定整个证书链无效

步骤4：附加规则校验 #

所有层签名校验通过后，还要完成最后几项规则校验，全部通过才判定证书合法：

• 服务器证书的使用者可选名称（SAN）或通用名称（CN）与当前访问的域名完全匹配
• 证书链中所有证书都在有效期内，且未被CA吊销（通过CRL或OCSP协议查询吊销状态）
• 证书用途字段包含「TLS Web服务器认证」权限，未被限制使用场景

补充疑问解答 #

你提到的伪造证书场景：修改证书内容、用自行生成的私钥签名、替换证书公钥的操作，会在构建信任链阶段就被拦截：
你修改后的服务器证书的颁发者为你自行虚构的CA，普通用户的设备本地没有预存你自制CA的根证书，无法构建出完整的、最终指向信任根的证书链，会直接被判定为无效证书。只有当用户手动将你的自制根证书加入本地信任根列表时，才会通过校验，这种情况通常只存在于开发测试场景，普通用户的设备不会信任你自行生成的CA。

内容的提问来源于stack exchange，提问作者hayatisevenbirisi