做支付接口对接的客户最近被退回了好几单合规审查，问题不在代码逻辑，全卡在SSL证书配置上。审计方给出的整改清单里，每一条都指向同一个根因：证书部署不规范。
PCI-DSS对SSL证书的核心要求
支付卡行业数据安全标准（PCI-DSS）要求所有传输持卡人数据的通道必须使用强加密。落到SSL证书层面，具体涉及三个维度：
第一，证书必须由受信任的CA机构签发，自签名证书直接判定不合格。第二，加密算法不能再用RSA 1024位或SHA-1，最低要求是RSA 2048位配合SHA-256。第三，TLS协议版本不能低于1.2，TLS 1.0和1.1必须关闭。
审计人员在检查时，通常会用OpenSSL命令行工具直接扫描你的域名，一行openssl s_client -connect就能暴露协议版本和证书链。如果你的服务器还在跑老配置，扫描结果会标红。
实际部署中最容易踩的三个坑
坑一：证书链不完整。很多运维人员只部署了域名证书，没带中间证书。浏览器靠缓存补全链条没问题，但PCI-DSS扫描器不会这么宽容，直接报“unable to verify the first certificate“。解决办法：向CA索要fullchain文件，或者手动拼接域名证书和中间证书，确保从叶节点到根节点完整。
坑二：证书域名和实际访问域名不匹配。这种情况多发于多子域名环境。比如证书签发给pay.example.com，但回调地址用的是api.example.com，扫描器一打就报CN不匹配。建议直接采购通配符证书（Wildcard），或者在证书SAN字段里把所有支付相关的子域名都列上。
坑三：到期未续签。PCI-DSS要求证书必须在有效期内，逾期哪怕一天也属于不合规事件。把证书到期日加进运维日历，提前30天启动续签流程，这个动作必须制度化。
合规自查清单
正式送审之前，建议跑一遍以下检查：
1. 用nmap --script ssl-enum-ciphers扫描服务器，确认只开放TLS 1.2及以上版本。
2. 在SSLLabs上做一次完整检测，目标拿到A评级。
3. 确认证书SAN列表覆盖所有对外暴露的支付域名。
4. 检查私钥权限是否限制在600，不能让非root用户读取。
PCI-DSS合规不是一次性考试，而是持续运营。SSL证书作为其中关键一环，部署规范了，后续的每轮复审都能少走弯路。