解读

面试官问“什么是证书锁定”时，真正想考察的是：

1. 你是否理解 HTTPS 信任链的薄弱环节——“只要系统信任任意 CA，就可能签发伪造证书”；
2. 你是否知道在 Android 侧如何把“信任谁”的决策权从系统回收，落到业务自己手里；
3. 你是否能权衡 Pinning 带来的安全收益与运维成本，并在国内“HTTPS 劫持、中间人钓鱼、山寨 Wi-Fi 热点”高发场景下给出落地方案。

回答时要体现“原理 → 实现 → 攻防 → 国内场景”的闭环，避免只背概念。

知识点

1. 证书链与 CA 模型：系统预置 100+ CA，任一被攻陷或遭人为滥发即可伪造域名证书。
2. Pinning 本质：在客户端内置“期望的公钥/证书指纹”，TLS 握手时只信任该指纹，忽略系统信任库。
3. 实现位置：
   • 应用层：OkHttp CertificatePinner、Volley 重写 TrustManager、URLConnection 自定义 X509TrustManager。
   • 系统层：network-security-config（Android 7.0+）支持 与，可热更新。
4. 指纹算法：SHA-256/SPKI(base64) 为主，国内合规需避开已退役的 SHA-1。
5. 攻击面：
   • 防止恶意 CA 签发伪造证书（如防火墙劫持、运营商广告注入、钓鱼热点）。
   • 防止企业内网抓包工具（Charles/Fiddler 根证书）被静默安装后解密流量。
   • 防止国家级别透明网关通过“受信任中间 CA”做流量审查。
6. 局限与风险：
   • 证书轮换导致客户端握手失败，国内大厂采用“双证书+梯度发布”解决。
   • 调试阶段需白名单机制，避免开发包无法抓包定位问题。
   • 不能防御客户端被逆向后摘除 Pinning 逻辑，需配合混淆、完整性校验、SafetyNet/Device Attestation。
7. 国内合规：工信部 337 号文要求 App 不得默认信任用户证书，Pinning 与“用户证书白名单”需并存；小程序/快应用若内嵌 WebView，需同时给 WebView 配置 onReceivedSslError 拒绝策略。

答案

证书锁定（Certificate Pinning，也叫 SSL Pinning）是指客户端在 TLS 握手阶段不再无条件信任系统内置的 100 多个 CA，而是预先嵌入一份“允许名单”——可以是整张服务器证书、中间 CA 证书，更轻量的做法是只锁定公钥的 SHA-256 指纹（SPKI）。只有当服务器返回的证书链中至少有一个元素与本地指纹匹配，才继续握手，否则立即抛 SSLPeerUnverifiedException 并中断请求。

在 Android 侧，主流实现有两条路径：

1. 应用层：OkHttp 的 CertificatePinner 提供一行代码 certificatePinner = new CertificatePinner.Builder().add("api.example.com", "sha256/123456…").build()，支持多域名、多指纹、通配符。
2. 系统层：在 res/xml/network_security_config.xml 中声明 `` 节点，打包后无代码侵入，Android 7.0+ 生效，可通过 Google Play 动态交付更新指纹列表。

Pinning 能阻断的攻击场景包括：

• 运营商或本地 Wi-Fi 网关通过向用户手机静默安装自签根证书，进行广告注入或内容篡改；
• 黑产利用购买到的“受信任中间 CA”签发钓鱼域名证书，绕过常规 HTTPS 绿色小锁；
• 企业内网审计工具强制安装根证书后，对员工 App 做解密抓包，导致用户明文数据泄露；
• 国家级别透明代理通过合法 CA 签发“中间人证书”做流量审查。

但它不能解决客户端被逆向后主动移除 Pinning 逻辑、服务器私钥泄漏、或者业务层 XSS/越权等问题，因此需要与代码混淆、完整性校验、密钥白盒、服务端证书短周期轮换等方案组合，形成纵深防御。

拓展思考

1. 国内大厂“灰度证书轮换”方案：在 network-security-config 里同时写入新旧两个指纹，服务端先升级证书，观察 48 小时无异常后，发新版 App 把旧指纹移除，实现用户无感切换。
2. 调试与运维平衡：国内开发习惯用 Charles 抓包，可在 buildConfig 中增加 DEBUG_ALLOW_USER_CERT 开关，debug 包信任用户证书，release 包强制 Pinning，并通过 CI 脚本自动检查 network-security-config 是否包含 debug 后门。
3. 小程序/WebView 场景：微信、支付宝 WebView 默认不走系统 network-security-config，需在 onReceivedSslError 里主动 handler.cancel()，否则 Pinning 形同虚设。
4. 合规审计：工信部 337 号文、个人信息保护合规审计中，Pinning 被列为“传输层防劫持”必检项，审计员会用 Frida 挂掉 App 的 TrustManager，若仍能解密流量即视为不合格。
5. 未来趋势：IETF 的 HPKP 因部署复杂已废弃，取而代之的是“Expect-CT + Pinning”混合模式；国内头部 App 开始试点“短周期证书（7 天）+ 自动化指纹分发”以降低运维成本，同时引入 TEE 级密钥证明，确保 Pinning 逻辑无法被用户层调试器绕过。