2.2 证书安装与HTTPS解密

2.2 证书安装与HTTPS解密

本节摘要：HTTPS 流量要被代理看见，靠的是一次受控的中间人：Burp 为每个站点现场签发证书，浏览器只要信任了 Burp 的根证书，就接受这些现场证书。本节讲清这条信任链怎么成立，并给出一套覆盖常见故障的排错顺序——从"历史无记录"到"证书告警"到"部分站点抓不到"。

加密隧道里的中间人

上一节讲过，代理看见明文的前提是客户端把请求交给它。HTTP 流量天然如此，HTTPS 则多一层障碍：浏览器要与目标站点协商加密，代理若只是转发密文，依旧什么都看不见。Burp 的解法是把一次 TLS 会话拆成两段——对浏览器这一段，Burp 冒充目标站点；对目标站点那一段，Burp 冒充浏览器。两段各自独立加密，Burp 在中间持有全貌。

冒充能成立，依赖证书体系的信任规则：浏览器只接受"受信任的签发者"给出的站点证书。Burp 安装时自带一个本地根证书，它现场为靶场站点签发的证书都由这个根签署。你把 Burp 根证书导入系统或浏览器的受信任区，浏览器就会把 Burp 现场签的证书当成合法站点证书——信任链被整体替换成了以 Burp 根为顶点的一条新链。

图：信任链的替换

动手：装证书，看明文

操作顺序固定三步。第一，代理开着的状态下用浏览器访问代理监听地址，页面提供根证书下载，按 DER 格式保存；第二，把证书导入受信任区——Windows 导入"受信任的根证书颁发机构"，macOS 加入钥匙串并手动设定为信任，浏览器若用独立配置文件则在浏览器设置里单独导入；第三，访问任意 HTTPS 站点，历史记录里出现完整明文请求即成功。

解密生效后值得看一眼的一手样本：一个普通登录请求在历史里的样子。

POST /login.php HTTP/1.1
Host: lab.local:8088
Cookie: PHPSESSID=labdemo0001
Content-Type: application/x-www-form-urlencoded

username=admin&password=labpass
​

HTTPS 站点的同类请求形态完全一致——解密之后，加密流量与明文流量在工具眼里没有区别，后续章节的一切操作对两者通用。

排错实录：按顺序查，不要跳

故障排查最忌乱试。下面这个顺序覆盖了绝大多数抓不到包的场景，每一步都有明确的判据。

第一步：历史里有没有任何记录。 一条记录都没有，问题在链路而不在证书——检查浏览器代理配置是否指向了监听器实际的地址与端口，浏览器是否启用了与代理设置冲突的其他网络扩展。练习环境最常见的是配置文件搞混：日常配置文件没设代理，练习配置文件设了但开错了窗口。

第二步：HTTP 站点能抓、HTTPS 站点报证书错误。 链路已通，证书链没接上——按第一部分的步骤重查证书导入位置：导入了"个人"区而不是"受信任的根"区是高频错误；macOS 导入后没有手动点"始终信任"是另一高频错误。

第三步：个别 HTTPS 站点报错，其他正常。 通常是该站点启用了严格的证书透明或客户端校验策略。练习靶场不会出现这种情况；真实评估里遇到，正确做法是记录现象并在报告中说明该资产在代理工具下的可见性限制，而不是想办法绕过——绕过本身可能超出授权。

第四步：移动端抓不到。 手机与电脑要在同一网络，代理指向电脑的局域网地址，且监听器要绑定到所有接口而非仅回环；新版系统对用户安装证书默认只在浏览器生效、应用内不信任，练习用途下浏览器验证即可，不必强求应用内解密。

⚠️ 排错时一次只改一处配置。两处一起改，好了不知道哪处起效，坏了不知道哪处添乱。

各平台安装细节速查

证书导入的手感各平台不同，把高频路径整理成对照表，排错时按表核对。

表里每一个"高频失误"都对应一次真实排错。另一条值得知道的机制差异：部分浏览器使用系统证书存储，部分使用自带存储（常见的 Firefox 系），所以"系统装了证书浏览器还报错"先查浏览器用的是哪个存储。移动端的新版系统普遍对用户安装的证书采取"浏览器信任、应用不信任"策略，这不是配置错误而是平台安全设计，应用内解密需要更高权限的操作，练习场景不必强求，评估场景遇到则如实记录平台限制。

一份完整排错记录的整理格式

排错的价值不止于当下修好，把过程整理成记录，团队里第二次遇到就能秒级定位。推荐格式四行：现象（报错原文或行为描述）、环境（系统、浏览器、工具版本）、已验证步骤（按本节的顺序逐条打钩）、结论（根因与修复动作）。按这个格式归档的排错记录积累下来就是团队资产——2.3 节说的配置库管配置，这份记录管经验，两者配套。带新人的团队尤其受益：新人遇到证书问题自己翻记录就能解决，不需要每次都占老手半小时。

补一个容易被忽视的角落：系统时间。证书校验依赖本机时间，虚拟机快照恢复、双系统切换后时间错乱，会造成"证书未生效"类报错，而配置明明全对。遇到解释不通的证书错误，先看一眼系统时钟，成本两秒，经常直接命中。

高频疑问

问：解密 HTTPS 会不会影响性能或行为？
答：多一次握手与加解密，延迟增加很小，功能行为不受影响。极少数对证书指纹做校验的目标会拒绝连接——这属于目标侧的增强防护，如实记录，不做绕过。

问：靶场全在本机，还需要折腾证书吗？
答：靶场镜像若以 HTTP 提供，确实用不上。但练习证书配置的意义在于真实评估必然遇到 HTTPS 目标，环境准备是按真实场景练的。建议练习环境也用 HTTPS 跑一遍全流程，把证书肌肉练出来。

问：浏览器提示证书错误时点了继续访问，有什么后果？
答：该次会话的流量仍会经代理，但浏览器对证书域的告警会被抑制，可能掩盖真实的证书配置问题。练习中养成"报错就修，不用例外放行"的习惯，评估时才不会把配置缺陷漏到现场。

与后续章节的接口

到本节为止，明文与密文流量都进了同一份历史记录，管道彻底打通。第三章开始用这些流量做正经事：站点地图整理、范围圈定、请求送入重放器验证。把本节排错顺序记熟，它会在你之后的每一次环境变更里反复派上用场。

本节要点回顾

• 机理：HTTPS 解密是把一次会话拆成两段的受控中间人，成立条件是信任 Burp 根证书。
• 操作：下载根证书、导入受信任区、访问 HTTPS 看明文，三步缺一不可。
• 排错：先查链路记录，再查证书区位置，再看个别站点策略，最后才动移动端。
• 纪律：根证书是高风险配置，只在练习机与专用配置文件中安装。