sslinsecurerenegotiation用于控制是否允许不安全tls重协商（cve-2009-3555风险），仅在确认老旧客户端（如jdk 6u45前）无法升级且报“re-negotiation requested but not allowed”时，于virtualhost内启用并严格限制来源。
Apache 中的 SSLInsecureRenegotiation 不是用来“支持旧版握手协议”的，而是控制是否允许**不安全的 TLS 重协商（insecure renegotiation）**——一种已被淘汰、存在 CVE-2009-3555 中间人劫持风险的机制。现代 TLS 握手（包括 TLS 1.2/1.3）本身是安全的，无需开启此选项；它只在极少数老旧客户端**强制发起非标准重协商**时才可能起作用。
什么情况下才需要启用 SSLInsecureRenegotiation
该配置仅适用于确认无法升级的遗留系统，且日志或客户端明确报错：
- Apache error log 出现
Re-negotiation requested but not allowed - Java 客户端（JDK 6u45 之前）、某些嵌入式设备或定制固件连接失败，错误含
SSL handshake failed或renegotiation rejected - 已排除证书、协议、SNI、防火墙等其他常见原因，且确定对方无法更新 TLS 实现
如何正确启用（仅限必要场景）
必须在启用 HTTPS 的 <virtualhost></virtualhost> 块内设置，不能写在 .htaccess 或全局非虚拟主机上下文中：
- 编辑站点配置文件（如
/etc/apache2/sites-enabled/example.com.conf） - 在
<virtualhost></virtualhost>内添加一行：SSLInsecureRenegotiation on - 确保该行位于
SSLEngine on、SSLCertificateFile和SSLCertificateKeyFile之后（顺序不影响功能，但便于维护） - 重启服务：
sudo systemctl reload apache2（Debian/Ubuntu）或sudo apachectl graceful（RHEL/CentOS）
启用后必须注意的安全折中
打开它等于主动放弃对 CVE-2009-3555 的防护，影响范围有限但风险真实存在：
- 仅对触发重协商的场景生效：例如客户端证书二次认证、部分反向代理或 LB 转发行为
- 现代浏览器（Chrome 30+、Firefox 25+）、OpenSSL 1.0.1+、TLS 1.3 全部不使用该机制，开了也无实际效果
- 若前端有 TLS 终止设备（如 Cloudflare、AWS ALB），Apache 根本收不到原始重协商请求，此配置完全无效
- 务必限制访问来源，避免暴露给不可信网络；建议配合
SSLStrictSNIVHostCheck on强化主机校验
更推荐的替代方案
优先尝试绕过重协商依赖，而非降低服务端安全性：
- 升级客户端：JDK 6u45+、Android 5.0+ WebView、主流 IoT SDK 均已支持 RFC 5746 安全重协商
- 调整客户端逻辑：避免在已建立连接上发起重协商，改用新连接或 HTTP 头传递认证信息
- 前置代理处理：用 Nginx 或 HAProxy 在边缘层完成兼容性适配，让 Apache 保持默认安全策略
- 检查是否误配：某些 Java 应用因
HttpsURLConnection.setHostnameVerifier或自定义 SSLSocketFactory 导致异常重协商，修复代码比改 Apache 更治本
