CDN 开了之后 HTTPS 证书报错，别急着甩锅源站

CDN 接入后 HTTPS 报错，现场最常见的反应是：源站证书是不是过期了？其实不一定。浏览器看到的证书，很多时候是 CDN 节点返回的证书，不是源站直接返回的证书。

这里要先把链路拆开。用户访问域名时，DNS 解析到 CDN 节点，浏览器和 CDN 节点建立 TLS 连接；CDN 节点再去回源，可能用 HTTP，也可能用 HTTPS。也就是说，HTTPS 证书至少可能出现在两段链路里。

用户浏览器 ⇄ CDN 节点，这一段看的是 CDN 上配置的边缘证书。CDN 节点 ⇄ 源站，这一段看的是源站证书，以及 CDN 回源时是否校验证书。

所以问题不一定在源站，也不一定在 CDN，得看报错发生在哪一段。

浏览器直接报证书不匹配，大概率先看 CDN 节点证书

如果用户打开网站，浏览器提示 NET::ERR_CERT_COMMON_NAME_INVALID、证书域名不匹配、证书不是颁发给当前域名，这类报错多数发生在用户到 CDN 节点这一段。

实际使用中发现，很多人源站证书配得很正常，直接访问源站 IP 或者源站域名也没问题，但一切到 CDN 就报错。原因是 CDN 控制台里没有给加速域名绑定正确证书，或者绑定了别的域名证书。

举个现场场景：example.com 接入 CDN，控制台上传的是 www.example.com 的证书，但用户访问的是 example.com。证书里 SAN 没有 example.com，浏览器就会报域名不匹配。反过来也一样，证书只覆盖 example.com，不覆盖 www.example.com，访问 www 也会出问题。

还有一种很隐蔽：CDN 上同一个证书被复用到多个域名，业务调整时删了 SAN 或换了证书，但 CDN 节点缓存、证书部署还没完全同步。部分地区正常，部分地区报错，这种很像网络问题，其实是节点证书未完全生效。

怎么判断是不是 CDN 边缘证书的问题

最直接的办法是看浏览器里展示的证书颁发对象和 SAN 列表。如果证书里没有当前访问域名，问题基本就在 CDN 侧证书配置。

也可以用 openssl 查 CDN 节点返回的证书：

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

这里的 -servername 很关键，它会带上 SNI。现在 CDN 都是多域名共用节点 IP，没有 SNI 很可能拿到默认证书，排查结果会误判。

输出里重点看 subject、issuer、X509v3 Subject Alternative Name。如果 SAN 里没有你的域名，或者拿到的是 CDN 默认测试证书、其他业务域名证书，就是边缘证书问题。

CDN 回源用 HTTPS 报错，用户看到的可能是 502 或 526

另一类问题不是浏览器直接提示证书不可信，而是页面打不开，CDN 返回 502、525、526、SSL handshake failed、origin SSL error 之类。这种多半发生在 CDN 节点到源站这一段。

这里补充一点，不同 CDN 厂商的错误码不完全一样。有的会直接显示 origin certificate invalid，有的只给一个 502。如果 CDN 日志能看到回源 TLS 握手失败，方向就很明确了。

常见原因包括：源站证书过期、源站证书链不完整、源站证书和回源 Host 不匹配、源站只支持太老的 TLS 版本、源站没有正确处理 SNI。

比如 CDN 配置的回源 Host 是 origin.example.com，但源站 Nginx 上绑定的证书只包含 www.example.com。CDN 回源时校验证书，发现证书不匹配，就会拒绝连接。用户这边看到的是 CDN 报错，但根因在源站证书配置。

源站证书链不完整也很常见

很多源站上只配置了站点证书，没有带 intermediate certificate。浏览器访问时有时候能自动补链，看起来没问题；但 CDN 节点回源校验证书时不一定帮你补，直接判定证书链不完整。

Nginx 里如果使用的是 ssl_certificate，建议放 fullchain.pem，而不是只放 cert.pem。Apache、负载均衡、WAF 后面也是一样的思路：让服务端完整返回证书链，别指望客户端补。

排查时可以在一台外部机器上执行：

openssl s_client -connect origin.example.com:443 -servername origin.example.com -showcerts

如果输出里 Verify return code 不是 0，或者提示 unable to get local issuer certificate，就要检查证书链。

证书没过期但还是报错，重点看 Host、SNI、回源协议

证书排查不能只看有效期。很多事故里，证书有效期还有 80 天，但业务还是挂了。真正的问题在域名匹配和 SNI。

CDN 回源时通常会有三个相关配置：源站地址、回源 Host、回源协议。源站地址可以是 IP，也可以是域名；回源 Host 决定 HTTP Host 头，也经常影响 TLS SNI；回源协议决定 CDN 是 HTTP 回源还是 HTTPS 回源。

如果源站地址填 IP，回源 Host 填 www.example.com，但 CDN 回源 TLS 的 SNI 没带 www.example.com，源站可能返回默认证书。这个默认证书也许是 default.local，也许是另一个业务域名，CDN 校验时就失败。

实际排查时要问 CDN 厂商一个问题：HTTPS 回源时，SNI 用的是回源 Host，还是源站地址？不同平台实现不一样，有些控制台还有单独的“回源 SNI”开关。

HTTP 回源和 HTTPS 回源不是一个风险级别

如果 CDN 到源站使用 HTTP 回源，源站证书就不参与这一段连接。用户浏览器只和 CDN 建立 HTTPS，看到的是 CDN 证书。这种模式配置简单，但 CDN 到源站之间是明文传输，不适合登录、支付、后台、API Token 这类数据。

如果使用 HTTPS 回源，链路更安全，但源站证书、证书链、SNI、TLS 版本都要配对。生产环境里建议 HTTPS 回源，尤其是跨境业务、游戏账号系统、电商后台、管理面板，不要为了省排查时间长期裸奔 HTTP 回源。

按报错现象分，锅一般在这里

浏览器提示证书域名不匹配：优先看 CDN 边缘证书是否覆盖访问域名。

浏览器提示证书过期：看浏览器展示的证书到底是谁返回的。如果证书颁发给的是 CDN 上配置的加速域名，那就是 CDN 侧证书没更新或未同步；如果绕过 CDN 访问源站也过期，那源站也要更新。

CDN 返回 502、525、526：重点看 CDN 到源站的 HTTPS 回源。源站证书、fullchain、回源 Host、SNI、TLS 版本都要查。

部分地区报错，部分地区正常：看 CDN 节点证书同步状态、DNS 是否有残留、是否存在多家 CDN 混用、是否有部分解析还打到旧平台。

手机报错，电脑正常：看客户端系统根证书库、证书链兼容性、是否用了较新的 CA 或 ECDSA-only 证书。老 Android 对某些链路兼容性比较差，尤其是业务面向海外用户时要多测几个系统版本。

一个现场排查路径，基本能把责任段定位出来

看浏览器拿到的证书

不要先登录源站改配置，先点开浏览器证书详情。看证书颁发给谁、SAN 包含哪些域名、有效期、颁发机构。浏览器看到的就是用户到 CDN 节点这一段的结果。

如果这里已经不对，源站改半天也没用。应该去 CDN 控制台检查加速域名绑定的证书，确认是否覆盖裸域、www、API 子域名、泛域名。

绕过 CDN 测源站

本地 hosts 把域名指向源站 IP，再访问 HTTPS。这样可以模拟用户直接访问源站，但要注意：如果源站靠 CDN 回源 Host 区分站点，直接用 IP 访问不准，必须带域名。

也可以用 curl 指定解析：

curl -v --resolve www.example.com:443:源站IP https://www.example.com/

这个命令比直接访问 https://源站IP 更靠谱，因为它同时保留了 Host 和 SNI。

看 CDN 回源日志

如果 CDN 有边缘日志或实时日志，直接筛选 5xx。关注字段包括 origin_status、ssl_protocol、ssl_cipher、upstream_connect_time、error_message。看到 certificate verify failed、handshake failure、unknown ca、no alternative certificate subject name matching 之类，就去源站证书和回源 SNI。

有些 CDN 控制台只显示“回源失败”，日志不够细。这个时候可以临时把回源协议改成 HTTP 验证一下。如果 HTTP 回源立刻正常，HTTPS 回源异常，问题基本锁定在源站 TLS 配置，不是业务程序挂了。

CDN 证书配置里容易踩的坑

泛域名证书不覆盖裸域

*.example.com 覆盖 a.example.com、api.example.com，但不覆盖 example.com。裸域需要单独放进 SAN。这个问题很高频，尤其是 Let's Encrypt 自动签发时只签了泛域名，没加 root domain。

证书更新了，但 CDN 没有切到新证书

源站证书自动续期不代表 CDN 边缘证书自动续期。除非 CDN 使用的是托管证书并完成 DNS 验证，否则源站 renew 之后 CDN 仍可能拿着旧证书继续服务。

很多故障发生在凌晨证书过期后，源站 certbot 已经续上了，但 CDN 证书是人工上传的旧文件。用户访问还是报过期，因为用户根本没碰到源站证书。

证书文件和私钥不匹配

上传 CDN 证书时，如果 certificate 和 private key 不是一对，有的平台会直接拒绝，有的平台提示不明显。源站 Nginx 也一样，reload 时可能失败，结果服务仍使用旧证书。

可以用 openssl 对比 modulus，确认 cert 和 key 是否匹配。

ECC 证书兼容性

ECDSA 证书性能好，但老客户端兼容性不如 RSA。现在多数 CDN 支持 RSA + ECDSA 双证书，能根据客户端能力自动选择。如果业务面向老设备、海外低版本 Android、嵌入式终端，别只上 ECDSA。

源站线路不稳时，HTTPS 报错会被误判成证书问题

多说一句，CDN 开启 HTTPS 回源后，源站网络质量也会影响 TLS 握手。丢包、跨境抖动、TCP 建连慢，可能表现为 handshake timeout、connection reset。表面看是 SSL error，实际是源站网络不稳。

跨境业务特别明显。用户在国内，CDN 节点在国内或亚太，源站放在美国、德国、新加坡，如果普通国际线路晚高峰丢包高，HTTPS 回源比 HTTP 更容易暴露问题，因为多了一段 TLS 握手，超时窗口更敏感。

这类场景选源站时别只看 CPU 和内存，线路要一起看。比如面向国内用户的海外站点，源站可以优先考虑 CMIN2、CN2 GIA、精品网这类回国质量更稳定的线路。如果你也在找这种海外云服务器、G 口大带宽服务器或高防服务器，可以看看129云，像美国精品网-A型走 CMIN2，2C 2G、50G SSD、50Mbps 峰值带宽，适合轻量站点、API、跨境业务测试；德国双ISP-G型带 1Gbps，GTT 直连，适合对欧洲访问和带宽有要求的业务。需要确认线路和防护场景，可以直接问客服热线 400-9177118。

多 CDN 或迁移 CDN 时，证书问题更容易乱

很多证书报错不是单 CDN 造成的，而是迁移过程中 DNS 没切干净。

比如 A 记录还残留到旧 CDN，CNAME 一部分解析到新 CDN，某些地区 Local DNS 缓存还没过期。用户访问同一个域名，不同网络拿到不同节点。新 CDN 证书正常，旧 CDN 证书已经删除或过期，于是出现“有人正常，有人报错”。

这种情况要查权威 DNS，而不是只在自己电脑 ping 一下。

dig yourdomain.com +trace

dig yourdomain.com @8.8.8.8

dig yourdomain.com @114.114.114.114

dig yourdomain.com @1.1.1.1

再配合 openssl 看不同解析结果返回的证书。只要发现不同 IP 或不同 CNAME 返回不同证书，就不是单纯源站问题。

回源 Host 配错时，源站看起来正常，CDN 就是不正常

源站上经常跑多个站点，Nginx 通过 server_name 区分。用户直接访问 www.example.com 正常，因为 SNI 和 Host 都是 www.example.com。但 CDN 回源时，如果 Host 被配置成 origin.example.com，源站可能命中另一个 server block。

命中错站点后会发生两类问题：HTTP 层返回错内容，或者 TLS 层直接返回错证书。后者就会被 CDN 判定为源站证书错误。

排查时看源站 Nginx access log 很有用。确认 CDN 回源请求带的 Host 是什么。不要只看业务日志，TLS 握手失败时请求可能还没进入应用层，业务日志里什么都没有。

证书链路排查时常用的判断口径

用户浏览器里看到的证书错了，CDN 边缘侧优先。

绕过 CDN 直连源站证书错了，源站侧优先。

浏览器证书正常但 CDN 返回 5xx，HTTPS 回源优先。

同域名不同地区返回不同证书，DNS、CDN 节点同步、多 CDN 残留优先。

源站证书没过期但 CDN 说 invalid，查 SAN、fullchain、SNI、回源 Host。

生产环境里建议这样配

边缘证书用 CDN 托管证书

如果 CDN 支持自动签发和自动续期，边缘证书尽量用托管证书。手工上传证书不是不能用，但证书到期前必须有监控和提醒，不能靠人记。

泛域名、裸域、www、api、static 这些域名要一次性确认覆盖范围，尤其是业务经常新增子域名时，证书 SAN 管理要跟着发布流程走。

源站使用完整证书链

源站 Nginx、Apache、负载均衡都使用 fullchain。不要只配站点证书。每次续期后做一次 reload 检查，确认服务实际返回的是新证书。

可以把 openssl 检查加进巡检脚本，提前 15 天、7 天、3 天报警。证书过期不是复杂故障，但它造成的影响很直接，用户看到红色拦截页基本就不会继续访问。

HTTPS 回源时明确 SNI

CDN 控制台如果有回源 SNI 配置，就显式填写和源站证书匹配的域名。不要让平台自动猜，尤其是源站地址填 IP、回源 Host 又是另一个域名时。

源站 Nginx 默认站点也要处理好。default_server 不要挂一个无关证书，至少放一个覆盖主业务域名的证书，减少 SNI 异常时的误伤。

跨境源站别忽略线路质量

HTTPS 回源对网络稳定性更敏感。源站如果放海外，普通线路在晚高峰出现 3% 到 8% 丢包，就可能引发间歇性 502、TLS 握手超时、资源加载失败。业务量不大时不明显，并发一上来就开始暴露。

游戏、电商、企业站、API 服务这类业务，源站线路建议提前压测。BGP、CN2、GIA、CMIN2、GTT 直连这些不是宣传词，实际差异会反映在 TCP 建连、TLS 握手、回源首包时间上。

别把所有 HTTPS 报错都归到证书本身

证书只是 HTTPS 链路里的一个环节。TLS 版本不兼容、Cipher Suite 不匹配、源站 443 端口被安全组拦截、WAF 回源策略错误、DDoS 清洗后端口映射不一致，都可能被前端包装成 SSL 相关错误。

源站只支持 TLS 1.0，CDN 强制 TLS 1.2 以上回源，会握手失败。源站只开了某些老 Cipher，CDN 不接受，也会失败。安全组只放行了办公 IP，没有放行 CDN 回源 IP 段，表现也是回源 HTTPS 不通。

还有高防场景，清洗节点前后如果证书终止位置变了，也要重新确认。TLS 是在高防节点终止，还是透传到源站，还是 CDN 终止后再 HTTPS 回源，这三种证书配置完全不同。

实际处理时不要反复改配置，先固定变量

遇到 CDN HTTPS 报错，最怕的是边查边改：一会儿换源站证书，一会儿改 CDN 证书，一会儿切回源协议，一会儿刷新 DNS。变量太多，后面即使恢复了，也不知道真正原因是什么。

建议先保留现场，抓浏览器证书、openssl 结果、CDN 日志、源站日志。确认是哪一段 TLS 出问题后再动配置。改完只验证一个变量，比如只换 CDN 边缘证书，就只测用户到 CDN；只改回源 SNI，就只测 CDN 到源站。

证书报错看起来是一个弹窗，后面其实是 DNS、CDN、TLS、源站 Web Server、线路质量一起参与。把用户到 CDN、CDN 到源站这两段拆开看，基本就不会在源站和节点之间来回甩锅。