当你访问一个HTTPS网站时，浏览器和服务器之间会进行一场“加密握手”，其中最关键的一环就是SSL/TLS证书的传递。但很多人会疑惑：服务器返回的究竟是单个证书还是一串证书链（Certificate Chain）？这背后关系到网站的身份验证和信任建立。本文用通俗易懂的例子，带你彻底搞懂这个过程。

一、SSL/TLS握手时，服务器返回的是什么？

答案是：服务器通常会返回完整的证书链（除了根证书）。

举个例子：假设你访问`https://www.example.com`，服务器的证书由中间CA（如DigiCert）签发，而DigiCert的权威又来自根CA（如DigiCert Global Root CA）。在握手时，服务器会按顺序发送：

1. 站点证书（`www.example.com`）

2. 中间CA证书（DigiCert SHA2 Secure Server CA）

3. 但不会发送根证书（因为根证书已预装在浏览器/操作系统中）。

这就是一个典型的证书链结构：

```

站点证书 → 中间CA证书 → 根CA证书（预装）

二、为什么需要返回证书链？

如果只返回站点证书，浏览器会遇到一个大问题：“我该相信谁？”

想象一个现实场景：有人递给你一张身份证，自称是“张三”，但你怎么确认这张身份证是真的？你需要知道发证机构（比如公安局）是否可信。同理：

- 站点证书相当于“身份证”；

- 中间CA和根CA相当于“公安局”及其上级单位；

- 浏览器预装的根CA列表相当于“你信任的官方机构名册”。

只有完整的链条才能让浏览器验证：

1. 站点证书是否由中间CA签发？

2. 中间CA是否被根CA信任？

3. 根CA是否在浏览器的可信列表中？

如果链条断裂（比如缺少中间CA），浏览器会弹出警告：“此网站的证书不受信任”（如下图）。

 *（示意图：实际警告可能因浏览器而异）*

三、技术细节：如何验证证书链？

以OpenSSL命令为例，你可以手动查看一个网站的完整链条：

```bash

openssl s_client -showcerts -connect www.example.com:443

输出会显示服务器返回的所有证书（通常包含站点和中间CA）。

验证的关键步骤：

1. 签名匹配：用上级CA的公钥验证下级证书的签名（比如用中间CA的公钥解密站点证书的签名）。

2. 有效期检查：所有证书必须在有效期内。

3. 用途检查：比如中间CA必须具有“签发下级证书”的权限。

四、常见问题与案例分析

? 问题1：为什么有些网站只返回单个证书？

可能是管理员配置错误。例如Nginx中若未设置`ssl_trusted_certificate`指令，可能只发送站点证书。此时用户需手动下载中间CA安装到本地。

? 正确配置示例（Nginx）：

```nginx

ssl_certificate /path/to/site_cert_and_intermediate.crt;

合并站点+中间CA

ssl_certificate_key /path/to/private.key;

?案例：Let’s Encrypt的兼容性问题

Let’s Encrypt的旧中间CA（DST Root CA X3）曾在部分旧设备上因缺失根库导致警告。解决方案是服务器同时发送新旧两条链条——这就是著名的“交叉签名”技术。

五、与最佳实践

- ? 服务器应始终返回完整的证书链（至少包含站点+中间CA）。

- ? 使用工具检测链条完整性（如[SSL Labs测试](https://www.ssllabs.com/ssltest/)）。

- ? 避免自签名或过期链引发安全警告。

理解SSL/TLS的链条机制，不仅能帮你排查HTTPS问题，还能更深入地把握网络安全的基础逻辑。下次看到浏览器的“小绿锁”，你会知道它背后是一整套精密的信任体系！

TAG:ssl返回的是证书还是证书链,ssl证书工作原理,ssl_get_error返回5,ssl_connect返回值,ssl证书的正确说法,ssl_accept 返回-1