第12章：Nginx SSL/TLS 配置与 HTTPS 实战

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

1. 项目背景

"鲜果园"的线上业务在过去两年中飞速发展，但同时也成为了网络攻击的高频目标。上个月的促销活动中，安全团队监测到多起中间人攻击（MITM）尝试：攻击者在公共WiFi环境下劫持用户会话，篡改订单金额和收货地址。虽然风控系统及时拦截了大部分异常交易，但这一事件让管理层意识到——全站HTTPS升级已经刻不容缓。

此外，随着iOS和Android系统对非HTTPS流量的限制越来越严格（如iOS的ATS策略要求所有网络请求必须使用TLS 1.2以上版本），鲜果园的混合内容（Mixed Content）问题也开始暴露：主站虽然启用了HTTPS，但部分静态资源仍通过HTTP加载，导致浏览器安全锁标志异常，用户信任度下降。

运维团队负责人把HTTPS全面迁移的任务交给了小胖。小胖第一次接触SSL证书，在云平台购买了一张单域名证书后，照着网上的教程在Nginx里配了ssl_certificate和ssl_certificate_key，然后宣布"搞定"。但小白在扫描测试时发现了不少问题：服务器仍支持已爆漏洞的SSLv3协议、证书链不完整导致部分浏览器警告、没有开启OCSP Stapling导致首次连接握手耗时长达400毫秒、HTTP/2也未启用。

大师在评审会上指出：“HTTPS不是简单地加上一张证书就能高枕无忧。TLS协议本身有多个版本（1.0/1.1/1.2/1.3），每个版本的安全性差异巨大；握手过程涉及非对称加密、对称加密、证书验证等多个环节，任何一环配置不当都会影响安全性和性能。我们需要系统性地理解SSL/TLS的完整链路，并建立一个能获得Qualys A+评级的配置基线。”

于是，大师带领团队踏上了从HTTP到HTTPS的完整升级之旅。

2. 项目设计

周四上午，安全专项会议室的窗帘半拉着，气氛比平时严肃。小胖面前摊着SSL证书文件和一串openssl命令的笔记。小白正在用SSL Labs的在线扫描工具测试现网配置，屏幕上的评级赫然显示着刺眼的"B"。大师推门而入，手里拿着打印出来的SSL握手时序图。

小胖（抬起头，有些沮丧）：“大师，证书我已经配好了，浏览器访问也能看到小绿锁。为什么小白的扫描工具只给了B级？我看网上有人说配了证书就是HTTPS了。”

大师（把时序图摊在桌上）：“小绿锁只是最基础的门槛。SSL Labs的评级从F到A+，涉及协议版本、密钥交换、证书强度、Forward Secrecy、HSTS等多个维度。你只完成了’有证书’这一步，距离生产级安全还差得远。”

小白（把笔记本转向大家）：“我列了一下我们现网的问题：第一，服务器仍接受TLS 1.0和TLS 1.1连接，这两个协议已经被POODLE、BEAST等攻击证明不安全；第二，证书链只发了服务器证书，没有包含中间CA证书，Android低版本设备直接报证书不受信任；第三，没有启用OCSP Stapling，每次新连接都要向CA的OCSP服务器查询证书吊销状态，增加了200到400毫秒的延迟；第四，HTTP Strict Transport Security（HSTS）没配，用户第一次通过HTTP访问时仍存在被劫持的风险。”

大师（点点头）：“小白总结得非常全面。让我先带你们回顾一下SSL/TLS握手的完整流程，理解了原理，配置才有灵魂。”

大师在白板上画下TLS 1.2的握手时序图：

客户端 服务器
| |
| ——– ClientHello —————–> | 支持的TLS版本、密码套件、随机数
| |
| <——- ServerHello —————– | 选定的TLS版本、密码套件、随机数
| <——- Certificate —————– | 服务器证书（含公钥）
| <——- ServerHelloDone ————- |
| |
| ——– ClientKeyExchange ———–> | 用服务器公钥加密预主密钥
| ——– [ChangeCipherSpec] ———-> |
| ——– Finished ——————–> | 加密握手完成
| |
| <——- [ChangeCipherSpec] ———- |
| <——- Finished ——————– |
| |
| <======= 加密应用数据传输 ==========> |

大师（指着图示）：“这是TLS 1.2的完整握手，需要2个RTT（往返时延）。握手完成后，双方协商出对称加密密钥，后续应用数据都用这个密钥加密传输。TLS 1.3对此做了重大优化，把握手缩减到1个RTT，甚至在会话恢复场景下可以做到0-RTT。”

小胖（皱着眉）：“大师，我听说握手过程很耗CPU，因为涉及非对称加密。鲜果园的QPS峰值有一万五，全部HTTPS后服务器扛得住吗？”

大师：“这是个好问题。非对称加密（RSA/ECDHE）确实比对称加密消耗更多CPU，但现代服务器硬件通常可以承受。更重要的是，TLS 1.3和TLS 1.2支持ECDHE密钥交换，配合椭圆曲线算法（如X25519），计算开销已经大大降低。此外，Nginx的SSL会话缓存（Session Cache）和会话票据（Session Tickets）可以让重复访问的客户端复用之前的握手结果，跳过完整的握手流程。”

小白（追问）：“Session Cache和Session Tickets有什么区别？”

大师：“两者都是为了实现会话恢复（Session Resumption），但机制不同。”

“Session Cache是服务器端缓存：Nginx在内存中保存已协商的会话参数（Session ID -> 主密钥的映射）。当客户端在后续连接中发送相同的Session ID，服务器直接从缓存中查找并恢复会话。优点是简单可靠，缺点是在多worker或多机集群场景下，缓存不共享，命中率受限。”

“Session Tickets是客户端缓存：服务器把一个加密过的会话状态（ticket）发给客户端，客户端在后续连接中把这个ticket带回来，服务器解密后即可恢复会话。优点是状态存储在客户端，天然支持多机集群；缺点是如果ticket密钥泄露，攻击者可以解密历史流量——不过只要定期轮换密钥，风险是可控的。”

小胖（恍然大悟）：“那我们是不是两个都开？”

大师：“是的，Nginx可以同时开启两种机制，让客户端自行选择支持的方式。”

小白（又抛出一个问题）：“大师，OCSP Stapling又是怎么回事？我看到有些大厂的证书配置里都有这个。”

大师：“OCSP（Online Certificate Status Protocol）是证书吊销状态查询协议。正常情况下，客户端收到服务器证书后，需要向CA的OCSP服务器发一个HTTP请求，询问’这张证书有没有被吊销’。这个查询会增加一次网络往返，而且如果CA的OCSP服务器宕机或网络不通，客户端可能无法完成证书验证。”

“OCSP Stapling的巧妙之处在于：由服务器主动向CA查询OCSP响应，然后把这个响应’装订’（Staple）到自己的TLS握手中，随Certificate消息一起发给客户端。客户端收到后，直接验证这个预置的OCSP响应即可，无需再向外发起查询。这样既减少了延迟，又减轻了CA服务器的压力。”

小胖（拍拍脑袋）：“这就像是去食堂吃饭时，窗口阿姨提前把健康证复印件贴在玻璃上，我们不用再去医务室查她有没有被吊销健康证了。”

大师（忍俊不禁）：“比喻虽然粗粝，但道理是对的。”

小白（继续深入）：“HSTS头我理解了，它是强制浏览器只用HTTPS访问。那HTTP/2和HTTPS有什么关系？”

大师：“HTTP/2虽然规范上允许运行在明文TCP之上（h2c），但所有主流浏览器都只支持基于TLS的HTTP/2（h2）。也就是说，要启用HTTP/2，必须先启用HTTPS。HTTP/2的多路复用、头部压缩（HPACK）、服务器推送等特性，可以大幅提升HTTPS的性能，部分抵消TLS握手带来的开销。”

小胖（看着白板上的满满内容）：“原来HTTPS不只是加一张证书，背后涉及到协议版本、密钥交换、会话恢复、证书状态、传输层优化这么庞大的知识体系。”

大师（收起时序图）：“正是如此。安全从来不是单点问题，而是一个系统工程。现在，我们把所有这些知识点落地到鲜果园的配置中。”

3. 项目实战

环境准备

• Nginx 1.24.0（源码编译时需启用–with-http_ssl_module和–with-http_v2_module）
• OpenSSL 3.0+（支持TLS 1.3）
• 有效SSL证书（服务器证书 + 中间证书 + 私钥）
• CentOS 8 / Ubuntu 22.04

步骤一：准备SSL证书文件

假设你已从CA机构获得以下文件：

• xian果园.crt：服务器证书
• xian果园.key：服务器私钥
• ca-chain.crt：中间CA证书链

关键操作：合并证书链

很多浏览器报错"证书不受信任"，是因为服务器只发送了终端实体证书，没有附带中间证书。Nginx需要把服务器证书和中间证书合并到一个文件中：

# 服务器证书在前，中间证书在后，依次追加
cat xian果园.crt ca-chain.crt > xian果园.fullchain.crt

# 验证证书链完整性
openssl verify -CAfile ca-chain.crt xian果园.fullchain.crt

预期输出：

xian果园.fullchain.crt: OK

验证私钥与证书匹配：

# 提取证书的公钥模数
openssl x509 -noout -modulus -in xian果园.crt | openssl md5

# 提取私钥的公钥模数
openssl rsa -noout -modulus -in xian果园.key | openssl md5

两个MD5值必须完全一致，否则说明私钥与证书不匹配。

步骤二：编写Nginx配置文件

user nginx;
worker_processes auto;

events {
worker_connections 1024;
}

http {
include mime.types;
default_type application/octet-stream;

# === 日志格式 ===
log_format ssl_log '$remote_addr – $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'ssl_protocol="$ssl_protocol" ssl_cipher="$ssl_cipher" '
'rt=$request_time';

access_log logs/access.log ssl_log;

# === HTTP 80端口：强制跳转HTTPS ===
server {
listen 80;
server_name www.xian果园.com xian果园.com;

# HSTS预加载（仅当确认全站HTTPS就绪后开启）
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

location / {
return 301 https://$host$request_uri;
}
}

# === HTTPS 443端口 ===
server {
listen 443 ssl http2;
server_name www.xian果园.com xian果园.com;
root /data/xian果园/static;
index index.html;

# === SSL证书配置 ===
ssl_certificate /etc/nginx/ssl/xian果园.fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/xian果园.key;

# === SSL协议版本：仅允许TLS 1.2和TLS 1.3 ===
ssl_protocols TLSv1.2 TLSv1.3;

# === 密码套件配置 ===
# 优先使用支持Forward Secrecy的密码套件
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 off; # TLS 1.3中此设置无效，交由客户端优先选择

# === 椭圆曲线偏好 ===
ssl_ecdh_curve X25519:secp384r1:secp256r1;

# === SSL会话缓存 ===
ssl_session_cache shared:SSL:50m; # 50MB共享缓存，约可存200万个会话
ssl_session_timeout 1d; # 会话有效期1天
ssl_session_tickets on; # 启用Session Tickets

# === OCSP Stapling ===
ssl_stapling on;
ssl_stapling_verify on;

# OCSP响应的DNS解析配置（必须）
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# === 证书透明度（Certificate Transparency）===
# 部分CA提供的证书已内嵌SCT，无需额外配置
# 如需手动添加：ssl_ct_static_scts /path/to/scts;

# === 安全响应头 ===
# HSTS：强制浏览器在未来一段时间内只用HTTPS访问
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# 防止点击劫持
add_header X-Frame-Options "SAMEORIGIN" always;

# XSS保护
add_header X-XSS-Protection "1; mode=block" always;

# MIME类型嗅探保护
add_header X-Content-Type-Options "nosniff" always;

# 引用策略
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

location / {
try_files $uri $uri/ /index.html;
}

location /api/ {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}

location /health {
access_log off;
return 200 "Nginx SSL is running\\n";
add_header Content-Type text/plain;
}
}
}

配置要点说明：

步骤三：语法检查与重载

/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

步骤四：验证测试

测试场景1：验证TLS版本和密码套件

# 测试TLS 1.3连接
openssl s_client -connect www.xian果园.com:443 -tls1_3

# 在输出中查找：
# Protocol : TLSv1.3
# Cipher : TLS_AES_256_GCM_SHA384

# 测试TLS 1.2连接
openssl s_client -connect www.xian果园.com:443 -tls1_2

# 测试被拒绝的TLS 1.1
openssl s_client -connect www.xian果园.com:443 -tls1_1
# 预期：握手失败

测试场景2：验证OCSP Stapling

openssl s_client -connect www.xian果园.com:443 -status

在输出中查找OCSP Response Status: successful，并且This Update和Next Update时间在合理范围内。

测试场景3：验证HTTP/2

curl -I –http2 https://www.xian果园.com/

预期响应头包含HTTP/2 200。

测试场景4：验证HSTS

curl -I https://www.xian果园.com/

预期响应头包含：

strict-transport-security: max-age=63072000; includeSubDomains

测试场景5：SSL Labs扫描

访问 https://www.ssllabs.com/ssltest/，输入域名进行扫描。

预期结果：

• Overall Rating: A+
• Certificate: 100%
• Protocol Support: 100%
• Key Exchange: 90%
• Cipher Strength: 90%

步骤五：源码级理解

打开src/http/modules/ngx_http_ssl_module.c，查看SSL配置指令的注册：

static ngx_command_t ngx_http_ssl_commands[] = {

{ ngx_string("ssl"),
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_CONF_FLAG,
ngx_conf_set_flag_slot,
NGX_HTTP_SRV_CONF_OFFSET,
offsetof(ngx_http_ssl_srv_conf_t, enable),
NULL },

{ ngx_string("ssl_certificate"),
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_CONF_TAKE1,
ngx_http_ssl_certificate,
NGX_HTTP_SRV_CONF_OFFSET,
0,
NULL },

{ ngx_string("ssl_protocols"),
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_CONF_1MORE,
ngx_conf_set_bitmask_slot,
NGX_HTTP_SRV_CONF_OFFSET,
offsetof(ngx_http_ssl_srv_conf_t, protocols),
&ngx_http_ssl_protocols },

/* … 更多指令 … */
};

这些指令在配置解析阶段被注册，最终转换为OpenSSL的API调用。

再看src/event/ngx_event_openssl.c中的SSL上下文初始化：

ngx_int_t
ngx_ssl_create(ngx_ssl_t *ssl, ngx_uint_t protocols, void *data)
{
SSL_CTX *ctx;

// 初始化OpenSSL库
ngx_ssl_init(ssl->log);

// 创建SSL上下文
ctx = SSL_CTX_new(SSLv23_method());
if (ctx == NULL) {
ngx_ssl_error(NGX_LOG_EMERG, ssl->log, 0,
"SSL_CTX_new() failed");
return NGX_ERROR;
}

SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);

if (!(protocols & NGX_SSL_TLSv1)) {
SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1);
}
if (!(protocols & NGX_SSL_TLSv1_1)) {
SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_1);
}
if (!(protocols & NGX_SSL_TLSv1_2)) {
SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_2);
}
#ifdef SSL_OP_NO_TLSv1_3
if (!(protocols & NGX_SSL_TLSv1_3)) {
SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_3);
}
#endif

ssl->ctx = ctx;
return NGX_OK;
}

这段代码展示了Nginx如何将配置中的ssl_protocols转换为OpenSSL的协议禁用标志。Nginx采用"反向排除"策略：默认启用所有协议，然后根据配置中未指定的版本逐个禁用。这种设计与直接指定启用版本相比，兼容性更好，特别是在OpenSSL库版本不同的环境中。

测试验证

# 基础连通性验证（示例）
curl -i http://127.0.0.1:8080/health

验证要点：

• 关键接口返回码符合预期（2xx/4xx/5xx与设计一致）；
• 关键日志字段完整（如 request_id、upstream 耗时、状态码）；
• 在小流量压测下无异常错误峰值。

4. 项目总结

经过本章的系统升级，鲜果园的全站HTTPS迁移顺利完成，SSL Labs评级从B提升到了A+。小胖和小白不仅学会了证书配置，更深入理解了TLS握手、会话恢复、OCSP Stapling等核心机制。

优劣对比：不同TLS版本与配置策略

适用场景

不适用场景

注意事项与警告

• 证书有效期：Let’s Encrypt证书有效期90天，需配置自动续期（certbot等）。商业证书通常1到2年，注意到期提醒。
• HSTS风险：一旦开启HSTS且max-age设得很长，如果HTTPS配置有问题，用户将无法通过HTTP访问来绕过。建议先在max-age=300（5分钟）测试，确认无误后再提升到63072000（2年）。
• 混合内容（Mixed Content）：页面中加载HTTP资源（图片、JS、CSS）会导致浏览器安全警告。全站迁移时需同步检查所有资源引用。
• TLS 1.3与中间件兼容性：部分老旧的企业级安全设备（如WAF、IDS）可能无法正确解析TLS 1.3流量，升级前需测试。
• 0-RTT重放攻击：TLS 1.3的0-RTT会话恢复虽然性能最优，但存在重放攻击风险。对于非幂等请求（如POST订单），应在应用层做防重放处理，或禁用0-RTT。

生产环境三大踩坑实录

案例一：证书链不完整导致移动端大面积报错

某电商公司上线HTTPS后，iOS用户正常，但大量Android用户反馈"证书不受信任"。排查发现服务器只发送了终端实体证书，没有附带中间CA证书。iOS设备通常内置了完整的中间证书，可以自动补全链条；而部分Android设备缺少该中间证书，导致验证失败。解决方案：使用cat server.crt intermediate.crt > fullchain.crt合并完整证书链。

案例二：OCSP Stapling配置遗漏resolver导致握手偶发超时

某公司在Nginx中开启了ssl_stapling on，但没有配置resolver指令。结果OCSP查询的DNS解析偶尔超时（默认使用系统/etc/resolv.conf），导致部分TLS握手耗时从100ms暴增到5秒以上。解决方案：显式配置可靠的DNS resolver，如resolver 8.8.8.8 8.8.4.4 valid=300s;，并设置合理的resolver_timeout。

案例三：HSTS预加载申请后无法回滚HTTP

某公司在未完全确认全站HTTPS就绪的情况下，就开启了preload标志并申请加入Chrome的HSTS预加载列表。结果部分子域名还有HTTP-only的服务，被强制HTTPS后无法访问。由于预加载列表被硬编码到浏览器中，移除需要数周到数月的更新时间。解决方案：HSTS分阶段 rollout，先小max-age测试，确认全站无误后再申请预加载。

进阶思考题

思考题1：TLS 1.3的0-RTT会话恢复机制虽然能显著降低重复连接的延迟，但它引入了重放攻击（Replay Attack）的风险。请分析：为什么0-RTT容易受到重放攻击？Nginx和OpenSSL目前对0-RTT的默认策略是什么？在鲜果园的电商场景中，哪些类型的请求绝对不能使用0-RTT，为什么？

提示：研究TLS 1.3的Early Data机制，以及IETF RFC 8446中对0-RTT安全性的讨论。思考POST订单、支付请求等非幂等操作的风险。

思考题2：在大型分布式架构中，Nginx通常采用多worker进程甚至多机部署。ssl_session_cache的shared内存缓存虽然可以在同一台机器的worker间共享，但无法跨机器共享。假设鲜果园有10台Nginx入口服务器，如何设计一种分布式SSL会话恢复方案，使得客户端无论连接到哪台服务器，都能复用之前的会话？请对比Redis集中存储、IP Hash负载均衡、以及TLS 1.3的PSK（Pre-Shared Key）模式的优劣。

提示：研究Nginx的ssl_session_ticket_key指令，以及通过共享ticket密钥文件实现跨机会话恢复的可能性。

下一章预告：第13章将深入Nginx的日志系统与访问控制。我们将从ngx_http_log_module.c和ngx_http_access_module.c源码出发，掌握access_log/error_log的格式定制、JSON结构化日志输出、allow/deny的IP访问控制、auth_basic基础认证、auth_request子请求认证等实战技巧。敬请期待《第13章：日志系统与访问控制》！

延伸阅读与资源

10倍开发者的 Dify 魔法书：从零构建全栈 AI 应用 后端工程师转型AI第一课-Ollama 与私有化大模型实战 大型语言模型(LLM) vLLM 高性能推理落地实战 Agent开发之LlamaIndex 实战修炼与源码进阶 大语言模型Transformers 实战修炼与源码剖析