图 1：本文封面，点明「信任沿证书链逐级传递」这条主线。
面试里被问「HTTP 和 HTTPS 有什么区别」，多数人能答出加密、端口、TLS 握手。但只要追问一句「浏览器凭什么相信这张证书」，能讲清楚的人就少了一大半。这篇文章不重复握手流程，专讲 HTTPS 背后的信任体系：CA 是什么、证书链怎么校验、自签名证书为什么被警告，以及抓包工具为什么能看到你的加密流量。
核心结论一句话
HTTPS 的信任不是来自某张证书本身，而是来自一条逐级签名的链：你的系统预置了一批根 CA，根 CA 给中间 CA 签名，中间 CA 给网站签名——信任从根开始，沿链条一级级传下来。
第一层：CA 与信任层级
CA（证书颁发机构）的工作是一手验证身份、一手签发证书：网站运营者向 CA 证明「这个域名归我管」，CA 用自己的私钥在证书上签名。为什么不直接让根 CA 给所有网站签？因为根私钥是整个体系的命根子，要离线冷藏、尽量少用。于是有了中间 CA：根 CA 只给少数中间 CA 签名授权，日常的站点证书由中间 CA 签发。根私钥即使长期不出保险柜，体系也照常运转。
第二层：证书链校验的四步
浏览器收到服务器发来的证书链后，做的不是「看一眼是不是知名 CA」，而是一套完整的校验流程。按 RFC 5280 第 6 节的路径校验算法，核心动作可以概括为四步：
一，验签名。用上级证书的公钥验证本级证书的签名，从站点证书一路验到根，链上任何一环签名对不上，立刻拒信。二，查有效期。链上每张证书都有起止时间，过期或未生效都不行。三，对域名。证书里登记的域名要和正在访问的域名匹配，拿别家证书冒充是不行的。四，看吊销状态。证书可能因私钥泄露等原因被提前作废，浏览器可通过 CRL 列表或 OCSP 在线查询确认它没被吊销。四步全过，才开始建立加密连接。
第三层：自签名证书为什么被拦
自签名证书是「自己给自己作证」——签名者和证书主体是同一个，链条不连向任何系统信任的根。它并非不能用：内部测试环境、企业内网把自签的根证书装进信任库，一样能正常建立 HTTPS。它的问题是浏览器无从分辨「这是你自己搭的测试站」还是「中间人伪造的站点」，所以只能给出警告，把决定权交回给用户。
第四层：抓包工具为什么能看明文
理解了信任链，抓包原理就一句话讲清了：它是一次你亲手批准的中间人攻击。抓包代理在本机安装自己的根证书进信任库，之后你访问任何站点，代理都即时伪造一张该站点的「替身证书」签给你。浏览器验链时一路验到代理的根——这个根是你自己亲手信任的，所以四步全过。浏览器以为在跟真实网站加密通信，实际加密终点是代理；代理解密看清内容后，再用真实站点的证书加密转发。两端的加密都是真的，但中间的代理两头都能看到明文。
这也是为什么绝不能随便安装来路不明的根证书：装进去的那一刻，等于把「识别一切网站真伪」的权力交了出去。
图 2：信任层级、四步校验与抓包代理的中间人原理。
两个常见误区
误区一：以为 HTTPS 加密的是证书。证书在握手里是明文传输的，它管的是「对方是谁」的身份认证；加密通信的密钥是握手过程中协商出来的。想看证书链长什么样，一条命令就够：openssl s_client -connect 域名:443 -showcerts，服务器发来的每一级证书都列得清清楚楚。
误区二：以为装了证书就绝对安全。证书体系防的是「你没批准过的中间人」，防不了你亲手信任的代理，也防不了 CA 本身作恶或私钥泄露——所以才有证书透明度日志这类让签发记录公开可查的配套机制。
给你的行动建议
下次部署 HTTPS 时做两个练习：用上面那条 openssl 命令看看你站点的证书链有几级、签发者是谁；再用抓包工具代理一次自己的请求，亲眼看看「信任代理根证书」之后明文是如何暴露的。亲手验证过一次，信任体系就从抽象概念变成了直觉。
你排查过证书相关的线上问题吗？是过期、域名不匹配还是链不完整？欢迎分享你的踩坑经历。