精准识别套件名四字段（密钥交换、签名算法、对称加密、哈希函数）可定位风险点，如ECDHE-RSA-AES128-SHA因SHA-1不安全须剔除，而ECDHE-RSA-AES128-SHA256合规；按BEAST/POODLE禁CBC、Sweet32禁3DES、Logjam禁弱DHE、全局禁RC4/EXPORT/NULL等分类过滤，并采用PCI-DSS验证通过的ECDHE-GCM/CHACHA20套件配置，辅以TLSv1.2+和严格校验确保生效。
直接依据安全扫描报告中列出的“不合规套件”名称，比照 OpenSSL 命名规则逐项剔除，比套用通用配置更准、更稳。关键不是删得越多越好，而是精准识别每个套件字段对应的风险点。
看懂套件名里的四个关键字段
例如 ECDHE-RSA-AES128-SHA，它由四段组成，每段代表一类密码学组件：
- ECDHE：密钥交换方式 → 支持前向保密，可保留
- RSA：签名算法 → 若服务端用 RSA 证书，此项合法；若用 ECDSA 证书，则应配 ECDHE-ECDSA
- AES128：对称加密 → AES128-GCM 安全，但 AES128-SHA 或 AES128-CBC 不安全
- SHA：哈希函数 → 表示 SHA-1，已禁用；-SHA256 和 -SHA384 可接受
所以 ECDHE-RSA-AES128-SHA 的问题在末尾的 -SHA，必须移除；而 ECDHE-RSA-AES128-SHA256 是合规的。
按漏洞类型批量剔除高危套件
扫描报告常归类为 BEAST、POODLE、Sweet32 等，每类对应明确缺陷，可针对性过滤：
-
BEAST / POODLE：所有 CBC 模式套件（如
-AES128-SHA、-AES256-SHA、-CAMELLIA128-SHA），一律禁用（除非强依赖 IE11/Win7 且无法升级） -
Sweet32：所有 64 位分组密码，典型是
DES-CBC3-SHA（即 3DES），必须清除 -
Logjam：含 DHE 且 DH 参数低于 2048 位的套件（如
DHE-RSA-AES128-SHA）→ 更稳妥做法是直接去掉所有 DHE，只留 ECDHE -
RC4 / EXPORT / NULL / aNULL / eNULL：全局禁用，无需犹豫，统一加前缀
!RC4:!EXPORT:!NULL:!aNULL:!eNULL
推荐的 PCI-DSS 合规 cipher 配置
以下配置经主流扫描器（如 Qualys SSL Labs、myssl.com）验证通过，兼顾安全性与现代客户端兼容性：
ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305";
配套必须设置：
- ssl_protocols TLSv1.2 TLSv1.3;（显式禁用 TLSv1.0 和 TLSv1.1）
- ssl_prefer_server_ciphers off;（避免客户端降级协商）
配置后务必执行 nginx -t 校验语法，再 nginx -s reload 生效；仅重启服务不保证热加载成功。
验证是否真正生效
不能只信配置文件，要实测确认：
- 用
openssl s_client -connect yourdomain.com:443 -tls1_2查看实际协商出的套件 - 提交至 SSL Labs 进行完整评分，重点关注 “Handshake Simulation” 中各客户端是否仍能协商出不合规套件
- 若发现旧客户端（如 IE11）仍连上不合规套件，说明配置未覆盖全部 server 块或被 include 覆盖，需逐层排查
