apache 的 sslprotocol 指令需采用“白名单+显式启用”方式配置，推荐过渡期使用 sslprotocol +tlsv1.2 +tlsv1.3，禁用旧协议须显式排除；其生效依赖 openssl 版本（1.1.1w/3.0.x）及专用密钥套件，且须分阶段验证客户端兼容性。
Apache 中的 SSLProtocol 指令是控制 TLS 协议版本启用与禁用的核心配置项，它不支持“自动协商升级”，所谓“平滑升级”实际是指在保留兼容性的同时，逐步收紧协议范围，避免服务中断。关键在于显式声明、分阶段调整、配合客户端适配，并验证生效。
明确启用所需协议，禁用已淘汰版本
不要使用 all -SSLv3 -TLSv1 -TLSv1.1 这类模糊写法——它隐含依赖默认行为，且容易意外禁掉 TLS 1.2。应始终采用“白名单+显式启用”方式：
-
TLS 1.2 + TLS 1.3 共存（推荐过渡期）：
SSLProtocol +TLSv1.2 +TLSv1.3 -
仅 TLS 1.3（强安全要求场景）：
SSLProtocol +TLSv1.3（注意：Java 8 默认不支持，Android 4.4 及更早系统将断连） -
禁用旧协议必须显式排除：即使启用了新协议，也要确保旧协议未被意外继承，例如避免配置中残留
-SSLv2以外的其他宽松指令
配合密钥套件与 OpenSSL 版本严格对齐
协议启用只是第一步，真正能否成功协商取决于底层 OpenSSL 和密钥套件是否匹配：
- Apache 2.4.37+ 且链接 OpenSSL 1.1.1w 或 3.0.x 才能启用 TLS 1.3；仅升级 Apache 而不更新 OpenSSL 无效
- TLS 1.3 必须搭配专用套件，例如：
SSLCipherSuite TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 - 切勿将 TLS 1.2 套件（如
ECDHE-ECDSA-AES128-GCM-SHA256）与 TLS 1.3 套件混写在同一行，否则部分客户端会协商失败
分阶段上线并验证每个环节
一次关闭所有旧协议风险高，建议按“观察→限制→停用”三步走：
-
第一阶段（监控期）：启用
+TLSv1.2 +TLSv1.3，同时开启 Apache 日志中的 SSL 协商信息：LogLevel ssl:info，观察访问日志中SSL_PROTOCOL字段分布 -
第二阶段（限制期）：确认 TLS 1.2/1.3 占比超 99.5%，且无关键业务客户端报错后，可考虑移除 TLS 1.2（改为仅
+TLSv1.3） -
验证手段要多元：
- 终端测试：
openssl s_client -connect example.com:443 -tls1_2和-tls1_3分别验证 - 浏览器检查：F12 → Security 标签页查看当前连接协议
- 第三方扫描：SSL Labs Test 报告中 “Handshake Simulation” 明确列出各客户端实际协商结果
- 终端测试：
注意客户端兼容性边界
协议升级不是纯服务端行为，需同步评估下游调用方能力：
-
Java 应用：Java 11+ 默认支持 TLS 1.3；Java 8u261+ 需添加 JVM 参数
-Djdk.tls.client.protocols=TLSv1.3 - 移动客户端：iOS 12.2+、Android 10+ 原生支持；Android 4.4–9 需 App 层启用 Conscrypt 或自定义 SSLSocketFactory
- 嵌入式设备/API 网关：部分老旧 IoT 设备、Nginx 1.13 以下、APISIX 2.x 默认不支持 TLS 1.3，需升级或代理适配
