给网站接入CDN并开启HTTPS之后，很多站长会遇到一个奇怪的现象：PC端的Chrome、Firefox访问完全正常，地址栏还挂着小绿锁，但用一些老旧的Android手机或者某些App内的WebView打开时，却弹出「该证书并非来自受信任的授权中心」的警告。问题往往不在证书本身，而在于服务器没有下发完整的证书链。本文就来把这个问题的来龙去脉讲清楚，并给出完整的排查和修复方案。
为什么证书链不完整会导致Android低版本报错
要理解这个问题，先要明白TLS握手时证书校验的逻辑。客户端拿到服务器下发的证书后，会沿着证书链向上追溯：叶证书由中间CA签发，中间CA又由根CA签发，而根CA预装在操作系统或浏览器的信任库里。只有当这条链能一路追到受信任的根证书，校验才算通过。
关键区别在于：操作系统内置的信任库里通常只存放根证书，中间证书并不在里面。服务器在TLS握手时必须把叶证书和中间证书一起发下来。如果服务器只发了叶证书，客户端就需要自己去下载中间证书，这个过程叫AIA抓取（Authority Information Access fetching）。现代桌面浏览器基本都支持自动补全，所以PC上看起来一切正常；但Android 7.0之前的系统、老版本OkHttp、以及大量嵌入式网络库并不做这个补全，拿到孤零零的叶证书后找不到签发者，直接判定证书不受信任。
这也解释了为什么问题总是「选择性出现」：设备越新、网络库越现代，越能容忍不完整的证书链；而Android 4.x、5.x这类老设备几乎必挂。如果你用Chrome桌面版测试一切正常就认为配置没问题，很容易掉进这个坑。
如何检测证书链是否完整
最直接的检测工具是openssl命令。用下面这条命令模拟客户端握手，并输出服务器实际下发的证书：
openssl s_client -connect example.ipipp.com:443 -servername example.ipipp.com -showcerts
观察输出结果，重点看两个地方。一是顶部的Certificate chain部分：如果只列出一层证书（深度0），说明服务器只下发了叶证书，链是不完整的；正常情况下应该至少看到两层，即叶证书加中间证书。二是看末尾的Verify return code，显示unable to get local issuer certificate基本就可以确认是缺中间证书。
也可以用在线检测服务，比如SSL Labs的SSL Server Test，输入域名跑一次完整扫描。如果报告里出现「Chain issues: Incomplete」或者评级为B以下，同样说明证书链有问题。在线工具的优势是能模拟不同客户端环境，可以直观看到哪些老平台会校验失败。
另外还可以直接在Android设备上验证：用老版本的Chrome或者系统浏览器打开站点，如果报「安全证书无效」而新设备正常，再结合openssl的结果交叉印证，基本可以锁定证书链问题，排除掉域名不匹配、证书过期这类其他可能。
在源站与CDN侧补全证书链的实操方法
修复的核心思路只有一个：把中间证书追加到下发的证书文件里。以Nginx为例，证书签发机构一般会给你几个文件：叶证书、中间证书、根证书。正确做法是把叶证书放最前面，中间证书紧随其后，拼成一个完整的fullchain.pem：
cat your_domain.crt intermediate.crt > fullchain.pem
然后在Nginx配置中指向拼接后的文件：
server {
listen 443 ssl;
server_name example.ipipp.com;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;
}注意顺序不能颠倒，叶证书必须在文件第一位，否则部分客户端会直接握手失败。根证书不需要放进去，因为客户端信任库里已经有了，发了反而浪费握手流量。如果用的是Let's Encrypt，certbot生成的fullchain.pem本身就是完整的，问题往往出在自己手动拼接或从证书商后台只下载了叶证书的场景。
如果HTTPS是终结在CDN上的，也就是证书配置在CDN控制台，那么排查对象就是CDN侧。主流CDN（阿里云、腾讯云、Cloudflare等）在配置HTTPS证书时，都要求上传「证书内容+私钥」，或者直接选择已托管证书。这里常见的坑是：手动上传时只粘贴了叶证书的PEM内容，漏掉了中间证书。正确做法是在证书内容框里，把叶证书和中间证书的PEM文本按顺序全部粘贴进去。判断依据很简单：PEM文件里BEGIN CERTIFICATE的段数应该等于证书链的层数，两层链就有两段。
如果你用的是免费DV证书，从某些渠道下载时可能只给一个crt文件，这时可以去证书商官网下载对应品牌的中间证书，或者用openssl从别的配置正确的服务器上把中间证书抓下来。修改配置后记得重启Nginx或刷新CDN配置，再用openssl验证一遍，确认Certificate chain里出现了两层以上证书。
其他容易被忽略的相关问题
证书链补全之后，如果个别老设备仍然报错，还有几个方向值得检查。第一是根证书的信任问题：部分老CA的根证书是在设备出厂后才加入信任库的，一些特别老的Android设备可能不信任你的证书品牌。可以用SSL Labs的报告查看「Handshake Simulation」部分，看各平台模拟结果。第二是跨签（cross-signed）中间证书的选择，有些CA历史上换过中间证书，下载时要选与你叶证书实际签发者匹配的那一个，可以通过比对证书的签发者字段来确认。
第二是SNI的支持问题。如果CDN配置了多个证书，老设备如果不发送SNI扩展，可能拿到默认证书，导致域名不匹配而报错，这种错误的提示文案和证书链问题很像，要注意区分。排查时可以先在支持SNI的现代客户端上确认返回的证书序列号是否正确。
第三，如果你的App用的是自己封装的网络层，还可以在客户端做兜底：OkHttp从某个版本起支持通过sslSocketFactory自定义信任逻辑，但不建议直接信任所有证书，那等于放弃了HTTPS的安全意义。正确的做法始终是把服务端的证书链配置完整，客户端保持严格校验。总结成一句话：服务器下发完整证书链是义务，客户端补全是情分，依赖情分的架构迟早会在某个老设备上翻车。
CDN HTTPS证书证书链不完整Android证书信任修改时间：2026-09-05 07:24:33