摘要：我们的服务面向海外用户。近期部分海外用户的老款手机——尤其是出厂较早、系统长期未更新的老 Android 机型——以及内部部分老 Linux 环境（如 CentOS 7），在访问海外服务时出现 SSL 报错，根因是海外服务 DV 证书的签发 CA 太新，老设备信任库里没有对应的新根。Akamai 通过"证书交叉签名（cross-signing）"实现双信任链兼容：在现有证书上再叠加一张老牌根 CA 的签名，让新老设备各走一条信任链。本文从信任链原理讲起，逐层拆解故障根因、解法机制，以及那个关键的时间边界——老牌根 CA 有效期截止2029/01/01。一、现象：海外用户访问服务，部分老款手机连不上我们的服务面向海外用户，部分用户通过老款手机等设备访问。在接入一批海外新服务时，发现一个"挑设备"的诡异现象：新设备 / 新系统：一切正常，HTTPS 握手顺畅。部分老设备：访问同样的域名，直接 SSL 报错，连接建不起来。最典型的是部分老款手机——尤其是出厂较早、系统常年未更新的老版本 Android 机型；此外，内部一些老 Linux 环境（如 CentOS 7）在调海外接口时也复现了同样的报错。报错形态常见于这些：SSL certificate problem: unable to verify the first certificate SSL certificate problem: unable to get local issuer certificate x509: certificate signed by unknown authority注意关键词：unknown authority（未知的签发机构）。这已经暗示了根因——客户端"不认识"签发这张证书的根。二、前置知识：HTTPS 信任链是如何建立的要理解报错，得先理解一张证书为什么"可信"。HTTPS 不是靠"证书自己证明自己"，而是靠一条信任链往回验证。以我们这次的海外站点为例，完整链条是：┌─────────────────────────────┐ │ 网站证书 (Leaf / End-Entity) │ ← 部署在服务器上的那张 │ 域名：xxx.overseas.com │ └──────────────┬──────────────┘ │ 由谁签名？ ┌──────────────▼──────────────┐ │ 中间 CA (Intermediate CA) │ ← 中间证书 └──────────────┬──────────────┘ │ 由谁签名？ ┌──────────────▼──────────────┐ │ 根 CA (Root CA) │ ← 证书链顶端 └──────────────┬──────────────┘ │ 必须提前"装"在设备里 ┌──────────────▼──────────────┐ │ 设备信任库 (Trust Store) │ ← 操作系统/浏览器内置 │ 预装了数百个受信任的根 CA │ └─────────────────────────────┘信任的本质：设备只要在它的"信任库（Trust Store）“里预装了最顶端的根 CA，就能一路向下确认"这张网站证书是可信的”。反过来，如果信任库里没有这个根，验证就断在顶端，结果就是unknown authority。信任库是随操作系统 / 浏览器更新推送到设备上的。一个新 CA 的根要想被信任，设备得"见过"它——也就是收到过包含它的更新。三、根因分析：为什么"新 CA"会让部分设备翻车（不止老设备）回到我们的故障。这些新接入的海外站点用的是 DV 证书（Domain Validation，域名验证型证书），由一家较新成立或较新轮换根的 CA 签发。问题就出在"新"字上：新 CA 的根进入信任库的时间晚。它近一两