SSLOptions 不控制证书算法或协议版本，仅透传SSL信息；真正决定旧算法兼容性的是SSLProtocol（协议）、SSLCipherSuite（套件）和证书签名/密钥类型三类配置。
apache 的 ssloptions 指令 不提供开启“legacy证书算法”的功能，也无法通过它启用如 sslv2、sslv3、md5 签名、sha-1 证书签名、rsa-keyexchange-only 等已被现代 tls 标准弃用的旧算法。
SSLOptions 控制的是 SSL/TLS 握手完成后，Apache 向 CGI/PHP/脚本环境透传哪些 SSL 相关信息（如证书内容、协议版本、加密套件名称等），它本身不参与密码套件协商、不修改握手行为、也不影响证书验证逻辑。
所以，所谓“通过虚拟主机配置 SSLOptions 开启 Legacy 证书算法”是一个常见误解——SSLOptions 与算法兼容性完全无关。
真正决定是否支持老旧算法的，是以下三类配置：
✅ 1. TLS 协议版本控制（关键）
Apache 使用 SSLProtocol 指令启用或禁用协议版本。若需兼容极老客户端（如 Windows XP + IE6、某些嵌入式设备），可能需临时启用已废弃的协议：
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
⚠️ 注意：
-
+TLSv1.0或+TLSv1.1可能被要求，但它们存在已知漏洞（POODLE、BEAST、ROBOT），不建议在生产环境启用。 -
SSLv2/SSLv3在 Apache 2.4.38+ 中默认彻底移除，无法启用。
✅ 2. 密码套件选择（直接影响算法）
使用 SSLCipherSuite 和 SSLHonorCipherOrder on 显式指定允许的加密套件。例如兼容旧系统可加入：
SSLCipherSuite ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA:DES-CBC3-SHA SSLHonorCipherOrder on
? 说明：
-
RC4-SHA、DES-CBC3-SHA属于高风险/弱强度套件，现代浏览器和服务端普遍禁用； -
AES128-SHA是 TLS 1.0–1.2 中仍被部分旧设备依赖的“最低可行”安全套件； - 若后端应用（如 Java 6 / OpenSSL 0.9.8）只支持 RSA 密钥交换且无前向保密，需保留
ECDHE以外的RSA套件（如AES128-SHA）。
✅ 3. 证书签名与密钥兼容性（常被忽略）
老旧后端（如某些银行中间件、Java 6/7、.NET Framework 2.0）可能：
- 不识别 SHA-256 以上签名的证书（需用 SHA-1 签发 —— ❌ 已被所有主流 CA 停止签发）；
- 拒绝 ECDSA 证书，仅接受 RSA 2048；
- 要求证书链中包含特定根/中级 CA（如 VeriSign Class 3、Entrust 2048）。
? 应对方式：
- 使用 RSA 2048 私钥 + SHA-256 证书（当前兼容性最佳平衡点）；
- 若必须 SHA-1，只能自建私有 CA（不适用于公网）；
- 确保
SSLCACertificateFile或SSLCACertificatePath包含目标后端信任的完整中间证书链（尤其避免缺失“交叉签名”证书）。
❌ 补充澄清：SSLOptions 能做什么？不能做什么？
| 它能做的 | 它不能做的 |
|---|---|
+StdEnvVars：注入 SSL_PROTOCOL, SSL_CIPHER, SSL_VERSION 等变量 |
修改 TLS 握手过程或算法选择 |
+ExportCertData：把客户端证书 PEM 内容写入 SSL_CLIENT_CERT 环境变量 |
让服务器接受 MD5 签名的客户端证书 |
+OptRenegotiate：优化重协商行为 |
绕过现代 OpenSSL 对弱 DH 参数的拦截 |
? 提示：若后端报错如
java.security.cert.CertificateException: Certificates does not conform to algorithm constraints，问题一定出在 JVM 的java.security策略文件或jdk.tls.disabledAlgorithms设置，而非 Apache 的SSLOptions。
不复杂但容易忽略。
