域名与证书不匹配源于证书SAN字段未覆盖访问域名，需检查证书SAN、Apache的ServerName/ServerAlias配置、虚拟主机顺序及证书文件完整性。
域名主体与证书不匹配，是 Apache HTTPS 访问时最直观的报错之一——浏览器直接弹出“您的连接不是私密连接”“NET::ERR_CERT_COMMON_NAME_INVALID”等提示。问题不在证书不能用，而在于它根本没覆盖你正在访问的那个域名。
核对证书实际覆盖的域名
证书是否包含当前请求的完整主机名，取决于其 Subject Alternative Name（SAN） 字段，而非过时的 Common Name（CN）。现代浏览器已基本忽略 CN，只认 SAN。
- 用浏览器点击地址栏锁图标 → “连接安全” → “证书有效” → 查看“使用者备用名称”列表，确认里面是否有 exact 匹配 的域名（如
www.example.com和example.com需分别列出，不能互相替代） - 命令行快速验证：
openssl x509 -in server.crt -text -noout | grep -A1 "Subject Alternative Name" - 若只申请了
example.com，但用户访问的是www.example.com，就必须补上 www 或改用通配符证书（*.example.com）
检查 Apache 虚拟主机配置是否绑定正确
即使证书本身支持多域名，Apache 也必须把该证书明确关联到对应 <virtualhost></virtualhost> 块中，且 ServerName 和 ServerAlias 必须与访问域名一致。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 每个 HTTPS 虚拟主机块内需显式设置：
ServerName example.com和ServerAlias www.example.com - 确保没有其他虚拟主机块意外捕获请求——比如末尾存在未禁用的
<virtualhost _default_:443></virtualhost>，它会返回默认证书，导致“访问 A 却看到 B 的证书” - 运行
apachectl -t -D DUMP_VHOSTS查看实际生效的虚拟主机顺序和匹配规则
确认证书文件内容未被误替换或截断
有时证书文件看似存在，但内容已被覆盖、格式损坏，或混入了多余空格/注释，导致 Apache 解析时无法识别 SAN 字段。
- 打开
server.crt文件，确认开头是-----BEGIN CERTIFICATE-----，结尾是-----END CERTIFICATE-----，中间无乱码、无换行错误 - 避免用 Windows 记事本编辑证书文件（易插入 BOM 或转为 ANSI 编码），推荐用 vim、nano 或 VS Code（UTF-8 无 BOM）
- 若使用 Let’s Encrypt 的 fullchain.pem，确保它由域名证书 + 中间证书按顺序拼接而成；单独用
cert.pem（不含链）会导致部分客户端校验失败，间接表现为“域名不匹配”假象
排除 SNI 与旧客户端兼容性干扰
极少数情况下，用户使用老旧系统（如 Windows XP + IE6）访问多域名共用 IP 的 HTTPS 站点，因不支持 SNI，服务器可能返回默认证书，从而触发域名不匹配警告。
- 这不是配置错误，而是协议限制。现代环境（Chrome/Firefox/Safari/Edge 及 iOS/Android 主流浏览器）均支持 SNI
- 可通过
openssl s_client -connect example.com:443 -servername example.com模拟标准 SNI 请求，验证服务端是否返回预期证书 - 如确需兼容非 SNI 客户端，只能为该域名分配独立 IP，并配置专用虚拟主机
