Nginx的SSL/TLS安全等级由ssl_protocols、ssl_ciphers、证书链完整性、OCSP Stapling和私钥权限五项共同决定，缺一不可；任一缺失均可能导致等保不通过或sslscan暴露漏洞。
直接用命令验证最可靠，不依赖第三方网站或主观判断。关键不是“有没有HTTPS”，而是协议、套件、证书链、密钥交换这些细节是否真正落地。
检查 TLS 协议是否启用正确版本
只写 ssl_protocols TLSv1.2; 不会自动启用 TLSv1.3——Nginx 严格按配置执行，不会补全。
- 运行：
openssl s_client -connect example.com:443 -tls1_3 -servername example.com 2>/dev/null | grep "Protocol"，应输出Protocol : TLSv1.3 - 同样测试 TLSv1.2：
openssl s_client -connect example.com:443 -tls1_2 -servername example.com 2>/dev/null | grep "Protocol" - 若任一失败，说明对应协议未生效，需确认
ssl_protocols TLSv1.2 TLSv1.3;写在server块内（非http块顶层）
验证密码套件是否禁用弱算法
仅设 ssl_ciphers 不够，必须配合 ssl_prefer_server_ciphers on;，否则客户端仍可协商出服务端不希望的旧套件。
- 用
nmap --script ssl-enum-ciphers -p 443 example.com扫描，结果中不能出现： -
TLS_RSA_*（无前向保密） - 含
SHA1、MD5、RC4、3DES的条目 - 推荐套件示例：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
确认证书链是否完整
浏览器报 NET::ERR_CERT_AUTHORITY_INVALID 很可能不是证书无效，而是中间证书缺失。
- 检查命令：
openssl crl2pkcs7 -nocrl -certfile /etc/nginx/ssl/example.com.crt | openssl pkcs7 -print_certs -noout - 正常应输出至少两段证书（域名证书 + 中间证书）
- Let’s Encrypt 用户必须使用
fullchain.pem作为ssl_certificate，而非单独的cert.pem - 私钥权限必须为
600，否则 Nginx 启动时可能静默降级或拒绝加载
验证 OCSP Stapling 和 ECDH 曲线
这两项虽不直接影响基础连接，但关系到等保测评和高级攻击防护。
- OCSP Stapling：配置
ssl_stapling on;和ssl_stapling_verify on;，并确保resolver可达（如resolver 8.8.8.8 1.1.1.1 valid=300s;） - ECDH 曲线：加
ssl_ecdh_curve secp384r1;或更优的X25519，避免客户端 fallback 到不安全曲线 - 验证 OCSP 是否生效：
openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null | grep -A 17 "OCSP response"，应看到OCSP Response Status: successful
