通配符证书在Nginx中“看似能用、实际错配”的根源在于证书覆盖范围、server块隔离与SNI分发逻辑未对齐:需验证SAN含DNS:example.com和DNS:*.example.com,每个域名独占server块,使用fullchain.pem,抓包确认SNI匹配目标域名。
通配符证书在 Nginx 中“看似能用、实际错配”是高频问题,根源不在证书本身,而在域名覆盖范围、server 块隔离和 SNI 分发逻辑是否对齐。排查要从证书能力边界出发,逐层验证 Nginx 是否真把对的证书交给了对的请求。
通配符 *.example.com 仅匹配一级子域名,不自动包含根域或二级以上子域。必须用命令检查证书 SAN 列表:
openssl x509 -in conf/ssl/example.com.fullchain.pem -text -noout | grep -A1 "Subject Alternative Name"
DNS:example.com(根域)和 DNS:*.example.com;若需支持 dev.api.example.com,则必须有 DNS:dev.api.example.com 或 DNS:*.api.example.com
Nginx 不会根据 Host 头自动挑选证书。把多个域名写进同一个 server_name 列表(如 server_name a.com b.com;),会导致 SNI 握手阶段无法精准绑定,浏览器可能拿到其他域名的证书。
www.example.com、api.example.com、example.com 各自建独立 server 块server_name,并指向同一份 fullchain.pem 和 privkey.pem
listen 443 ssl,且未启用 default_server 冲突只配 cert.pem 是常见错误。现代浏览器要求服务器返回完整链(自身证书 + 中间证书),否则握手失败或显示不安全警告。
ssl_certificate conf/ssl/example.com.fullchain.pem(不是 cert.pem)600(Linux)或防杀软拦截(Windows)nginx -t 确认语法通过,再 nginx -s reload,避免配置未生效浏览器访问 https://api.example.com 时,Nginx 必须在 TLS 握手阶段向客户端声明 SNI = api.example.com,否则客户端可能缓存或 fallback 到默认证书。
tls.handshake.type == 1,查看 Client Hello 中的 SNI 字段值www.example.com),说明某个 server 块被意外设为 default_server,或 DNS 缓存/Hosts 文件干扰了请求目标