Apache中SNI默认证书错乱本质是TLS握手时未正确传递或识别Server Name，导致服务器返回非预期证书；需排查SNI启用状态、客户端是否发送、虚拟主机匹配顺序及旧客户端兼容性问题。
apache 中 sni 默认证书错乱，本质是客户端发起 tls 握手时未正确传递 server name，或服务器未按域名选择对应虚拟主机证书，导致浏览器收到非预期的证书（比如访问 site-a.com 却返回 site-b.com 的证书）。这不是证书本身无效，而是匹配逻辑失效。排查需聚焦“sni 是否启用、是否被识别、是否被正确路由”三个环节。
确认 SNI 在服务端已真正启用
仅加载 mod_ssl 不够，必须确保底层 OpenSSL 支持且 Apache 编译时启用了 SNI：
- 运行
httpd -V | grep -i "openssl\|sni"，检查 OpenSSL 版本 ≥ 1.0.2（推荐 ≥ 1.1.1） - 执行
httpd -M | grep ssl，确认ssl_module已加载（不是注释状态） - 检查配置中是否存在
Listen 443，且无重复或冲突监听（如同时有Listen *:443和Listen 192.168.1.10:443）
验证客户端是否发送了 Server Name 并被 Apache 接收
用 OpenSSL 模拟真实握手，强制指定 -servername 参数，观察返回的证书是否符合预期：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 测试目标域名：
echo | openssl s_client -connect your-server-ip:443 -servername site-a.com -showcerts 2>/dev/null | head -20 - 对比不带 -servername 的结果：
echo | openssl s_client -connect your-server-ip:443 -showcerts 2>/dev/null | head -20 - 若前者返回 site-a.com 证书、后者返回其他证书（如第一个定义的虚拟主机证书），说明 SNI 生效；若两者一致，说明 SNI 未触发或被忽略
检查虚拟主机加载顺序与默认捕获行为
Apache 按配置文件读取顺序匹配 <VirtualHost *:443>，最后一个未匹配的会成为“兜底”默认主机：
- 运行
apachectl -t -D DUMP_VHOSTS，查看实际生效的 HTTPS 虚拟主机列表及排序 - 重点检查是否有
<VirtualHost _default_:443>或未设ServerName的<VirtualHost *:443>块位于末尾 - 确保每个 HTTPS 虚拟主机都明确声明
ServerName example.com和必要ServerAlias www.example.com - 删除或注释掉无实际用途的默认 HTTPS 块，避免它无意中响应所有未匹配请求
排除客户端兼容性干扰
部分老旧环境无法发送 SNI，会回退到首个可用证书，造成“错乱”假象：
- 现代浏览器（Chrome/Firefox/Safari/Edge）、curl ≥ 7.18.1、OpenSSL ≥ 0.9.8j 均支持 SNI
- Windows XP + IE6/IE7、Android 2.x 系统浏览器等不支持 SNI，此时 Apache 必然返回第一个
<VirtualHost *:443>的证书 - 若只在特定旧设备上复现问题，基本可锁定为 SNI 不兼容，而非配置错误
