通配符证书在nginx中报net::err_cert_common_name_invalid，主因是证书san未覆盖根域或二级子域、server块未按域名关系分设、误用cert.pem而非fullchain.pem。需用openssl验证san字段，根域与泛域应分设server块，跨主域必须独立配置，且所有块须明确listen 443 ssl http2并启用sni。
通配符证书在 Nginx 中出现“绑定异常”，比如浏览器提示 NET::ERR_CERT_COMMON_NAME_INVALID 或小锁图标不显示，通常不是证书无效，而是证书链与配置未对齐。核心问题在于：通配符证书本身能力有限、Nginx 的 server 块结构不匹配、证书文件选错这三者叠加导致“看似配了，实则没生效”。
确认证书是否真正覆盖目标域名
通配符 *.example.com 只能匹配一级子域（如 api.example.com、www.example.com），不自动包含根域 example.com，也不覆盖二级子域（如 dev.api.example.com）。
- 用命令检查证书 SAN 字段：
openssl x509 -in /etc/letsencrypt/live/example.com/cert.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
每个域名单独配一个 server 块
Nginx 不会根据 Host 头动态切换证书；它靠 SNI 在 TLS 握手阶段决定返回哪个证书。如果把多个不兼容的域名塞进同一个 server_name 列表（例如 server_name a.com b.net;），SNI 就无法精准路由，容易错发证书。
- 根域和泛域建议分设两个块：一个专配
example.com，另一个配*.example.com（实际仍用同一份 fullchain.pem） - 跨主域（如
site-a.com和site-b.net）必须各自独立 server 块，不可共用 ssl_certificate 指令 - 所有 HTTPS server 块都要明确写
listen 443 ssl http2，避免被 default_server 拦截错发证书
必须使用 fullchain.pem，且顺序不能错
Let’s Encrypt 等 CA 的证书是三级链：你的域名证书 → 中间证书（R3）→ 根证书（ISRG Root X1）。浏览器需要完整路径才能信任。只配 cert.pem 就等于只交了“身份证”，没交“派出所开具的证明”。
- 配置中必须写：
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; -
fullchain.pem内容顺序应为：你的证书（cert.pem）在最前，中间证书（chain.pem）紧随其后，不包含根证书 - 验证是否生效：
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep "BEGIN CERTIFICATE" | wc -l—— 正常应输出 ≥2
抓包确认 SNI 是否真实发送目标域名
即使配置全对，如果客户端（比如旧版安卓 App、某些内网工具）没发 SNI，或 DNS 解析指向了错误 IP，Nginx 仍可能回退到 default_server 的证书，造成错配。
- 用 Wireshark 或 tcpdump 抓 TLS 握手包，过滤
tls.handshake.type == 1，看 Client Hello 中的 SNI 字段是否为你期望的域名 - 测试时加
-servername参数模拟正确行为：openssl s_client -connect example.com:443 -servername api.example.com - 若 SNI 正确但证书仍错，说明对应域名的 server 块未命中——检查
server_name拼写、大小写、空格及是否被其他块拦截
