用户提到的“证书域名与实际域名一一对应”确实是核心思路，但实际排查时，往往不是简单的“看两边是否一样”就能解决的。证书匹配涉及精确匹配、通配符规则、以及多域名（SAN）等细节。
下面我说一下一套系统化的排查步骤，帮用户快速定位问题：
第一步：确认浏览器实际访问的域名
检查地址栏：确保没有输错，例如把 `www.example.com` 输成了 `ww.example.com`。
注意端口：HTTPS默认443端口，但如果访问`https://example.com:8443`，证书仍按域名`example.com`匹配，端口不影响匹配结果。
看协议：确认是 `https://` 开头，而不是被强制跳转到的地址。
第二步：获取服务器上实际部署的证书信息
通过浏览器查看（最快捷）：
点击地址栏的🔒锁图标 → “连接是安全的” → “证书有效”（或类似选项）。
在证书详情中，找到 “颁发给” 或 “使用者” 字段，重点关注 公用名（CN, Common Name） 和 使用者可选名称（SAN, Subject Alternative Name）。
重要：现代浏览器（Chrome 58+、Safari 11+、Firefox 48+）只检查SAN字段，如果SAN中没有你的域名，即使CN匹配也会报错。
通过命令行查看（更准确）：
bash
# 替换成你的域名和端口（例如443）
openssl s_client -connect 你的域名:443 -servername 你的域名 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
结果示例：`DNS:example.com, DNS:www.example.com`
第三步：逐一核对匹配规则
拿到证书里的域名列表（SAN和CN）后，和浏览器访问的域名比较：
访问的域名 证书中需包含（满足任一即可） 常见错误理解
`example.com` 精确存在 `example.com` `*.example.com` 不能匹配 `example.com`（通配符不匹配裸域）
`www.example.com` 精确存在 `www.example.com` 或 `*.example.com` 通配符 `*.example.com` 可以匹配 `www.example.com`
| `api.abc.example.com` | 精确存在 `api.abc.example.com` 或 `*.abc.example.com` | 通配符 `*.example.com` 不能匹配三级子域名（只匹配一级子域）
`192.168.1.1` （IP） 证书SAN中必须精确包含 `IP:192.168.1.1` 为域名签发的证书不能用于IP访问（除非专门申请IP证书）
第四步：检查是否有多证书/多服务混淆
反向代理 / 负载均衡器：检查前端（如Nginx、HAProxy）和后端（实际应用）是否用了不同证书？客户端只和前端握手。
SNI（服务器名称指示）：如果服务器上托管多个HTTPS站点，老旧的客户端（如Windows XP+IE8）可能不支持SNI，会拿到默认证书而非匹配域名的证书。
CDN / 云WAF：确认CDN边缘节点配置的证书是否包含了你的域名，有时CDN会回源到IP导致显示源站的自签名证书。
第五步：特殊情况的快速检验
证书刚更新但浏览器仍报错：强制刷新（Ctrl+F5）或清除浏览器缓存（包括HSTS状态，Chrome访问 `chrome://net-internals/#hsts` 查询删除）。
通配符证书但包含两个点：*.example.com` 不是有效通配符，标准通配符只一个星号。
中文域名（IDN）：证书中存储的是 `xn--` 开头的punycode编码，例如 `中文.com` → `xn--fiq228c.com`，访问时要自动转码匹配。
如果以上都正确但仍然报错
那很可能不是“域名不匹配”问题，而是浏览器显示的错误信息有误导。请查看浏览器具体的错误代码：
`ERR_CERT_AUTHORITY_INVALID`：证书不被信任（缺中间证书或自签名）
`ERR_CERT_DATE_INVALID`：证书过期或系统时间错误
`ERR_CERT_COMMON_NAME_INVALID`：这才是真正的域名不匹配错误（现代浏览器已较少单独出现，多并入安全提示）
最后总结一下：域名匹配的核心是把“浏览器地址栏里的域名”与“证书SAN字段里的DNS名称”做精确字符串比较（通配符按规则展开）。90%的“不匹配”都是因为不小心访问了带www/不带www、多级子域名、或IP地址导致的。
