带新人配抓包环境，最容易卡住的是证书这一步。系统证书装好，浏览器里 HTTPS 明文看得清清楚楚，一切到 Java 服务、Python 脚本、curl 命令，马上变脸——报错文案还各说各话：Java 报 PKIX path building failed，Python 抛 SSLCertVerificationError，curl 提示 unable to get local issuer certificate。同一条代理链路，浏览器过了、程序不过，问题不在证书本身。下面说的"装证书"，装的都是抓包工具的根证书——多数时候不是它没装，而是装错了地方。
这类"证书装了还是不认"的场景攒起来大概四种：
- Java 服务调第三方接口，本地好好的，接上抓包就报证书路径错误
- Python 脚本调接口、爬数据，一挂代理全是 SSL 证书错误
- curl、wget、git 拉东西，突然提示证书不受信任
- Firefox 里明明配好的证书，换个工具又要再装一遍
根子在"信任谁"这件事不止一份名单。操作系统有一份证书库，很多浏览器和程序读它；另一些程序自带独立的一份——Java 读 JRE 里的 cacerts 密钥库，Python 的 requests 用 certifi 自带的证书包，curl 走 OpenSSL 编译时定下的默认 CA 路径，Firefox 从 2019 年起用自己的证书库。抓包工具的根证书装进系统库后，读自己那份名单的程序该不认还是不认。所以正解不是"把系统证书再装一遍"，而是找到目标程序读的是哪一份，把证书装进那一份。
怎么判断一个程序读的是哪份名单？看报错文案最直接：带 PKIX、"unable to find valid certification path" 字样的多半是 Java；SSLCertVerificationError、"certificate verify failed" 常见于 Python 和 OpenSSL 系；curl 会明确说 unable to get local issuer certificate。认出门派，再按下面的分类处理。
Java 程序报 PKIX 证书路径错误，装到哪才算数？
Java 不读系统证书库，它读 JRE 目录下的 cacerts 密钥库。手动路线是用 keytool 把根证书导进去：
keytool -importcert -trustcacerts -alias proxy-ca \
-keystore "$JAVA_HOME/lib/security/cacerts" \
-file proxy-ca.crt
两个提醒：cacerts 默认口令是 changeit，生产环境改过的话得找运维要；机器上装了多个 JDK/JRE 时，每个都有自己的 cacerts，别只装了一个。不想动密钥库，也可以用启动参数指定信任库（-Djavax.net.ssl.trustStore 加 -Djavax.net.ssl.trustStorePassword），但那要改每一条启动命令，服务一多就散，长期看不如统一装进 cacerts。
这种逐个导入的活，TraceEagle 的证书管理页做成了「证书全覆盖」：自动发现本机这类程序（包括正在运行的），逐个标「已装 / 未装」，点安装就送进对应的证书库，不用记路径和口令。
Python 抛 SSLCertVerificationError，证书包在谁手里？
Python 的 requests 不读系统证书库，它用 certifi 这个包自带的证书清单——certifi.where() 能查到具体文件路径。手动路线有三条：代码里 verify 参数指向你的 CA 文件；设 REQUESTS_CA_BUNDLE 环境变量；或者用 SSL_CERT_FILE 指定。麻烦点在 Python 环境可能有好几个——系统解释器、pyenv、各版本虚拟环境各有各的 certifi，脚本实际用哪个，得对着报错现场判断。认环境有个笨办法但管用：先 which python 或 pip -V 确认脚本跑在哪个解释器下，再往那个环境的证书配置上找。
自动发现对这种多环境场景省事：扫出来逐个装，漏掉的用手填路径补。
还有种野路子：直接往 certifi 的 cacert.pem 里追加根证书。能用，但记着 certifi 升级时（pip 更新依赖会带上）这个文件会被覆盖，得重新追加——长期方案还是环境变量或显式指定，稳得多。
curl、wget、git 这些命令行工具呢？
它们走 OpenSSL / libcurl 的默认 CA 路径。临时用可以在命令行指定：curl 用 --cacert 指向证书文件、wget 用 --ca-certificate（或 --ca-directory 指整个目录）；git 则用 http.sslCAInfo 配置或 GIT_SSL_CAINFO 环境变量。想让它们在抓包时都正常，还是得把根证书放进对应工具的默认信任路径——这正是全覆盖里「命令行与脚本工具」那一档覆盖的范围（curl、wget、Ruby、PHP、git 都认）。
Firefox 为什么总要单独装？
Firefox 从 2019 年起不读系统证书库，用自己维护的一套。证书在设置里导入（隐私与安全、证书、查看证书、导入），Thunderbird 同理。因为独立，别的浏览器装过的不算数，Firefox 得单独来一遍。
Node.js 写的工具、Electron 应用呢？
Node.js 也自带一套：默认读内置的 Mozilla CA 清单，和系统库不是一回事；用 NODE_EXTRA_CA_CERTS 环境变量指向根证书文件，就能把你的证书追加进去。Electron 打包的桌面应用继承了类似的行为，调它的网络请求时同样用这个变量试。这类运行时的共同点还是那句：先搞清它默认信谁，再把根证书加进那份信任里。
顺带对比下同类工具在这一步的做法：mitmproxy 提供了详细的证书安装文档，引导你逐个程序手动装；Charles、Fiddler 装完系统证书后，遇到 Java、Python 的目标，同样要自己去配 trustStore 和 certifi。把"发现本机这些程序、把证书送进各自证书库"收成界面上一步，是部分工具这两年补上的体验——工作里这类程序多的团队，选抓包工具时可以把这一步的省事程度算进去。
还是解不开，或者不想一个个装？
一种思路是把证书送进正确的地方：全覆盖自动发现漏掉的程序，用手填路径指过去再装；另一种是绕开证书——有的目标压根不走标准 TLS（自研加密），证书解决不了，换应用层抓包从程序内部取明文。
还有个更省事的选择：换个抓法。网卡抓包、指定程序抓包这类不走代理的方式，本身不要求安装根证书——不想挨个配证书库的场景，从源头避开这摊事。
装完怎么验证装对了？重现一次原来的报错场景最直接：Java 服务重新调一次、Python 脚本重跑一遍，报错变成正常响应就对了；走代理的抓包会话里，对应请求的 TLS 状态从密文变「已解密」，也是明确的信号。要是没生效，先回到"它到底读哪份名单"这步——大概率是装错了地方，不是证书本身有问题。
按这种方法排查试试：先看报错的是哪个程序，找到它读哪份证书库，把根证书装进那一份——Java 进 cacerts、Python 进 certifi、命令行进 OpenSSL 路径、Firefox 进它自己的库。嫌逐个装麻烦，让 TraceEagle 证书管理里的全覆盖自动找；实在不想碰证书的，换成不走代理的抓法，问题根本不会出现。
