如何用Nginx配置提升SSL Labs证书评级到A+？

SSL Labs提供的服务器测试工具通过模拟客户端握手，从证书有效性、协议支持度、密钥交换机制、加密套件强度、前向保密能力以及常见漏洞暴露面等多个维度，对站点的HTTPS实现进行量化评分。许多运维人员在接入Nginx反代或网关之后，发现评级停留在B甚至更低，其根本原因往往不是证书本身不可信，而是TLS协议栈的暴露面过大或者加密协商策略过于宽松。理解评分模型的权重分布，才能有针对性地调整Nginx指令。

协议版本与加密套件的精简策略

SSL Labs对支持已被证明不安全的旧版协议（如TLS 1.0和TLS 1.1）的服务器会直接扣减大量分数，因为这些协议容易受到降级攻击和已知密码学弱点影响。在Nginx中，应当显式声明只启用TLS 1.2和TLS 1.3。通过ssl_protocols指令可以精确控制，避免使用默认值中残留的旧协议。与此同时，加密套件（Cipher Suite）的选择决定了密钥交换与对称加密的强度，评分系统偏好支持前向保密（PFS）的ECDHE系列套件，而单纯使用RSA密钥交换的套件会被标记为弱项。

在配置套件时，推荐将TLS 1.3的套件独立用ssl_conf_command或默认内置列表管理，而对TLS 1.2使用经过筛选的ECDHE套件。下面给出一个兼顾兼容性与高评分的示例，其中剔除了CBC模式套件以降低BEAST类攻击风险，并优先采用AES-GCM与ChaCha20-Poly1305这类AEAD算法。

server {
    listen 443 ssl http2;
    server_name example.ipipp.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    # 仅启用安全协议
    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS1.2使用的强套件，启用ECDHE前向保密
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # 优先服务端套件顺序
    ssl_prefer_server_ciphers on;

    # TLS1.3套件（Nginx 1.19+支持）
    ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
}

上述配置在SSL Labs中通常能拿到协议支持与加密强度项的满分。需要注意的是，若业务必须兼容极旧客户端，勉强开启TLS 1.0会让评级无法超过B，此时应通过独立旧域名或CDN边缘处理遗留流量，而不是在主站妥协。

证书链完整性与OCSP装订优化

证书链不完整是初级部署中最常见的扣分项。Nginx的ssl_certificate指向的文件必须包含服务器证书以及所有中间证书，顺序为服务器证书在前、中间证书依次在后。如果只放了叶子证书，部分客户端会出现未知颁发者错误，SSL Labs也会在“证书链”一项标红。使用Let's Encrypt等免费证书时，应直接采用fullchain.pem而非cert.pem。

另一个影响评级但常被忽略的点是OCSP装订（OCSP Stapling）。开启后，Nginx在握手时主动提供证书吊销状态的签名证明，既保护了客户端隐私，也向评分系统展示了良好的运维实践。配置时需要指定受信任的证书签发者文件，并开启ssl_stapling_verify以确保装订内容可被校验。以下片段展示了标准做法：

ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver 223.5.5.5 119.29.29.29 valid=300s;
resolver_timeout 5s;

如果未配置ssl_trusted_certificate，Nginx无法验证OCSP响应，装订会失效。此外，证书有效期过长（如超过一年）虽不直接扣分，但现代评分趋势鼓励短周期轮换，配合自动化续期脚本可进一步降低运维风险。对于使用泛域名证书的站点，还需确认SAN字段覆盖了所有对外主机名，否则特定子域访问会触发评级警告。

会话复用、HSTS与安全响应头配合

SSL Labs对会话恢复机制的考察主要集中在是否支持安全的会话复用。Nginx默认提供TLS会话票据（Session Ticket）与会话ID缓存，但票据密钥若长期不轮换，会削弱前向保密意义。建议通过ssl_session_ticket_key指定一个定期更换的随机文件，或暂时关闭票据仅用共享内存缓存。同时设置合理的ssl_session_cache与超时时间，可在不损失安全性的前提下提升性能评分。

HTTP严格传输安全（HSTS）头的缺失会让站点在SSL Labs中无法获得A+，最高只能到A。通过在Nginx中添加add_header Strict-Transport-Security并携带max-age与includeSubDomains，可告知浏览器强制HTTPS访问。若要拿到A+，还需在SSL Labs界面提交预加载申请，但响应头本身必须已正确输出。示例如下：

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;

最后，混合内容（页面中引用HTTP资源）虽不直接影响SSL Labs握手评分，但会导致浏览器地址栏显示不安全，间接拉低整体安全印象分。Nginx可通过sub_filter或在前端框架层统一改写资源协议来消除该类问题。综合上述协议、证书、会话与响应头四层调整，绝大多数Nginx站点都能稳定达到SSL Labs的A+评级，并在真实攻防中具备现代加密韧性。

NginxSSL_LabsTLS_configuration修改时间：2026-08-16 07:48:30