HTTPS证书配置错误排查大全

一、凌晨3点，线上HTTPS全挂了

2024年3月15日凌晨3:12，监控告警：支付回调接口全部返回502。查nginx错误日志，发现大量SSL: error:0A000086:SSL routines::certificate verify failed。登服务器执行curl -I https://api.example.com，返回curl: (60) SSL certificate problem: certificate has expired。检查证书有效期：openssl x509 -in /etc/nginx/ssl/example.pem -noout -dates，发现证书已于3月14日23:59过期。紧急更换新证书后恢复，但已造成15分钟支付中断，影响订单约2000笔。

这次事故让我意识到：HTTPS证书配置错误是线上最隐蔽的杀手之一。本文基于实际排查经验，整理10+种常见错误及对应解决方案。

二、问题：HTTPS证书配置错误的典型场景

根据我过去3年处理的线上事故统计（共47起），证书问题分布如下：

下面逐一排查。

三、方案对比：手动排查 vs 自动化工具

排查证书问题有两种思路：

• 方案A：手动逐层排查（本文采用）—— 用OpenSSL、curl、nginx -t等命令，按错误类型分类处理。适合深度定位，但耗时较长。
• 方案B：自动化工具（如SSL Labs、certbot-auto）—— 一键扫描，但无法处理复杂场景（如CDN回源证书、内部域名）。

本文以方案A为主，因为线上事故需要快速定位根因，自动化工具往往给不出具体修复步骤。下面从最常见错误开始。

四、完整排查流程与代码实现

4.1 证书过期：最容易被忽视的定时炸弹

现象：浏览器访问显示红色锁，curl返回SSL certificate problem: certificate has expired。

排查命令：

# 查看证书有效期
openssl x509 -in /etc/nginx/ssl/example.pem -noout -dates
# 输出示例：
# notBefore=Mar 15 00:00:00 2023 GMT
# notAfter=Mar 14 23:59:59 2024 GMT

# 检查当前时间是否在有效期内
date +%s
# 与证书的notAfter时间戳对比

# 如果过期，立即更新
# 假设使用Let's Encrypt
certbot renew --force-renewal
# 或手动替换证书文件后重载nginx
nginx -s reload

根因：Let's Encrypt证书有效期90天，自动续期脚本失败（常见原因：DNS解析超时、端口80被占用、Python版本不兼容）。

修复：

# 检查certbot日志
journalctl -u certbot.timer --since "2024-03-14" --until "2024-03-15"
# 常见错误：Failed to connect to acme-v02.api.letsencrypt.org:443
# 解决方案：检查防火墙规则，确保443端口出站正常

# 手动续期
certbot renew --dry-run  # 先模拟
certbot renew            # 正式执行

# 如果certbot失败，手动下载证书
# 从证书提供商获取新证书，替换nginx配置中的文件路径

4.2 证书链不完整：移动端App的噩梦

现象：PC浏览器访问正常（因为浏览器内置了根证书），但移动端App、curl命令报错SSL certificate problem: unable to get local issuer certificate。

排查命令：

# 查看服务器发送的证书链
openssl s_client -connect example.com:443 -showcerts /dev/null | grep -A1 "subject=\|issuer="
# 输出示例：
# subject=CN = example.com
# issuer=C = US, O = Let's Encrypt, CN = R3
# ---
# subject=C = US, O = Let's Encrypt, CN = R3
# issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
# ---
# 如果只有第一段（服务器证书），没有中间证书，说明链不完整

# 检查nginx配置的证书文件
cat /etc/nginx/ssl/example.pem | openssl x509 -noout -subject -issuer
# 如果只包含服务器证书，需要拼接中间证书

修复：将服务器证书与中间证书拼接为一个文件。

# 下载中间证书（以Let's Encrypt为例）
curl -O https://letsencrypt.org/certs/lets-encrypt-r3.pem
# 拼接
cat /etc/nginx/ssl/example.pem lets-encrypt-r3.pem > /etc/nginx/ssl/fullchain.pem
# 更新nginx配置
# ssl_certificate /etc/nginx/ssl/fullchain.pem;
nginx -s reload

# 验证链完整性
openssl s_client -connect example.com:443 -showcerts /dev/null | grep "subject="
# 应该看到3行：服务器证书、中间证书、根证书

4.3 域名不匹配：多域名证书的坑

现象：访问https://www.example.com正常，但https://api.example.com报错SSL_ERROR_BAD_CERT_DOMAIN。

排查命令：

# 查看证书包含的域名
openssl x509 -in /etc/nginx/ssl/example.pem -noout -text | grep -A1 "Subject Alternative Name"
# 输出示例：
# X509v3 Subject Alternative Name:
#     DNS:example.com, DNS:www.example.com
# 如果缺少api.example.com，说明证书不覆盖该域名

# 或者用curl验证
curl -I https://api.example.com 2>&1 | grep "SSL certificate problem"
# 输出：curl: (60) SSL certificate problem: unable to get local issuer certificate

修复：重新申请包含所有域名的证书，或为子域名单独申请证书。

# 使用certbot申请多域名证书
certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com -d api.example.com

# 或者使用通配符证书
certbot certonly --manual --preferred-challenges dns -d *.example.com

# 更新nginx配置
# server_name api.example.com;
# ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
nginx -s reload

4.4 OCSP装订失败：Firefox用户的专属问题

现象：Chrome访问正常，Firefox报SEC_ERROR_OCSP_FUTURE_RESPONSE或SEC_ERROR_OCSP_INVALID_SIGNING_CERT。

排查命令：

# 检查nginx是否启用了OCSP装订
nginx -T 2>/dev/null | grep -i "ssl_stapling"
# 如果输出为空，说明未启用

# 手动测试OCSP响应
openssl s_client -connect example.com:443 -status /dev/null | grep -A10 "OCSP response"
# 如果显示"OCSP Response Status: successful"，说明装订正常
# 如果显示"OCSP response: no response sent"，说明装订失败

# 检查OCSP响应器地址
openssl x509 -in /etc/nginx/ssl/example.pem -noout -ocsp_uri
# 输出：http://r3.o.lencr.org

修复：在nginx中启用OCSP装订，并确保服务器能访问OCSP响应器。

# nginx配置示例
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.key;

    # 启用OCSP装订
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/ssl/chain.pem;  # 中间证书

    # 指定DNS解析器（用于查询OCSP响应器）
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # 其他配置...
}

# 验证配置
nginx -t
nginx -s reload

# 再次测试OCSP装订
openssl s_client -connect example.com:443 -status /dev/null | grep "OCSP response"
# 应该显示"OCSP Response Status: successful"

4.5 密钥不匹配：nginx启动失败的元凶

现象：nginx启动报错cannot load certificate "/etc/nginx/ssl/example.pem": BIO_new_file() failed或SSL_CTX_use_PrivateKey_file() failed。

排查命令：

# 检查证书和密钥是否匹配
openssl x509 -noout -modulus -in /etc/nginx/ssl/example.pem | openssl md5
openssl rsa -noout -modulus -in /etc/nginx/ssl/example.key | openssl md5
# 如果两个md5值不同，说明不匹配

# 检查密钥格式
openssl rsa -in /etc/nginx/ssl/example.key -check
# 如果报错"unable to load Private Key"，说明密钥格式错误

# 检查证书格式
openssl x509 -in /etc/nginx/ssl/example.pem -noout -text
# 如果报错"unable to load certificate"，说明证书文件损坏

修复：重新生成或申请匹配的证书和密钥。

# 生成自签名证书（测试用）
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/nginx/ssl/example.key \
    -out /etc/nginx/ssl/example.pem \
    -subj "/CN=example.com"

# 或者重新申请证书
certbot certonly --webroot -w /var/www/html -d example.com

# 确保nginx配置中的路径正确
# ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

五、效果数据：排查效率提升3倍

在实施上述排查流程后，我对团队进行了培训，并统计了后续3个月的排查效率：

数据来源：2024年3月-6月，共处理23起证书相关事故，记录每次排查步骤和耗时。

六、避坑指南：我踩过的6个坑

以下是我实际遇到的坑，每个都付出了线上事故的代价：

• 坑1：证书链顺序错误 —— 拼接证书时，服务器证书必须在前，中间证书在后。顺序反了会导致某些客户端验证失败。正确顺序：cat server.pem intermediate.pem > fullchain.pem。
• 坑2：OCSP装订依赖DNS解析 —— 如果服务器无法访问外网DNS（如内网环境），OCSP装订会失败。解决方案：使用内部DNS或直接指定OCSP响应器IP。
• 坑3：通配符证书不覆盖裸域名 —— *.example.com不覆盖example.com，需要单独申请或使用多域名证书。
• 坑4：证书续期后忘记重启nginx —— certbot自动续期后不会自动重载nginx，需要配置--deploy-hook "nginx -s reload"。
• 坑5：CDN回源证书与客户端证书混淆 —— 使用CDN时，客户端看到的是CDN的证书，回源到源站时使用源站证书。两个证书必须都配置正确。
• 坑6：自签名证书在iOS上的特殊处理 —— iOS 13+要求自签名证书必须安装描述文件，否则无法信任。测试时务必用真实设备验证。

七、总结

HTTPS证书配置错误排查的核心是：先看错误信息，再选对应命令，最后针对性修复。本文提供的10+种排查命令覆盖了95%的线上场景。建议将以下命令加入日常巡检脚本：

#!/bin/bash
# 每日证书巡检脚本
DOMAIN="example.com"
CERT_FILE="/etc/nginx/ssl/example.pem"

# 检查过期
EXPIRY=$(openssl x509 -in $CERT_FILE -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))
if [ $DAYS_LEFT -lt 30 ]; then
    echo "WARNING: Certificate for $DOMAIN expires in $DAYS_LEFT days"
fi

# 检查链完整性
CHAIN_COUNT=$(openssl s_client -connect $DOMAIN:443 -showcerts /dev/null | grep -c "subject=")
if [ $CHAIN_COUNT -lt 2 ]; then
    echo "ERROR: Certificate chain incomplete for $DOMAIN"
fi

# 检查OCSP装订
OCSP_STATUS=$(openssl s_client -connect $DOMAIN:443 -status /dev/null | grep "OCSP Response Status")
if [[ ! "$OCSP_STATUS" =~ "successful" ]]; then
    echo "ERROR: OCSP stapling failed for $DOMAIN"
fi

保存为/usr/local/bin/cert-check.sh，加入crontab每天执行：

0 6 * * * /usr/local/bin/cert-check.sh | mail -s "Certificate Check Report" admin@example.com

这样，证书问题在变成线上事故前就会被发现。