apache中密码套件选择需平衡安全强度、客户端兼容性与协议支持,策略作用范围为全局或虚拟主机,必须搭配sslprotocol使用并启用sslhonorcipherorder on,优先选用pfs和aead模式套件,禁用rsa密钥交换、cbc模式及弱哈希算法。

选密码套件不是挑越多越好,而是要兼顾安全强度、客户端兼容性、协议版本支持三者平衡。Apache 本身不支持按请求动态换套件,策略生效范围是全局或单个虚拟主机,所以得先明确你的服务对象和安全底线。
看清楚协议基础再定套件
密码套件必须和 SSLProtocol 搭配使用,否则配置无效。比如你启用了 TLSv1.3,那套件里写一堆只支持 TLSv1.2 的 ECDHE-RSA-AES256-SHA 就没意义;反过来,若仍需兼容 Windows 7 + IE11,就得保留部分 TLSv1.2 下的强套件,但绝不能开 TLSv1.0/1.1。
- 等保三级或生产环境:强制 SSLProtocol TLSv1.2 TLSv1.3,禁用所有旧协议
- 内部系统或测试环境:可临时放宽为 all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1,但仍建议尽快收敛
- 务必加上 SSLHonorCipherOrder on,否则客户端可能选到列表里靠后的弱套件
优先选带前向保密(PFS)和 AEAD 模式的套件
前向保密保证即使服务器私钥泄露,历史通信也不会被解密;AEAD(如 AES-GCM、CHACHA20-POLY1305)比传统 CBC 模式更安全、更高效。RSA 密钥交换(如 RSA-AES)已不推荐,应替换为 ECDHE 或 DHE。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 推荐组合(TLSv1.2+):ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
- 避免出现:RSA(密钥交换)、CBC(如 AES128-CBC-SHA)、MD5/SHA1(哈希)、DES/3DES(分组算法,受 Sweet32 影响)
- 别用 ALL 或 HIGH 这类模糊指令,它们会隐式包含已被淘汰的算法
根据实际访问端做取舍
不是所有用户都用最新 Chrome。如果你的服务有政企客户、老旧内网设备或嵌入式终端,需做兼容性验证,而不是一刀切。
- 纯现代环境(Chrome/Firefox/Safari 最新版 + Android/iOS 主流系统):可只留 TLSv1.3 原生套件(如 TLS_AES_256_GCM_SHA384),或精简 TLSv1.2 套件
- 需兼容 Win7+IE11 / Java 7u95 等老客户端:保留 ECDHE-RSA-AES128-GCM-SHA256,并确保 OpenSSL 版本 ≥ 1.0.2u(CentOS 7 默认满足)
- 调试阶段可用 openssl s_client -connect example.com:443 -tls1_2 -cipher 'ECDHE' 快速验证某类套件是否被接受
验证是否真正生效
改完配置后,浏览器地址栏显示“锁”图标 ≠ 套件正确。很多弱套件仍能握手成功,只是不该被选中。
- 用命令行确认协商结果:openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | grep Cipher
- 跑一次 apachectl configtest 再 systemctl reload httpd,避免语法错误导致降级回默认配置
- 用 SSL Labs Test 扫描域名,它会明确标出哪些套件被启用、是否存在降级风险、是否支持 OCSP Stapling 等细节










