必须同时配置SSLProtocol和SSLCipherSuite并启用SSLHonorCipherOrder、SSLCompression off，且依赖OpenSSL≥1.1.1支持TLSv1.3与现代套件，否则安全评级不达标。
SSLProtocol 和 SSLCipherSuite 配置必须同时调整
只禁用弱加密套件但保留旧版协议（如 SSLv2/SSLv3），安全评级仍会掉到 B 或更低。Apache 的 SSLProtocol 控制协议版本，SSLCipherSuite 控制具体算法组合，二者缺一不可。
推荐配置如下：
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
-
SSLProtocol中的all表示启用所有支持的协议，再用减号逐个剔除不安全版本；TLSv1.2 是当前最低可用底线，TLSv1.3 需 Apache ≥ 2.4.37 + OpenSSL ≥ 1.1.1，单独启用需加+TLSv1.3 -
SSLCipherSuite推荐优先选带ECDHE和GCM的套件，保证前向保密（PFS）和 AEAD 安全性；避免出现RC4、MD5、SHA1、DES、3DES等关键词 - 配置后务必用
apachectl configtest检查语法，否则 reload 会失败
OpenSSL 版本决定你能用哪些加密套件
Apache 自身不实现密码学，它依赖底层 OpenSSL 库。如果系统 OpenSSL 太老（比如 CentOS 7 默认的 1.0.2k），即使配置了 TLSv1.3 或 CHACHA20-POLY1305 套件，也会静默忽略。
验证方法：
openssl version -a
- OpenSSL ≥ 1.1.1 才支持 TLSv1.3 和现代 AEAD 套件（如
AEAD-CHACHA20-POLY1305-SHA256） - 某些发行版（如 Debian 10、Ubuntu 20.04）默认已升级，但 CentOS/RHEL 7 需手动编译或换源（如 IUS 或 Remi）
- 运行
openssl ciphers -s -V 'ECDHE-ECDSA-AES128-GCM-SHA256'可确认该套件是否被当前 OpenSSL 实际识别
别漏掉 SSLHonorCipherOrder 和 SSLCompression
仅靠 SSLCipherSuite 不足以确保客户端按你指定的优先级使用强套件。Apache 默认接受客户端首选项，必须显式开启服务端排序；另外，压缩功能曾导致 CRIME 攻击，必须关闭。
- 添加
SSLHonorCipherOrder on，强制服务器按SSLCipherSuite顺序选择，而非迁就客户端 - 添加
SSLCompression off，禁用 TLS 层压缩（注意不是 HTTP 压缩，后者由mod_deflate管理） - 这两项虽小，但在 Qualys SSL Labs 测试中直接影响“BEAST vulnerability”和“Cipher Suite Order”两项评分
测试结果和常见误判点
配置生效后，用 https://www.ssllabs.com/ssltest/ 扫描是最直接的方式，但要注意几个容易误读的地方：
- 显示 “TLS 1.3: Yes” 不代表你配置了它——Apache 2.4.37+ 且 OpenSSL 1.1.1+ 下，TLSv1.3 是自动启用的，无需写进
SSLProtocol，写了反而可能报错 - 如果看到 “WEAK KEY EXCHANGE” 警告，大概率是用了 RSA 密钥交换（如
RSA-AES128-SHA），必须换成ECDHE开头的套件 - 某些 CDN（如 Cloudflare）会终止 TLS 并用自己的证书重加密，此时测的是 CDN 配置，不是你 Apache 的真实设置
真正起作用的永远是 OpenSSL 实际加载的套件列表，而不是配置文件里写了什么——所以每次改完都建议用 openssl s_client -connect yoursite.com:443 -tls1_2 手动连一次看协商结果。
