NGINX如何为特定子域名启用TLS 1.1（Let's Encrypt Certbot场景）

核心问题定位与逐项修复 #

配置中TLS 1.1始终无法生效，是多层级的配置冲突、拦截叠加导致的，按以下顺序操作即可解决：

• 移除HTTP/2对TLS 1.1的强制拦截
  目标子域名的443监听指令中携带的http2参数，是最核心的阻断因素。Nginx的HTTP/2实现严格遵循技术规范，仅当客户端协商到TLS 1.2及以上版本时才会启用HTTP/2，且开启该参数后，Nginx会在TLS握手阶段直接拒绝所有低于TLS 1.2的连接请求——哪怕同server块内单独声明了允许TLS 1.1，也不会生效。
  操作：将目标子域名的监听配置从listen 443 ssl http2;修改为listen 443 ssl;，移除http2参数，TLS 1.1的握手流程才不会被拦截。
• 解除系统OpenSSL全局安全策略的库级拦截
  较新的Linux发行版会在OpenSSL全局配置中默认禁用TLS 1.0/1.1，这种拦截在加密库层面生效，完全不受Nginx单站点配置的控制。
  操作：修改OpenSSL全局配置文件中对应连接的安全等级，将加密协商的SECLEVEL从默认的2调整为1，允许TLS 1.1兼容的加密套件正常协商。注意不要直接将安全等级设为0，避免引入不必要的安全风险。
• 配置适配TLS 1.1的加密套件
  之前尝试的两套加密套件列表，优先匹配的多为TLS 1.2专属的GCM类加密套件，没有预留足够TLS 1.1可协商的兼容套件。就算协议层面放开，没有匹配的加密套件也会导致握手失败，测试站点自然会判定TLS 1.1不可用。
  操作：将目标server块内的ssl_ciphers替换为同时兼容TLS 1.1、TLS 1.2的套件列表：
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
• 确认Nginx加载最新配置
  所有配置修改完成后，先执行nginx -t校验语法，确认无报错后执行systemctl reload nginx热加载配置，避免配置未生效的低级问题。

生效验证与临时配置注意事项 #

• 本地快速验证不需要依赖第三方测试站点，直接执行openssl s_client -connect 目标子域名:443 -tls1_1，如果返回完整证书链且握手成功，就说明TLS 1.1已经正常启用；同时补测TLS 1.2、TLS 1.3的协商流程，确认高版本协议不受影响。
• TLS 1.1属于已被行业标准淘汰的不安全协议，在对应API客户端完成升级后，需要第一时间将该子域名的配置恢复：重新开启http2、将ssl_protocols切回TLS 1.2以上版本、把OpenSSL全局安全策略恢复到默认等级，不要长期开放低版本TLS。

内容的提问来源于stack exchange，提问作者John Tiggernaught