要通过PCI-DSS合规扫描，Nginx HTTPS配置必须禁用TLSv1.0/1.1、启用ECDHE前向保密套件（如ECDHE-RSA-AES256-GCM-SHA384）、强制Secure/HttpOnly/SameSite Cookie、注入HSTS与X-Content-Type-Options响应头，且所有指令须带always参数并经nginx -t校验。
要让 Nginx 的 HTTPS 配置通过 PCI DSS 合规扫描，关键不是证书本身有多“高级”，而是整个 TLS 通信链路必须满足几项不可协商的硬性要求：禁用不安全协议、启用前向保密加密套件、强制安全 Cookie 属性、注入关键响应头。证书只需是有效、由可信 CA 签发、使用 SHA-256 或更高签名算法的即可，重点在 nginx.conf 中的运行时行为控制。
禁用 TLSv1.0 和 TLSv1.1
这是 PCI DSS 最刚性门槛——只要配置中出现 ssl_protocols TLSv1（即 TLSv1.0）或 TLSv1.1，所有合规扫描工具（如 Qualys SSL Labs、myssl.com）都会直接判为不合规。
- 必须显式写为：
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、SHA1/MD5、EXPORT、NULL、ANONYMOUS、PSK、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
后端生成的 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=31536000; includeSubDomains; preload" always; - 内容类型保护：
add_header X-Content-Type-Options "nosniff" always; - 所有
add_header指令都需带always，确保跳转和错误响应中也生效
证书本身无需特殊定制，但必须由受信 CA 签发、未过期、域名匹配、私钥强度 ≥2048 位（RSA）或 ≥256 位（ECDSA），签名算法为 SHA-256 或更高。配置完成后，建议用 openssl s_client -connect yoursite.com:443 -tls1_2 实际验证协商结果，确认无禁用套件残留。
