ssl证书过期或配置错误不会导致nginx崩溃，但会引发客户端连接中断和浏览器报错；关键线索需在server块内设warn级日志（如error_log /var/log/nginx/ssl_example.com.log warn），以捕获证书过期、私钥权限拒绝、证书与私钥不匹配等信号，并须结合openssl验证、nginx -t测试及-s reload重载闭环确认。
SSL 证书过期或配置错误本身不会让 Nginx 崩溃，但会导致客户端连接中断、浏览器报错（如 NET::ERR_CERT_DATE_INVALID），而这些异常在日志中往往藏得深——关键不是看有没有报错，而是看在哪一级、哪个作用域、出现什么特征信号。
重点看 warn 级别日志，且必须限定在 server 块内
Nginx 默认的全局 error_log 很可能漏掉 SSL 相关问题。真正有效的线索只出现在启用了 listen 443 ssl 的 server 块里，并显式配置了独立日志：
- 在对应 server 块中添加：error_log /var/log/nginx/ssl_example.com.log warn;
- warn 级别会记录：证书过期、域名不匹配、私钥不可读、SSL 指令路径错误、TLS 版本被禁用等安全敏感信号
- 例如：[warn] SSL certificate "/etc/nginx/ssl/example.com.pem" is expired 或 [emerg] open() "/etc/nginx/ssl/key.pem" failed (13: Permission denied)
从日志关键词快速锁定三类典型错误
看到以下内容，基本可直接归因，无需反复试错：
- SSL_CTX_use_PrivateKey_file(...) failed ... key values mismatch → 证书与私钥不匹配，用 openssl x509 -noout -modulus -in cert.pem | md5 和 openssl rsa -noout -modulus -in key.pem | md5 对比哈希值
- no shared cipher 或 tls_post_process_client_hello:no shared cipher → 加密套件无交集，不是证书问题，需检查 ssl_ciphers 配置与客户端能力是否兼容
- SSL_do_handshake() failed 伴随 SSL alert number 40 → TLS 握手失败，优先确认 ssl_protocols 是否禁用了客户端唯一支持的版本（如只留 TLSv1.3，但 Android 8.0 只支持到 TLSv1.2）
别依赖日志“看到”证书过期，要主动验证
浏览器提示“证书已过期”，不代表 Nginx 日志一定有记录——因为很多过期判断发生在握手阶段早期，Nginx 可能只记一条 warn，甚至不记（尤其 error_log 级别设为 error 时）。所以必须交叉验证：
- 用命令直查：openssl x509 -in /path/to/fullchain.pem -noout -dates，核对 notAfter 是否早于当前时间（今天是 2026-08-20）
- 确认 Nginx 实际加载的是哪个证书：curl -Ivk https://yoursite.com 2>&1 | grep "subject:"，或访问 SSL Labs 测试页
- 检查文件权限：ls -l /etc/nginx/ssl/，证书建议 644，私钥必须 600 且属主为运行 Nginx 主进程的用户（通常是 root）
重载后务必验证，避免“以为生效”
覆盖证书文件 ≠ Nginx 自动使用新证书。必须执行完整流程：
- 先语法检查：sudo nginx -t（防止路径写错、指令拼错导致重载失败）
- 再平滑重载：sudo nginx -s reload（不用 restart，避免连接中断）
- 最后验证生效：sudo tail -f /var/log/nginx/ssl_example.com.log，同时新开终端运行 openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
