摘要：API 客户端一旦固定了服务器证书或公钥，正常的 SSL 证书更新也可能让调用全部失败。根因通常不是新证书无效，而是客户端 Pin 与新证书、公钥或证书链不再匹配。本文说明如何判断 Pin 的类型，并用双 Pin、灰度和回滚安排降低升级风险。
固定的是旧信息 新证书再合法也会被客户端拒绝
普通 TLS 校验会验证域名、有效期、证书链和客户端信任库；证书固定则额外要求服务端提供的证书或公钥，与应用预先保存的值匹配。只要 Pin 不匹配，客户端就会主动中止连接。对客户端而言，这不是证书更新失败，而是一次明确的安全拒绝。
因此，证书更新不能只安排在服务器侧。只要API 由移动应用、桌面客户端、设备固件或内部 SDK 调用，证书变更都需要把客户端版本、Pin 集合、发布渠道和最低支持版本纳入同一张升级计划。
先分清 固定的是整张证书 还是公钥
固定整张叶子证书最直观，但也最容易在证书重新签发时失效：即使域名、CA 和服务器都没有变化，新证书的内容通常已经不同。固定公钥会更灵活一些；如果新证书继续使用同一对密钥，Pin 可以保持不变，但把长期不换密钥当作常规续期策略并不理想。
还有一些实现会固定中间CA 或维护多个可接受值的 Pin 集。它们的兼容性更高，但信任范围也会扩大。选哪一种不应只看“更新是否方便”，而应结合威胁模型、客户端可控程度、密钥轮换要求和停机代价决定。OWASP 的现行建议也强调：如果不能安全、及时地更新 Pin 集，固定策略本身可能带来高于收益的可用性风险。
为什么证书更新常常变成 API 故障
1. 服务器更换了证书，同时换了密钥对，客户端仍只保存旧公钥或旧证书哈希。
2. CDN、WAF、负载均衡和源站的 TLS 终止位置不一致，部分请求命中新证书，部分请求仍返回旧证书。
3. 应用内 Pin 集随代码发布，旧版本应用没有机会获得新 Pin，用户没有升级就会永久失败。
4. 证书链发生变化，客户端固定了某一中间证书或对链路实现了过度严格的比对。
5. 测试只覆盖了最新 App 或办公室网络，没有覆盖旧版本、海外节点、备用域名和真实 CDN 路径。
更稳妥的做法 先让客户端接受新 Pin 再切换服务器
兼容升级的关键不是“在更新日尽快换证书”，而是建立一个重叠期。第一阶段，客户端发布包含当前Pin 与下一把公钥或下一张证书信息的版本；第二阶段，观察新客户端覆盖率、接口成功率和 Pin 失败日志；第三阶段，再将服务端切到新证书；最后，在旧客户端退出支持范围后移除旧 Pin。
对无法频繁升级的客户端，如IoT 设备、企业桌面软件或嵌入式终端，应在设计阶段准备至少一个备用 Pin，并定义可信的配置更新与紧急回滚机制。不能把“等所有用户升级”作为唯一预案，因为大量设备可能长期离线或停留在旧版本。
服务端切换前需要验证的四件事
• 确认所有 TLS 终止点，包括 CDN、WAF、负载均衡、网关和备用入口，均已登记在切换范围内。
• 用目标 API 域名和 SNI 验证各节点实际返回的叶子证书、公钥和完整证书链。
• 在灰度节点上同时用新旧客户端、不同地区网络和自动化健康检查发起真实接口请求。
• 保留可快速恢复的旧配置，但不要把已经泄露、误签或不再可信的旧证书作为回滚手段。
什么时候不宜做证书固定
如果客户端和服务端不由同一团队控制、客户端更新不可预测，或无法通过受保护渠道安全更新Pin 集，就不适合为了“更安全”而仓促加入固定逻辑。标准 TLS 验证、正确的域名校验、证书透明度和 CAA 等机制，往往比难以维护的 Pin 更能兼顾安全性与可用性。
FAQ
1.不更换私钥 只续期证书 能避开固定失败吗？
若客户端固定的是公钥，复用密钥可能暂时避免Pin 变化；但这不应成为长期常规做法。密钥轮换、泄露处置和合规要求仍应被保留，正确解决方式是规划可兼容的 Pin 集与客户端升级。
2.已经上线的旧版本 App 无法更新 怎么处理？
先统计旧版本数量、调用量和是否可被强制升级。若旧客户端仍是关键流量，应在切换前保留兼容窗口，并评估是否存在安全的远程配置更新机制；没有可信更新路径时，应谨慎调整证书和密钥变更计划。
3.证书固定是否能解决所有中间人风险？
不能。固定只是特定威胁模型下的一层控制，仍需要正确的TLS 配置、密钥保护、证书生命周期管理和接口身份认证。
关于 GlobalSign
GlobalSign 提供 SSL TLS 证书服务。对于有 API 客户端的业务，证书采购和续期计划应同时考虑客户端兼容性、密钥轮换、CDN 或负载均衡配置以及发布节奏，避免把正常的证书更新变成线上接口故障。
数据来源：OWASPPinning Cheat Sheet；GlobalSign SSL TLS 证书与证书管理技术资料。