刚好之前在生产环境处理过类似的证书更换问题，给你梳理下核心疑问和可行的兼容方案：

一、是不是只能固定证书？ #

没错——当你生成使用全新公钥的新证书时，之前的公钥/SPKI固定规则完全失效，因为新证书的公钥哈希和旧的完全不匹配，旧版本App里的校验逻辑会直接拒绝新证书。这时候如果要做固定，确实只能固定新证书本身，但正如你担心的，这必须依赖App更新，旧版本用户没法自动适配。

二、怎么避免旧版本用户连接失败？ #

这里有几个经过实践验证的平滑过渡方案：

• 双证书并行部署（最常用的过渡方案）
  如果你旧证书还没过期，或者能向CA申请到同旧公钥的续期证书（大部分主流CA都支持这个操作，哪怕旧证书过期，只要私钥还在就能申请），可以在服务器上同时部署旧证书（或同公钥续期证书）和新证书，通过SNI让服务器根据请求返回对应证书。这样旧版本用公钥/SPKI固定的用户能正常连接，新版本用户用新证书，等大部分用户升级后再下线旧证书。

• 远程配置添加双重校验
  如果你的App支持拉取远程配置（比如内置配置中心、后台推送的小配置包），可以在旧版本里更新校验逻辑：同时保留原有的公钥/SPKI固定，新增对新证书公钥/SPKI的校验，只要任意一个匹配就允许建立连接。这样旧版本用户不用升级App，只要拉到新配置就能兼容新证书，风险小且见效快。

• 临时放宽校验（风险可控时使用）
  如果用户基数极大、升级周期很长，且你的服务器有足够的安全防护（比如严格的WAF规则、IP白名单、API签名校验），可以临时关闭旧版本的证书固定逻辑，等80%以上用户升级到新版本后再重新开启。这个方案要谨慎评估风险，确保不会被中间人攻击钻空子。

• 分层推送升级通知
  对旧版本用户分优先级推送升级：给活跃用户弹出强制升级弹窗，对低频用户推送温和提醒，同时在应用商店、官网、用户社群同步公告。如果你的App有核心功能依赖服务器连接，甚至可以设置“旧版本仅能访问基础功能，升级后才能使用全功能”的规则，加快用户升级速度。

长期优化建议 #

从长远来看，除非是私钥泄露等安全原因，否则尽量不要更换公钥——正常续期证书时申请同公钥的续期证书，这样公钥/SPKI固定可以一直生效，不用折腾用户升级，也能避免这类兼容问题。

内容的提问来源于stack exchange，提问作者guhan0