通配符证书在二级域名下出现“不信任”提示，问题通常不出在通配符本身，而在于证书链是否完整送达、nginx是否正确加载、以及浏览器能否构建完整信任路径；需确认san包含目标域名、ssl_certificate指向fullchain.pem且顺序为域名证书→中间证书（非根证书）、server_name严格匹配、代理透传sni与host头。
通配符证书在二级域名下出现“不信任”提示，问题通常不出在通配符本身，而在于证书链是否完整送达、Nginx是否正确加载、以及浏览器能否构建完整信任路径。关键不是证书能不能用，而是它有没有被“正确呈现”给客户端。
确认通配符证书实际覆盖目标二级域名
通配符 *.example.com 只匹配一级子域名（如 api.example.com、blog.example.com），不匹配：
- 根域名 example.com（需单独加入 SAN 或另配证书）
- 三级域名 dev.api.example.com
- 带端口或路径的变体（如 api.example.com:8443）
用命令检查证书 SAN 是否含当前访问域名：
openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -text -noout | grep -A1 "Subject Alternative Name"
输出中必须明确列出你正在访问的完整二级域名。
验证 Nginx 是否发送了完整且顺序正确的证书链
浏览器报“不安全”，90% 是因为只收到了终端证书，没收到中间证书。Nginx 的 ssl_certificate 必须指向 fullchain.pem，不能是 cert.pem。
- 运行 openssl s_client -connect api.example.com:443 -showcerts，观察输出中的 BEGIN CERTIFICATE 块数量和顺序
- 第一块必须是你的二级域名证书（Subject=CN=api.example.com）
- 第二块起应为 Let’s Encrypt R3 等中间证书（Issuer 匹配上一块的 Subject）
- 最后一块不能是根证书（如 ISRG Root X1）
若只看到一块，说明 Nginx 没加载 fullchain.pem；若顺序颠倒或混入 root CA，也会触发不信任。
检查 server_name 与证书使用的严格对齐
Nginx 不会“智能选证”，它靠 server_name 匹配来决定启用哪个 SSL 上下文：
- 每个二级域名建议配置独立的 server 块：
server_name api.example.com; - 避免把多个不相关的域名塞进同一个 server_name 列表
- 防止未定义的二级域名被默认 server 块捕获——它可能返回的是另一个域名的证书
例如，若 www.example.com 的 server 块排在最前且设为 default_server，而用户访问 api.example.com 又未明确定义，则会错用 www 的证书，必然不匹配。
排除代理链中 SNI 和 Host 头干扰（如前端有 CDN 或反向代理）
如果请求经过 CDN、WAF 或上层 Nginx 代理，可能影响后端证书验证逻辑：
- 确保代理透传原始 Host 头：添加 proxy_set_header Host $host;
- 若后端服务也走 HTTPS（即 Nginx 作为客户端连后端），需额外配置：
proxy_ssl_server_name on;
proxy_ssl_name "api.example.com";
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; - 此时 proxy_ssl_name 必须与后端证书 SAN 完全一致，大小写、通配符都不能差
不复杂但容易忽略
