pci-dss 合规 https 配置需禁用 tlsv1.0/1.1、启用前向保密套件（如 ecdhe-aes256-gcm-sha384）、强制 secure/httponly/samesite cookie、注入 hsts 与 x-content-type-options 响应头，且所有指令须带 always 参数并经 nginx -t 校验。
要让 HTTPS 通过金融级 PCI-DSS 合规审计，关键不是堆砌高强度参数，而是精准满足几项不可协商的硬性要求：禁用 TLSv1.0、启用前向保密套件、强制安全 Cookie 属性、注入关键响应头。配置错误哪怕只有一处，扫描工具（如 Qualys SSL Labs、myssl.com）就会直接判定“不合规”。
禁用 TLSv1.0 和 TLSv1.1
这是 PCI-DSS 最刚性门槛，自 2018 年 6 月 30 日起强制生效。只要 ssl_protocols 中出现 TLSv1（即 TLSv1.0）或 TLSv1.1，所有合规扫描均失败。
- 必须显式写为：ssl_protocols TLSv1.2 TLSv1.3;
- 删除所有含 TLSv1、TLSv1.1 的旧模板，包括注释中的残留写法
- 执行 nginx -t 校验语法，再用 nginx -s reload 生效（仅重启服务不保证热加载）
配置 PCI-DSS 认可的加密套件
不能只看“AES256”就认为安全——必须同时满足密钥交换（ECDHE）、对称加密（AES-GCM 或 CHACHA20-POLY1305）、哈希（SHA256+）三重约束，并彻底剔除禁用组件。
- 必须删除含以下关键词的套件：RC4、3DES、DES、-SHA（即 SHA1）、-MD5、EXPORT、NULL、ANONYMOUS、CBC 模式（如 -AES128-SHA）
- 推荐且经扫描验证通过的配置：ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384";
- 必须启用：ssl_prefer_server_ciphers on;（防客户端降级）
- 建议补充：ssl_ecdh_curve secp384r1;（避免协商弱曲线）
强制注入 Secure/HttpOnly/SameSite Cookie
后端生成的 Set-Cookie 在反向代理场景下极易丢失 Secure 标志，PCI-DSS 要求所有会话 Cookie 必须同时具备这三个属性，且必须覆盖所有响应类型（含 302、4xx）。
- 使用 add_header Set-Cookie "JSESSIONID=$sessionid; Path=/; HttpOnly; Secure; SameSite=Lax" always;
- always 参数不可省略——否则仅对 2xx 响应生效
- 若需前端 JS 读取部分 Cookie（如刷新令牌），应拆分命名：敏感会话 ID 设 HttpOnly，控制类 Cookie 单独定义并豁免
启用 HSTS 与 X-Content-Type-Options 响应头
这两项是扫描高频扣分项，缺一不可，且参数必须符合最小作用域与有效期要求。
- HSTS：add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
- 内容类型保护：add_header X-Content-Type-Options "nosniff" always;
- 两项都必须带 always，确保跳转、错误等非 2xx 响应也生效
