SSL 证书到期忘续？ECS 设置提醒自动告警教程

部署在 ECS 上的 HTTPS 站点，证书过期往往不是突然发生，而是被“记得续”这三个字拖垮。ECS SSL证书到期提醒配置的核心，是把人工记忆换成可重复执行的检查与通知机制。公开政策下主流 CA 证书有效期最长已缩至 398 天，留给运维的反应窗口比过去更短。

一、SSL证书到期风险与提醒的必要性

1. 什么是证书到期提醒

SSL 证书到期提醒，不是简单看一个过期日期，而是围绕 ECS 上证书部署路径建立周期性检测。管理员通过读取本地证书文件或远端 443 端口证书，获取 notAfter 时间，并与当前日期比较剩余天数。检测结果通过邮件、短信、企业微信/钉钉等 Webhook 自动通知，形成闭环。它解决的核心问题是：证书不会被打开看，但服务每天都在被用户访问。

2. 证书过期有哪些影响

证书过期最直接的表现是浏览器拦截、HTTPS 报错，用户访问被切断。更隐蔽的问题在内部：多台 ECS 或多个站点分别部署证书，手动排查耗时且容易漏查；主域名更新后，子域名、负载均衡节点仍可能使用旧证书。缺少专职运维的中小团队若还要分散管理云服务器、数据库、CDN 资源，可参考聚搜云这类一站式云服务方案，减少多厂商对接成本。

3. 为何需要自动提醒

人工记录证书到期，在证书有效期长、域名少时勉强可行。但主流公共 CA 已执行最长 398 天有效期策略，一年内至少一次续期、替换、部署，窗口更紧。自动提醒的价值不是发送一条通知，而是设置多级阈值：例如剩余 30 天、14 天、7 天分别告警，越接近到期频率越高。通知内容应带域名、证书路径、到期时间、剩余天数，否则收到告警后还要再排查半天。

二、ECS部署SSL证书的基础准备

证书到期提醒配置不是从写告警脚本那一刻才开始的，而是先确认证书在 ECS 上的真实部署情况。实际运维里，最常见的故障不是“没有证书”，而是证书路径分散、类型不统一、主域名和子域名使用不同证书，等到脚本上线才发现只检测了其中一张。对于缺少专职运维的中小团队，如果云服务器、数据库、CDN 等资源分散在不同厂商，证书台账往往也会跟着碎片化。这类团队想把基础资源统一管理，可以参考聚搜云这类一站式云服务方案，减少多厂商对接的繁琐成本，后续再做 ECS SSL 证书到期提醒配置时，至少能先解决“在哪里查、查哪些”的问题。

1. 证书类型怎么选：有效期缩短后，自动提醒比人工记录更重要

TLS/SSL 证书有效期整体在缩短，主流公共 CA 已执行最长 398 天有效期策略。这不是一个小变化：过去买一张两年期证书放在那里，可能一年后才会第一次认真看到期时间；现在一年期证书部署完，实际上留给运维的反应窗口很短。因此选择 DV、OV 还是 EV，不应只看加密强度，还要把续期周期和团队响应速度考虑进去。DV 证书签发快、自动化程度高，适合大多数 Web 业务；OV/EV 证书审核周期更长，一旦到期，重新签发和替换耗时也更多。建议至少按剩余 30 天、14 天、7 天设置多级提醒，不要只设一个提前 1 天的阈值。证书到期时间应从证书文件本身获取，而不是依赖记忆或域名购买时间。

2. ECS 环境检查要点：先定位路径，再谈告警

在 ECS 上做证书到期提醒，第一步是确认 Web 服务类型和证书实际路径。Nginx 通常通过 ssl_certificate 指向 .pem/.crt 文件，Apache 常见为 SSLCertificateFile 路径，Tomcat 可能使用 keystore。如果脚本检测的路径不对，后续告警就没有意义。可以用 OpenSSL 命令直接读取本地证书到期时间：

openssl x509 -enddate -noout -in /path/to/cert.pem

同时建议通过远端 HTTPS 访问校验实际下发的证书是否与本地一致：

openssl s_client -connect domain:443 -servername domain | openssl x509 -noout -enddate

这一步的目的是发现“本地证书已经更新，但线上节点还挂着旧证书”的情况。多节点、负载均衡或 CDN 边缘证书，往往比单台 ECS 更难排查，所以环境检查要把所有可能终结 TLS 的位置都纳入，而不是只看主域名。

3. 如何安装 SSL 证书并保持路径一致

安装证书本身并不复杂，难的是替换后保持一致性。证书更新后，旧证书如果还残留在某个子域名、备用节点或反向代理路径下，检测脚本可能报告“已更新”，但真实用户访问仍会看到过期证书。安装完成后，应至少在两个层面做校验：一是本地证书文件路径是否正确，二是通过公网域名访问时返回的证书序列号或到期时间是否与本地一致。对于同一 ECS 上多个站点，建议以域名为单位建立证书清单，记录证书路径、服务类型、到期时间和责任人，后续配置 ECS SSL 证书到期提醒时可以直接把清单转成检查脚本的输入，而不是每次临时去翻配置。

三、SSL证书到期提醒的实现方式

ECS SSL证书到期提醒配置的关键不是堆通知渠道，而是让检测范围和提醒频率匹配真实的证书部署情况。证书有效期已经缩短到最长398天，仅靠人工台账很容易漏。一个能在 ECS 上定时执行的检查脚本，加上邮件、短信、Webhook 里至少两条通道，基本可以覆盖中小团队的需求。三种方式各有适用场景，邮件适合留档，短信适合临期强触达，Webhook 适合团队群组联动。

1. 邮件通知怎么配

先确认检测对象。Nginx 看 ssl_certificate 指向路径，Apache 看 SSLCertificateFile，不要只盯着主域名证书，还要覆盖 SAN 证书和子域名证书。取到期时间可以直接用：

openssl x509 -enddate -noout -in /etc/nginx/ssl/example.crt

脚本里用 date -d 计算剩余天数，按 30 天、14 天、7 天三档触发。邮件发送在 ECS 上常用 mailx 或 msmtp 接外部 SMTP，端口 465/587。关键是收件地址别只用个人邮箱，团队邮箱或群组更容易避免漏看。邮件正文应包含域名、证书路径、到期时间和剩余天数，而不是只写一句“证书快过期了”。定时任务用 cron 每天跑一次即可：

0 9 * * * /usr/local/bin/ssl-check.sh

还有一个容易忽略的点：同一阈值每天重复发信会很快变成“狼来了”。可以在脚本里按域名和阈值级别写一个状态文件，只在告警级别变化时发送，减少无效打扰。

2. 短信告警如何实现

短信适合放在最后阶段，例如剩余 7 天、3 天、1 天，不建议从 30 天开始每天发。短信通道一般通过服务商 API 调用，多数需要模板 ID 和签名，国内通道还要做审核，所以不能等证书快过期了才临时去接短信告警。海外业务可以使用通用短信网关 API，用 curl 发起 HTTP 请求即可。

脚本逻辑与邮件一致：检查剩余天数，低于阈值时调用短信接口，内容压缩到域名、剩余天数和路径。短信按条计费，只保留给最关键证书或最后提醒，不要把它作为唯一通知。若邮件通道被拦截，短信可以作为第二通道兜底，但两者应独立配置，不能都从同一台 ECS 的同一个出网链路判断是否成功。

3. Webhook集成方法

Webhook 是目前比较灵活的通道，可以推到企业微信、钉钉、飞书或 Slack 群机器人。脚本中构造 JSON，用 curl 发送即可：

curl -X POST -H 'Content-Type: application/json' 
  -d '{"msgtype":"text","text":{"content":"证书即将到期"}}' 
  https://your-webhook-url

相比邮件，Webhook 消息可以直接 @ 当日值班或续期责任人，也方便在群里形成处理记录。安全上不要把 Webhook URL 硬编码在公开仓库中，建议放在环境变量或权限为 600 的配置文件里。

更关键的细节是“本地文件检测”和“远端验证”要结合。很多人本地证书已经替换，但 Nginx 没有 reload，或者 CDN、负载均衡节点仍在用旧证书。可以同时用：

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

如果本地文件和远端下发的到期时间不一致，告警就应该触发。这个检查能拦住一批“以为自己续好了”的线上事故。总体来看，ECS SSL证书到期提醒配置至少应有“邮件 + Webhook/短信”两条通道，否则任一通知渠道失效，整条提醒链路就会静默断掉。

四、配置ECS SSL证书到期提醒详细步骤

ECS SSL证书到期提醒配置的核心不是把脚本写得多复杂，而是先保证检测对象正确、阈值可执行、通知有兜底。下面按 Linux + OpenSSL + cron 组合展开，适合部署在 ECS 上的 Nginx、Apache 或单机多证书场景。

1. 获取证书到期时间

先确认证书真实位置，不要只凭记忆。Nginx 可执行 nginx -T 查看生效配置，找到 ssl_certificate 指向文件；Apache 看 SSLCertificateFile；Tomcat 若使用 keystore，则用 keytool -list -v -keystore xxx.jks 查看 Valid until。

本地证书文件检测命令：

openssl x509 -enddate -noout -in /etc/nginx/ssl/site.pem

输出类似 notAfter=Jun 12 23:59:59 2026 GMT。脚本里可转成 Unix 时间戳：

end_ts=$(date -d "$(openssl x509 -enddate -noout -in cert.pem | cut -d= -f2)" +%s)

但本地文件只能说明证书已被放到机器上，不能代表 443 端口实际下发。建议再加一条远端检测：

echo | openssl s_client -connect domain:443 -servername domain 2>/dev/null | openssl x509 -noout -enddate

这里 -servername 必须保留。否则多站点部署在同一台 ECS 时，不带 SNI 很容易拿到默认站点证书，导致误判。

2. 设置提醒阈值

阈值不建议只设一个。按真实处理链路看，30 天、14 天、7 天三档更实用：30 天提醒负责人启动续期，14 天确认替换进度，7 天进入高频提醒并抄送备份责任人。剩余天数计算：

remaining_days=$(( (end_ts - now_ts) / 86400 ))

不要等到只剩 1 天才告警。OV/EV、内部审批或 CA 延迟都会吃掉缓冲时间。目前公共 CA 已普遍执行最长 398 天有效期政策，证书轮换频率上升，14–30 天的提前量并不算保守。

3. 编写提醒脚本

脚本建议按“检测—比对—通知—记录”四步实现，并加入状态文件避免重复告警。例如记录上次触发阈值，当剩余天数从 31 天降到 29 天时触发一次 30 天档，后续仍处 29 天时不再重复发送。不能做成“每天运行就每天发”，否则同一证书一周多封相同邮件，真正的高危告警反而被淹没。

通知内容至少包含域名、证书路径、到期时间、剩余天数、当前阈值档位。通知渠道至少两条：邮件建议用团队邮箱或群组，Webhook 可对接企业微信、钉钉、飞书或 Slack。脚本应做到 Webhook 失败时继续尝试邮件，不能因一个渠道异常直接退出。日志建议落到 /var/log/cert_check.log。

最后挂到 cron，每天上午检查一次：

10 9 * * * /usr/local/bin/check_ssl_cert.sh >> /var/log/cert_check.log 2>&1

多证书场景可维护一个列表文件，每行记录 域名|证书路径|可选端口，脚本循环检测。中小团队用 cron 已足够，重点是上线前真实触发一次告警，验证通知链路完整，而不是只确认脚本无报错。

五、测试与验证提醒功能是否生效

证书到期提醒链路包含“检测—判断—触发—送达”四步，任何一步出问题都可能导致告警静默失败。上线前不建议只把阈值调到 30 天就认为配置完成，至少要用一个可重复的测试用例验证触发条件和通知到达。下面按模拟到期、通知日志、配置排错三个环节展开。

1. 模拟到期如何测试

最不建议的做法是直接修改 ECS 系统时间。虽然看起来能触发 cron，但会干扰系统审计、日志时间戳和其他定时任务，测试后还容易忘记恢复。更稳妥的方式有两种：

• 临时降低提醒阈值：把脚本中的 THRESHOLD_DAYS 从 30 改成 60，让现有证书立即进入“临期”区间。验证完成后改回原值。
• 使用短期测试证书：生成一张剩余 2 天有效的自签名证书，放到测试路径下，让脚本只检测该路径。命令可参考：

openssl req -x509 -newkey rsa:2048 -nodes 
  -keyout test.key -out test.crt -days 2 
  -subj "/CN=test.example.com"

执行检测脚本后，观察是否触发通知。如果脚本支持 --test 或 --dry-run，先看输出内容是否包含域名、证书路径、到期时间和剩余天数；确认无误后再接入真实通知渠道。远端检测还需要注意 -servername 参数，否则多 vhost 的 ECS 可能返回默认站点证书，导致测试对象错误。

2. 检查通知日志

通知是否发出，不能只看脚本执行了。至少要检查三层日志：

• 脚本运行日志：是否输出证书信息、剩余天数、命中的提醒级别和发送动作。
• 系统定时任务日志：cron 是否按预期时间执行，是否存在环境变量缺失导致的静默失败。
• 渠道回执日志：邮件查看 SMTP 返回码，250 通常表示接收成功；Webhook 不能只看 HTTP 200，企微、钉钉、飞书等接口通常还要看响应体中的 errcode 是否为 0。

另一个容易被忽略的问题是重复告警。如果检查脚本每个小时跑一次，但通知只按“剩余天数小于 30”触发，30 天到 14 天之间可能发送几十条内容重复的告警，反而让管理员麻木。建议在脚本中记录上次通知时的剩余天数，只有进入新的提醒级别或天数发生变化时才发送。日志至少保留 3 个月，方便事后核对漏报和误报。

3. 常见配置错误排查

测试阶段最容易暴露的是路径、权限和格式三类问题。

• 证书路径不一致：脚本检测的路径与 Nginx/Apache 实际加载的路径不一定是同一个。上线前执行 nginx -T 或 httpd -S，确认 ssl_certificate 或 SSLCertificateFile 的真实指向，避免“检测的是新证书，线上跑的是旧证书”。
• cron 环境变量缺失：手动执行脚本正常，但 cron 跑不起来，多半是 PATH 不包含 openssl 或脚本目录。脚本内建议使用绝对路径，或在开头显式 export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。
• 时区不统一：系统时区、日志时间、通知内容里的到期时间如果不使用同一个时区，可能出现“剩余 1 天”实际已经过期。建议统一使用 UTC 或明确标注 Asia/Shanghai。
• 邮件送达失败：SMTP 返回成功不代表进入收件箱。测试时检查垃圾邮件文件夹，并确认发信域名已配置 SPF、DKIM、DMARC 记录。仅发到个人邮箱风险较高，应使用团队邮箱或群组。
• Webhook 格式错误：钉钉、飞书、企业微信对 JSON 结构、Content-Type 和签名都有要求，HTTP 200 可能只是服务端收到请求，不代表消息真正推送。需要按渠道文档核对，并在测试阶段保留响应体。
• 多 vhost/SNI 遗漏：同一 ECS 上多个 HTTPS 站点时，远端检测必须显式指定 -servername，否则 openssl s_client 返回的是 443 端口默认证书，可能漏报真正要监控的子域名。

这些错误大多能在一次模拟测试中暴露，关键是不要用“看起来执行成功”替代“通知确实到达”。

六、到期提醒配置优化与常见问题

提醒配置上线后，真正要防的不是证书突然过期，而是误报太多导致告警被忽略，以及证书数量变多后管理失控。下面三个问题更容易在实际运维中暴露出来。

1. 如何避免误报

误报主要来自两类：一是只检测本地证书文件，但线上实际生效的证书已经是另一张；二是用修改系统时间测试，造成重复或错误告警。更稳妥的做法是本地文件与远端握手同时检测。远端用 openssl s_client -connect domain:443 -servername domain 拿证书，再与本地 ssl_certificate 指向的文件比对指纹。指纹不一致时，应提示“部署不一致”，而不是简单归入到期告警。

阈值上建议 30/14/7 天三级，比单设一个 1 天阈值更实用。每次检查记录序列号和指纹，出现连续告警时能快速判断是路径配错、证书替换未完成，还是检测脚本本身有问题。

2. 多证书统一管理

证书多头管理最容易漏掉子域名、SAN 证书和负载均衡后的旧证书。可以先用一张表维护“域名、证书路径、服务类型、负责人、续期入口”，不需要复杂系统。脚本遍历这张表，而不是手动逐个查。服务类型要区分 Nginx 的 ssl_certificate、Apache 的 SSLCertificateFile、Tomcat 的 keystore，检测命令不完全一样。

如果同一域名在 CDN、负载均衡和源站各配一份证书，远端检测需要覆盖多个入口，不能只测源站 443。按证书指纹聚合后，同一张证书在多个路径使用时，续期替换可以一次完成，避免旧证书残留在某个节点。

3. 提醒渠道备份策略

单一邮件渠道容易因拦截、个人邮箱未登录而失效。至少配置“团队邮箱 + Webhook”两条独立通道，Webhook 可对接企业微信、钉钉、飞书或 Slack。邮件标题建议直接带域名和剩余天数，例如“example.com 证书剩余 14 天”，而不是笼统的“证书到期提醒”。

Webhook 内容控制在一屏内，包含域名、到期时间、剩余天数和检测路径即可。还可以增加每周汇总，把临期证书集中发一次，减少日常告警疲劳。主渠道失败时自动降级到备用渠道，并在日志中标记，否则一旦告警静默失败，到期提醒就形同虚设。