如何为 Apache 配置 SSL 加密套件的顺序优化

必须开启SSLHonorCipherOrder on，否则客户端可强制协商弱套件；需在VirtualHost内配置，配合明确SSLCipherSuite（如ECDHE-RSA-AES128-GCM-SHA256等）和TLSv1.2+协议，并用openssl实测验证。

Apache 的 SSL 加密套件顺序不是“列出来就行”，而是决定客户端最终协商出哪个套件的关键开关。顺序优化的核心目标是：让安全强度高、性能好、前向保密强的套件优先被选中，同时确保老设备仍有可用路径——不靠堆砌，而靠排序+强制+分层。

必须开启服务端优先权（SSLHonorCipherOrder）

即使你写了一串完美的套件列表，如果没启用这一项，Apache 就会听客户端的——它可能强行选一个排在自己列表最前面的弱套件（比如 AES128-SHA），导致你的高强度配置完全失效。

• 在虚拟主机或主配置中添加：SSLHonorCipherOrder on
• 这是所有套件顺序生效的前提，缺一不可
• 检查是否生效：用 openssl s_client -connect yoursite.com:443 -cipher 'AES128-SHA' -tls1_2 测试，若连接成功但实际协商结果不是该套件，说明服务端排序已起作用

按能力分组设计套件链（TLSv1.2 最小可行集）

现代客户端（Chrome/Firefox/Safari/Android 7+）普遍支持 ECDHE + AES-GCM；旧环境（Java 7、Windows 7 SP1、Android 4.4）则依赖 RSA 密钥交换和 SHA-256 摘要。推荐使用以下明确、无歧义的写法：

• ECDHE-ECDSA-AES128-GCM-SHA256：适配 ECDSA 证书，高性能 AEAD
• ECDHE-RSA-AES128-GCM-SHA256：主流 RSA 证书路径，PFS + GCM
• ECDHE-ECDSA-AES256-GCM-SHA384：更高密钥长度，兼容 Safari 15+/iOS 15+
• ECDHE-RSA-AES256-GCM-SHA384：同上，RSA 证书版本
• ECDHE-RSA-AES128-SHA256：兜底给旧 Java 客户端（如 Java 8u251 以下）
• AES128-GCM-SHA256：极少数无 ECDHE 支持的场景（冗余项，可选）

整行写为：
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256

禁用模糊表达与危险组合

像 HIGH、ALL、!aNULL:!MD5 这类通配写法看似省事，实则危险——它们随 OpenSSL 版本动态变化，可能在升级后意外引入 RC4、DES-CBC3-SHA 或非前向保密套件。

• 永远用具体、带连字符的完整套件名，不缩写、不泛指
• 显式排除已知风险项：不用 SHA1 摘要、不带 -CBC- 的模式（除非绝对必要且理解风险）
• 不混用 TLSv1.3 和 TLSv1.0/1.1 套件——OpenSSL 可能静默降级或握手失败

协议版本需与套件严格对齐

套件能否生效，取决于协议是否支持。例如 AES-GCM 套件只在 TLSv1.2+ 中可用；而 TLSv1.3 使用全新套件命名体系（如 TLS_AES_128_GCM_SHA256），不能和 TLSv1.2 混写。

• 若只支持现代客户端：SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 +TLSv1.3
• 若需兼容旧设备：仅在独立虚拟主机中启用 TLSv1.0/1.1，并配专属套件（如 ECDHE-RSA-AES128-SHA），绝不与 TLSv1.3 共存
• 确认 OpenSSL 版本 ≥ 1.1.1 才能真正启用 TLSv1.3；phpEnv 等 Windows 集成环境需实测验证，不能只看 Apache 版本