VirtualHost级别无法按域名精确启用双向认证，因TLS握手发生在Host头解析前，SSLVerifyClient指令作用于IP:Port绑定而非域名；可行方案包括统一设optional_no_ca后用Require expr按HTTP_HOST和SSL_CLIENT_VERIFY动态控制，或为双向站点分配独立IP/端口并直接设require。
虚拟主机本身不支持直接配置 sslverifyclient 实现双向证书认证（mtls），因为该指令是 apache 的全局或服务器级（<virtualhost></virtualhost>）指令，但它的生效逻辑依赖于底层 ssl/tls 握手阶段——而握手发生在 host 头解析之前，此时 apache 还不知道请求要路由到哪个虚拟主机。
为什么 VirtualHost 级别无法真正“按站点”启用双向认证
HTTPS 连接建立时，客户端先完成 TLS 握手（含证书交换和验证），之后才发送 HTTP 请求（含 Host 头）。Apache 在握手阶段就必须决定是否要求客户端证书，而此时它尚未进入虚拟主机匹配流程。因此：
– SSLVerifyClient require 若写在某个 <virtualhost></virtualhost> 块中，实际作用于该 IP:Port 绑定的所有连接；
– 若同一 IP:Port 托管多个 HTTPS 虚拟主机（SNI 场景），所有站点都会触发客户端证书验证，无法仅对某一个开启；
– 即使使用 SNI，TLS 层的证书验证策略仍由监听端口的主配置决定，不能按域名动态切换。
可行的替代方案：按域名实现逻辑上的“特定站点”双向认证
虽然无法在 TLS 层精确按域名开关验证，但可通过组合配置，在应用层达成等效效果：
-
统一开启客户端证书验证 + 条件跳过：在
<virtualhost></virtualhost>或<ssl></ssl>上下文中设置SSLVerifyClient optional_no_ca（不强制校验 CA，只收证书），再用SSLRequire或Require expr结合%{SSL_CLIENT_VERIFY}和%{HTTP_HOST}做运行时判断。例如：
SSLVerifyClient optional_no_ca<br>SSLVerifyDepth 1<br><br><Location "/><br> # 仅对 api.example.com 强制验证通过的客户端证书<br> Require expr %{HTTP_HOST} != 'api.example.com' || \<br> (%{SSL_CLIENT_VERIFY} == 'SUCCESS' && %{SSL_CLIENT_S_DN_CN} =~ /CN=trusted-api-client/)<br></Location>这样，非目标域名可直通，目标域名则检查证书有效性及 DN 字段，未提供或验证失败即返回 403。
更干净的做法：为双向认证站点分配独立 IP 或端口
若条件允许，这是最符合语义且无歧义的方式：
- 给需双向认证的站点绑定专用 IP（如
192.168.1.100:443），其他站点用另一 IP（如192.168.1.101:443）； - 在对应
<virtualhost></virtualhost>中直接配置：SSLVerifyClient requireSSLVerifyDepth 2SSLCACertificateFile /path/to/ca.crt - 客户端必须提供被该 CA 签发的有效证书才能完成握手，天然隔离于其他站点。
注意事项与调试要点
– 确保启用 mod_ssl 和 mod_authz_core；
– 使用 SSLVerifyClient optional_no_ca 时，务必配合 SSLOptions +StdEnvVars 才能在表达式中读取 %{SSL_CLIENT_*} 变量；
– 浏览器访问会弹出证书选择框，API 调用建议用 curl 指定 --cert client.pem --key client.key --cacert ca.crt；
– 日志中开启 SSLLogLevel info 可查看握手阶段证书验证详情（注意生产环境避免 info 级别日志泄露敏感信息）。
