一次HTTPS验证从服务器证书开始
服务器证书位于信任链最下方，也叫终端实体证书。它直接绑定网站域名，例如 www.example.com，并包含公钥、有效期、签发者、用途以及主题备用名称等信息。浏览器收到证书后，会先核对访问域名是否出现在证书的主题备用名称中，再检查证书是否过期、签名是否有效，以及用途是否允许服务器身份验证。
域名匹配只能证明“这张证书写了这个域名”，不能证明证书由可信机构签发。浏览器还需要找到签发该服务器证书的CA证书，并验证签名。大多数公开网站不会由根CA直接签发服务器证书，而是通过一个或多个中间CA完成签发。
中间证书把签发工作和根密钥隔离开
中间证书由上级CA签发，并被授权继续签发下级证书。公开CA使用中间证书处理日常签发，可以让根密钥长期离线保存。即使某个中间CA需要停用或替换，也不必同时更换所有设备中的根证书。
网站部署时通常要把服务器证书和必要的中间证书一起发送给客户端。服务器一般不需要发送根证书，因为客户端会从自己的信任库中选择信任锚。RFC5280把信任锚作为路径验证的输入；它可能以自签名根证书的形式存在，但不等同于服务器必须传输的证书链成员。
根证书为什么能够成为信任起点
根证书通常是自签名证书。自签名并不会自动产生信任，真正的信任来自分发过程：操作系统、浏览器或企业管理员把经过审核的根证书放入本地信任库。验证路径最终能够连接到本地认可的根，客户端才会接受这条链。
这也解释了为什么同一个网站可能在一台设备上正常，在另一台旧设备上报错。两台设备的根证书库、更新时间或企业安全策略可能不同。信任链不是服务器单方面宣布有效，而是服务器提供的证书与客户端本地信任策略共同得出的结果。
三类证书各自承担什么任务
| 证书类型 | 主要作用 | 通常由谁提供 |
| 服务器证书 | 证明网站或服务端身份，并提供用于TLS连接的公钥 | 网站服务器发送 |
| 中间证书 | 连接服务器证书与根证书，承担日常签发 | 网站服务器通常需要发送 |
| 根证书 | 作为客户端认可的信任锚 | 操作系统、浏览器或企业信任库提供 |
一条有效路径还要通过哪些检查
链条能够连接起来只是第一步。客户端还会验证每一级证书的签名、有效期、基础约束、密钥用途、名称约束和策略约束，并按照自身策略处理吊销状态。RFC5280要求相邻证书的签发者与主题关系能够衔接，目标证书在验证时间有效，路径最终由信任锚支持。
常见失败并不都发生在同一位置。服务器漏发中间证书时，桌面浏览器可能凭缓存补齐，而新安装的系统、容器或移动设备仍会失败；域名不匹配时，即使证书链完整也不会通过；根证书库过旧时，服务端配置正确也可能无法建立信任。排查时必须把“链不完整”“域名错误”和“客户端不信任根”分开。
如何判断网站是否正确发送了证书链
不要只看浏览器地址栏中的锁形图标。运维人员可以使用 OpenSSL 的 s_client 查看服务器实际发送的证书列表，再用verify 验证服务器证书、中间证书和本地信任库能否组成有效路径。Windows环境还可以使用 certutil 检查证书链和吊销信息。
如果测试显示服务器只发送了终端证书，应在Web服务器或负载均衡设备上配置包含中间证书的完整链文件。根证书一般不应作为服务器链的一部分重复发送。修改后要从未访问过该站点的客户端、容器或独立检测环境再次验证，避免浏览器缓存掩盖问题。
信任链的核心不是证书数量
一条链不一定固定为三张证书。某些部署只有一个中间CA，另一些可能涉及交叉签发或更长路径。判断标准不是“是否凑齐三张”，而是客户端能否从目标证书构建一条符合策略、最终抵达受信任锚的有效路径。理解这一点，才不会把根证书、中间证书和服务器证书混为一谈。