必须开启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 版本
