sslinsecurerenegotiation是apache mod_ssl中控制不安全tls重协商的开关，默认关闭以防范cve-2009-3555；仅当确认老旧客户端（如jdk 6u45前）无法升级且日志出现重协商拒绝错误时，才在virtualhost内启用并严格限定范围。
sslinsecurerenegotiation 是 apache mod_ssl 中控制是否接受不安全 tls 重协商的开关，默认关闭，目的是防范 cve-2009-3555 攻击。它不是“兼容性补丁”，而是一种有明确安全代价的妥协手段——仅当确认老旧客户端（如 jdk 6u45 之前版本、某些嵌入式设备或定制 sdk）无法升级，且连接失败日志中反复出现 re-negotiation requested but not allowed 或 ssl handshake failed 时，才考虑启用。
确认是否真需要开启
现代浏览器（Chrome 30+、Firefox 25+、Safari 7+）、OpenSSL 1.0.1+、Java 6u45 及之后版本均支持 RFC 5746 安全重协商，根本不会触发该配置生效的路径。开启它对这些客户端毫无影响，也起不到“修复”作用。
- 检查错误日志：只在 Apache error.log 中看到明确的 renegotiation 拒绝提示，且能 100% 确认是某类旧设备/老 Java 客户端发起的请求
- 排查前置代理：若使用 Cloudflare、AWS ALB、Nginx 做 TLS 终止，Apache 实际收不到原始重协商报文，此配置完全无效
- 优先尝试替代方案：比如让客户端改用新建连接代替重协商，或升级其 TLS 库
在虚拟主机中正确启用
该指令必须写在启用 HTTPS 的 <virtualhost></virtualhost> 块内，不能放在全局上下文或 .htaccess 中，也不支持写 off（默认就是 off，显式写出反而易引发误解）。
- 编辑站点配置文件（如
/etc/apache2/sites-enabled/example.com.conf） - 确保已启用 SSL：包含
SSLEngine on，以及有效的SSLCertificateFile和SSLCertificateKeyFile - 在同一
<virtualhost></virtualhost>块中添加一行：SSLInsecureRenegotiation on - 保存后执行
sudo systemctl reload apache2（Debian/Ubuntu）或sudo apachectl graceful（RHEL/CentOS）
启用后的关键注意事项
打开这个开关，等于主动放弃对 CVE-2009-3555 的防护。它的风险不是理论上的，而是真实可利用的中间人攻击面。
- 只影响实际发生重协商的场景：例如客户端证书二次认证、某些负载均衡器转发策略、或旧版 Java 客户端在长连接中动态切换权限
- 不等于“放宽所有 SSL 校验”：其他安全配置（如
SSLProtocol all -SSLv2 -SSLv3、SSLStrictSNIVHostCheck on）仍需保留并生效 - 务必限制暴露范围：仅在必须兼容的特定虚拟主机中开启，不要全局启用；若同一 IP 上有多个 HTTPS 站点，避免配置合并导致意外继承
验证与替代建议
启用后不能仅靠“连得上”判断成功，要确认是否真的绕过了问题，同时观察是否有异常行为。
- 用
openssl s_client -connect example.com:443 -reconnect测试，若返回RENEGOTIATING并完成握手，说明已生效；若中断或报 alert 100，则未起效 - 更可靠的方式是用
testssl.sh --reneg example.com，结果应显示 Insecure renegotiation is supported（注意：这是你主动开启后的预期结果，不是漏洞） - 长期来看，应推动客户端升级或改用支持安全重协商的通信方式，而不是依赖此配置维持旧系统运行
