证书后台显示还有几十天才过期，电脑浏览器也能正常访问，但旧手机、某些应用或接口客户端却提示证书不受信任。这个现象不能只用缓存解释，因为客户端能否建立信任，不只取决于站点证书的到期时间。
证书链、域名匹配、SNI、终端根证书库以及 CDN 与源站返回差异，都可能让不同设备得到不同结果。处理时先保存每个入口实际返回的证书，再判断缺的是哪一环。
先记录发生错误的具体入口
排查前先固定域名、端口、网络、设备和发生时间。同一个网站可能同时存在主域名、www、接口子域名与回源域名，它们未必使用同一张证书。
先在正常电脑和异常设备上确认访问的是完全相同的域名。不要把使用 IP 访问时出现的证书错误与域名访问混为一谈，大多数公开证书只签发给域名，不会匹配服务器公网 IP。
还要记录异常设备显示的错误类型。域名不匹配、证书过期、未知颁发机构和握手失败属于不同方向。只写 HTTPS 不安全，后续很难还原问题。
用OpenSSL查看服务器实际发送的内容
从外部网络执行：
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullOpenSSL 官方把 s_client 定义为通用 SSL/TLS 客户端和诊断工具。这里的 -servername 会发送 SNI，避免多站点服务器返回默认证书；-showcerts 用于显示服务器发送的证书列表。
重点保存以下结果：
- 叶子证书的 Subject 与 SAN 是否包含目标域名
- Issuer 是否符合预期
- 服务器发送了几张证书
- 最后的 Verify return code 是什么
-showcerts 显示的是服务器实际发送的列表，不代表客户端已经构建出可信链。根证书通常由客户端本地信任库提供，服务器一般不需要发送根证书。
证书没过期不等于证书链完整
公开 HTTPS 常见链路是站点证书、中间证书和根证书。服务器只配置站点证书，遗漏中间证书时，一些桌面浏览器可能通过缓存或在线获取补齐，较旧设备、嵌入式客户端和严格接口库却会直接失败。
Nginx 通常应配置包含站点证书与中间证书的完整链文件，例如：
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;具体路径取决于证书来源和面板，不能照抄域名。若误把 cert.pem 当成完整链，浏览器表现可能不一致。
修改后先执行：
sudo nginx -t
sudo systemctl reload nginx然后重新运行 openssl s_client，确认服务器实际返回已经变化。控制面板显示配置成功，只能证明文件被保存，不能代替公网握手验证。
区分CDN证书和源站证书
启用 CDN 或反向代理后，访客连接的是边缘证书，CDN 回源时连接的则可能是另一张源站证书。公网域名测试正常，不代表直接回源也正常；源站正常，也不代表所有边缘位置已经更新。
可以先测试公网域名，再使用受控解析指定源站 IP：
openssl s_client -connect origin-ip:443 -servername example.com -showcerts </dev/null这条命令仍保留目标域名的 SNI，只改变连接地址。若公网与源站返回不同的颁发者、有效期或证书链，故障就应分别从 CDN 证书部署和源站配置排查。
更换云服务器时也要把证书验证纳入迁移验收。我见过站点从旧实例迁到萤光云或 LightNode 后，DNS 已经切换，但新服务器只复制了站点证书，没有同步完整链；平台本身并不会替应用自动修复这一层。选择固定配置长期运行或利用小时计费安排迁移窗口都可以，真正决定 HTTPS 是否正常的是新入口实际返回的证书、链与域名是否一致。
为什么只有部分设备报错
不同设备的根证书库版本、链构建能力和 TLS 支持并不完全相同。旧系统长期未更新，可能缺少新根证书；某些应用还会使用自带的信任库，而不是系统信任库。
先检查异常设备的系统时间。时间偏差过大时，仍在有效期内的证书也可能被判断为尚未生效或已经过期。随后确认系统与应用是否已经更新。
若只有一类旧设备失败，而 OpenSSL 与主流浏览器验证均通过，需要查看证书机构公布的兼容性范围。不要为了兼容极少量过旧客户端，直接重新启用已经淘汰的 TLS 版本或弱密码套件，这会扩大所有访客的安全风险。
域名匹配与SNI不能忽略
多站点 Nginx 会根据 SNI 选择证书。如果客户端没有发送 SNI，或服务器的默认虚拟主机配置错误，可能返回另一站点的证书。
分别测试带 SNI 与指定地址的结果，可以确认服务器选择了哪张证书。查看证书域名：
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName不要只看证书的 Common Name。现代客户端主要依据 Subject Alternative Name 判断域名是否匹配，通配符证书也有明确匹配范围，通常不能跨越多级子域名。
如果 IPv4 与 IPv6 指向不同服务器，还应分别测试两个入口。部分设备优先走 IPv6，就可能拿到旧服务器或错误虚拟主机的证书，而只测 IPv4 的电脑看不出问题。
修复后的验收标准
修复后至少完成公网域名、源站入口、IPv4、IPv6和原异常设备的复测。每个入口应返回预期叶子证书与中间证书，域名匹配，验证结果正确。
再检查主域名、www 与接口子域名，确认没有某个虚拟主机继续使用旧文件。若通过 CDN 提供服务，应等待配置同步后从不同网络复测，并确认 DNS 已经没有残留旧地址。
最后记录证书文件来源、自动续期方式、部署位置和到期监控。只监控证书日期不够，还应定期从公网执行完整握手验证，因为续期成功但 Web 服务没有重新加载，也会继续返回旧证书。
这类故障的最终结论不应是证书重新上传后看起来正常，而应是所有预期入口返回同一套正确证书链，原异常设备能够建立信任，续期链路也经过一次验证。有效期只是其中一项，完整链路验证才是验收结果。
