SSLInsecureRenegotiation是Apache中允许不安全TLS重协商的兼容性开关，启用后可使JDK 6u45前等老旧客户端连通，但会主动放弃对CVE-2009-3555的防护，须严格限定作用域并配套加固。
Apache 中的 SSLInsecureRenegotiation 不是“支持旧版握手的安全迁移”手段，而是一个有明确安全代价的兼容性开关：它允许服务端接受不带 RFC 5746 安全重协商扩展的 TLS 重协商请求，从而让某些无法升级的老客户端（如 JDK 6u45 前、部分嵌入式设备）连通，但会主动放弃对 CVE-2009-3555 的防护。所谓“安全迁移”，实际是指在必须启用它的前提下，通过最小化影响范围和强化其他环节来控制风险。
确认是否真需要开启 SSLInsecureRenegotiation
很多问题被误判为重协商失败，实则源于证书链缺失、SNI 不匹配或协议版本不兼容。只有当满足全部条件时，才考虑启用：
- 日志中持续出现
Re-negotiation requested but not allowed或客户端明确报SSL handshake failed，且复现可稳定触发重协商（如需客户端证书认证、代理二次协商等场景） - 客户端确实无法升级——例如运行在封闭固件中的 Java 6u43、Android 4.0 内置 WebView、或某款停产工业网关
- 该客户端流量可控、可信，且不涉及高敏操作（如支付、管理后台）
- 前置没有 TLS 终止设备（如 Cloudflare、AWS ALB），否则 Apache 根本收不到原始重协商请求，此配置无效
仅在必要虚拟主机中启用并严格限定作用域
SSLInsecureRenegotiation 是 per-vhost 指令，不能写在全局配置或 .htaccess 中。必须在启用 HTTPS 的 <VirtualHost> 块内显式设置：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 确保
SSLEngine on已启用，且SSLCertificateFile和SSLCertificateKeyFile已正确配置 - 在同一个
<VirtualHost>块中添加：SSLInsecureRenegotiation on - 不要在其他虚拟主机中复制该行；若多个站点共用 IP+端口，只对那个特定老客户端访问的域名单独配置
- 禁用
SSLInsecureRenegotiation off—— 它无意义，因为默认就是 off，显式写出反而易引发误解
配套加固措施降低潜在风险
开启后，CVE-2009-3555 的攻击面即存在。需通过其他配置收窄暴露路径：
- 禁用已淘汰协议：
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1（保留 TLSv1.2+） - 启用 SNI 强校验：
SSLStrictSNIVHostCheck on，防止域名混淆类中间人试探 - 限制重协商触发条件：避免在业务逻辑中主动调用
SSL_renegotiate()；如使用客户端证书认证，改用首次握手完成认证，而非连接建立后再协商 - 配合防火墙或 WAF 规则，对该虚拟主机的访问来源做白名单限制（如仅允特定 IP 段或用户代理）
验证配置生效与行为边界
重启 Apache 后，不能仅靠“能连上”判断成功，要确认它按预期工作且未过度放行：
- 用
openssl s_client -connect example.com:443 -reconnect测试：若返回RENEGOTIATING并继续握手，说明重协商被接受；若直接断开或报ssl alert number 100，说明仍被拒绝 - 运行
testssl.sh --reneg example.com：结果应为Secure renegotiation IS supported（表示安全重协商可用），同时Insecure renegotiation项显示OK（表示不安全重协商也被接受） - 检查 Apache error log，确认无重复警告，且只在目标客户端访问时出现重协商相关日志
