apache 不支持为不同 sni 域名单独指定 tls 加密套件,因套件协商发生在 sni 解析之前;可行方案包括分端口部署、分级证书引导或前置代理分流。
apache 本身不支持为不同域名(sni)单独指定 tls 加密套件(cipher suite)。sslprotocol 和 sslciphersuite 是全局或虚拟主机级指令,但它们作用于整个 ssl 上下文初始化阶段——而加密套件协商发生在 sni 域名被识别**之前**。
为什么不能按域名设加密套件?
TLS 握手流程决定了限制:
- 客户端在 ClientHello 中**先发送 SNI 域名**,但同时也**一并列出它支持的所有加密套件**
- 服务器必须在 ServerHello 阶段**立即回应一个双方都支持的套件**,此时才刚开始解析 SNI
- Apache/mod_ssl 在收到 ClientHello 后,会先用全局或监听端口级的 SSLCipherSuite 筛选候选套件,再根据 SNI 匹配虚拟主机——套件选择早于虚拟主机路由
- 也就是说:你无法让
site-a.com只用 ECDHE-ECDSA-AES128-GCM-SHA256,而site-b.com强制用 DHE-RSA-AES256-SHA —— 它们共享同一组可选套件列表
可行的变通方案
虽然不能“每个域名一套 cipher”,但可通过组合策略实现近似效果:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
-
分端口部署:为不同安全策略的域名分配不同 HTTPS 端口(如 443、8443、9443),每个
<virtualhost></virtualhost>块独立配置SSLCipherSuite。这是最直接、完全隔离的方式 - 分级证书 + 全局套件约束:用高兼容性套件覆盖全部域名(如含 TLS_AES_128_GCM_SHA256 和 ECDHE-RSA-AES256-SHA),再通过证书类型引导客户端行为——例如给旧系统域名配 RSA 证书,给新系统域名配 ECDSA 证书,客户端会自动优先选用匹配密钥类型的套件
- 前置代理分流:在 Apache 前加一层支持 per-SNI cipher 的网关(如 APISIX 或自定义 Nginx+OpenResty),由它完成 SNI 解析和差异化 TLS 参数设置,后端 Apache 只处理 HTTP 流量
注意实际影响范围
现代浏览器和主流客户端(curl ≥7.40、Java 8u252+、OpenSSL 1.1.1+)协商出的最终套件,取决于:
– 你配置的 SSLCipherSuite 排序
– 客户端 ClientHello 提供的套件列表
– 双方证书类型(RSA/ECDSA)与密钥交换算法兼容性
因此,合理设计全局套件列表(例如禁用弱算法、按优先级排序 ECDHE > DHE > RSA),比强行按域名拆分更有效且符合 TLS 规范。










