当用户直接访问 domain2.com（不带www）时，移动端浏览器在发起HTTP请求前就因证书域名不匹配而阻断连接，此时Apache的.htaccess重写规则根本不会执行——问题根源在于SSL证书未包含该主域名作为Subject Alternative Name（SAN）。
当用户直接访问 `domain2.com`（不带www）时，移动端浏览器在发起http请求前就因证书域名不匹配而阻断连接，此时apache的`.htaccess`重写规则根本不会执行——问题根源在于ssl证书未包含该主域名作为subject alternative name（san）。
现代浏览器（尤其是iOS Safari、Android Chrome）在建立HTTPS连接的TLS握手阶段，会严格校验证书中的域名是否与请求主机名完全匹配。这一校验发生在任何HTTP层逻辑（包括Apache的mod_rewrite）介入之前。这意味着：
- 用户在地址栏输入 http://domain2.com 或 https://domain2.com；
- 浏览器立即尝试TLS握手，并向服务器发送ClientHello；
- 服务器返回当前配置的SSL证书（仅含 www.domain2.com 和 domain1.com, www.domain1.com）；
- 浏览器发现证书的 SAN 列表中不含 domain2.com，即刻终止连接，弹出“您的连接不是私密连接”等红色警告；
- 此时 .htaccess 中的 RewriteCond 和 RewriteRule 完全未被触发——因为请求甚至未到达Apache的HTTP处理模块。
✅ 正确解决方案：补全证书的 SAN（Subject Alternative Name）
SSL证书必须显式包含所有需保护的域名。针对 domain2.com，你需要确保其主域名（裸域）被加入证书的 SAN 字段。操作步骤如下：
-
重新申请或续订证书，在CSR生成或CA控制台填写时，务必同时添加：
domain2.com www.domain2.com
⚠️ 注意：仅设置 Common Name (CN) = www.domain2.com 已不足够。自2015年起，主流CA及浏览器已强制要求使用 SAN 字段，且 CN 不再参与域名匹配校验。
-
部署完整证书链：
确保上传至服务器的不仅是 domain2.com.crt，还包括全部中间证书（Intermediate CA），通常以 fullchain.pem 形式提供。Nginx 示例配置：ssl_certificate /path/to/fullchain.pem; # 包含域名证书 + 中间证书 ssl_certificate_key /path/to/privkey.pem;
Apache 示例：
SSLCertificateFile "/path/to/domain2.com.crt" SSLCertificateChainFile "/path/to/intermediate.crt" # 或合并进SSLCertificateFile SSLCertificateKeyFile "/path/to/privkey.pem"
-
验证证书覆盖范围：
部署后，使用在线工具如 SSL Labs SSL Test 或终端命令确认：openssl x509 -in domain2.com.crt -text -noout | grep -A1 "Subject Alternative Name"
输出应类似：
X509v3 Subject Alternative Name: DNS:domain2.com, DNS:www.domain2.com
❌ 常见误区与规避建议
- 不要依赖重定向绕过证书问题：.htaccess 的 301 重定向无法解决 TLS 层校验失败，它只在 HTTPS 连接成功建立后才生效。
- 不要禁用客户端证书校验（如WebView中调用 handler.proceed()）：这等于关闭安全警报，使用户暴露于中间人攻击风险。
- 避免混合方案：若暂时无法更新证书，切勿通过HTTP跳转（如 http://domain2.com → https://www.domain2.com），因HTTP明文传输可能被劫持或降级。
? 总结：SSL证书的域名覆盖是HTTPS可信链的基石。对于多域名/多子域名站点，务必采用*多域名证书（UCC）或通配符证书（`.domain2.com）**，并在申请时穷举所有必需主机名。只有证书本身具备domain2.com` 的 SAN 条目，移动端与桌面端才能一致、安全地完成TLS握手，后续的重写规则、WordPress逻辑等才得以正常运行。
