Java 与 Python 信任所有 SSL 证书的风险与正确做法
信任所有证书会破坏 HTTPS 身份验证。本文说明 Java/Python 的应用级信任配置、可信 CA 获取和开发环境边界，不提供生产绕过校验的方案。
直接回答：不要信任所有证书。 关闭证书校验后，HTTPS 只加密不认证，攻击者用一张自签证书就能劫持流量。开发环境也优先使用受控测试 CA。先修复链和名称，再把经独立渠道核验的 CA 配置到相应应用信任库，而不是关闭验证。
为什么"信任所有"如此危险
TLS 提供两件事：加密和身份认证。信任所有证书等于放弃了后者：
- 证书链信任与主机名匹配是相关但不同的检查；某些 Java 客户端更换 TrustManager 后仍做主机名校验，但这不补回链信任被关闭的风险
- 网络路径上任何人都可以出示一张自己签的证书，客户端照单全收
- 流量依然"加密"，但加密的对端可能是攻击者——中间人可以明文读取、篡改所有数据
这些写法会让依赖方误以为"有 HTTPS 就安全"，是审计和合规上的高危项。
正确做法：把 CA 导入信任库
先区分缺失中间链、未知 CA、过期、域名不匹配和系统时间错误。修复服务端或客户端的实际根因：
Python（requests / urllib）
pip install --upgrade certifi
import certifi, ssl, requests
# 公网站点可使用公共 CA bundle；certifi 不包含企业私有 CA
requests.get('https://example.com', verify=certifi.where(), timeout=10)
# 企业 CA 须经 IT 可信渠道取得并核验指纹
requests.get('https://internal-api.example.com', verify='/path/to/company-ca-bundle.pem', timeout=10)
ctx = ssl.create_default_context()
ctx.load_verify_locations(cafile='/path/to/company-root-ca.pem')
Java
把企业内网 CA 或自签证书导入 truststore：
keytool -import -trustcacerts \
-alias internal-ca \
-file internal-ca.crt \
-keystore /path/to/application-truststore
或指定独立 truststore 启动：
java -Djavax.net.ssl.trustStore=/path/to/truststore.jks \
-Djavax.net.ssl.trustStorePassword=changeit \
-jar app.jar
开发环境的临时绕过要有边界
开发环境也应使用受控测试 CA，并验证 SAN。不要用通用环境变量把任意 URL 切到不验证模式，也不要全局抑制警告。测试 CA 只安装到专用测试设备，私钥不得发布或提交。
证书修复后，先用原客户端验证主机名和证书链。若还配置了观测云 HTTPS 拨测，保持证书校验开启，并检查拨测节点能否访问目标；私有 CA 与客户端证书是不同配置，不能通过勾选忽略证书错误代替建立正确的信任关系。
常见问题（FAQ）
Q：为什么自签证书环境下不能直接信任所有证书？
A：因为"信任所有"不只信任你的自签证书，而是信任世界上任何人签的任何证书。正确做法是把这张自签证书（或其 CA）单独导入客户端信任库，既能用又不扩大攻击面。
Q：Java 导入证书到 cacerts 后还是报 PKIX 错误？
A：先确认导入的是运行应用的 JVM 的 cacerts（多 JDK 环境容易导错位置），其次确认导入的是完整的证书链（根 CA 或中间 CA），而不是只导了服务器叶子证书。
Q：requests 关闭验证时满屏 InsecureRequestWarning 怎么办？
A：保留警告并修复证书链、域名和信任配置。全局抑制警告只会掩盖后续不安全请求。
参考资料
本文依据官方资料核对，未进行现场运行测试；代码与配置示例需结合实际版本、权限和环境验证。
- requests.readthedocs.io：#ssl cert verification
- docs.python.org：ssl
- docs.oracle.com：java secure socket extension jsse reference guide
- docs.guance.com：http
- docs.guance.com：ssl
