SSLInsecureRenegotiation on 是为极少数遗留客户端（如Java 6u45前、Android 4.4以下）临时妥协的安全退让，非推荐兼容方案；默认关闭，开启即放弃CVE-2009-3555防护，且仅在块内生效。
SSLInsecureRenegotiation 不是“提升兼容性”的推荐手段，而是为极少数遗留客户端临时妥协的安全退让；它默认关闭，开启即主动放弃对 CVE-2009-3555 的防护。
SSLInsecureRenegotiation on 必须写在 块内
这个指令不接受全局配置，也不能放进 .htaccess。如果你把它写在主配置文件顶部、或 ssl.conf 的 SSLEngine on 之前，Apache 启动时不会报错，但完全不生效。
- 必须放在启用 HTTPS 的
- 位置无严格顺序要求，但建议紧邻
SSLCertificateFile和SSLCertificateKeyFile，便于维护 - 写成
SSLInsecureRenegotiation off是冗余的——2.2.15+ 版本默认就是off，显式写出反而可能误导后续维护者
哪些客户端真会触发重协商？别靠猜，用 openssl 验证
现代浏览器（Chrome 30+、Firefox 25+、Safari 7+）、主流 HTTP 客户端（curl 7.40+、Java 8u161+）早已禁用不安全重协商，SSLInsecureRenegotiation on 对它们毫无影响。
- 真正依赖它的通常是：Java 6u45 以前版本、Android 4.4 以下 WebView、部分 IoT 设备 SDK、老旧银行/政务终端定制 UA
- 验证是否真被触发：运行
openssl s_client -connect example.com:443 -reconnect，若返回RENEGOTIATING并完成握手，说明客户端在尝试重协商 - 若连接直接中断并提示
SSL alert number 100，说明 Apache 拒绝了该请求——此时开on才有意义
前置 TLS 终止会让 SSLInsecureRenegotiation 完全失效
如果你用了 AWS ALB、Cloudflare、Nginx 作 TLS 终止代理，Apache 实际收到的是明文 HTTP 或后端 TLS 连接（由 LB 发起），原始重协商请求根本到不了 Apache 进程。
- 此时无论你配
SSLInsecureRenegotiation on还是off，都对客户端行为无影响 - 兼容性问题应转向 LB 层排查：ALB 默认禁用重协商；Cloudflare 的 “Origin SSL” 模式需确认是否启用了 client auth 回传
- Apache 日志里也看不到相关 renegotiation 记录，
SSLLogLevel info不会输出重协商事件
替代方案比开 SSLInsecureRenegotiation 更值得优先尝试
直接打开 SSLInsecureRenegotiation on 是最省事但风险最高的解法。多数情况下，问题根源不在 Apache 配置本身。
- 检查客户端是否真的需要重协商：绝大多数 Web 场景（静态资源、REST API、表单提交）根本不需要它；只有动态启用客户端证书认证时才可能触发
- 确认是否误配了
SSLVerifyClient require或SSLRequireSSL等强制校验指令，导致客户端在非必要路径上发起重协商 - 升级 OpenSSL 库：旧版 OpenSSL（如 0.9.8）存在实现缺陷，即使 Apache 配置正确，也可能误判重协商合法性
- 应用层绕过：Java 应用可禁用
SSLEngine.setNeedClientAuth(true)的运行时调用；Node.js 可设rejectUnauthorized: false（仅限测试）
真正容易被忽略的是：开了 SSLInsecureRenegotiation on 后，你无法再通过常规扫描工具（如 testssl.sh --reneg）确认服务是否“安全支持重协商”，因为结果会恒定显示 Secure renegotiation IS supported —— 它只告诉你协议层面能协商，不区分安全与否。这时候得靠抓包看 ClientHello 是否带 renegotiation_info 扩展，才能判断实际走的是哪条路。
