证书问题是“平时无感、出事全站受影响”
不少站点在建站时配过一次 HTTPS，之后就把这件事从待办清单里划掉了。但证书有明确的有效期，域名覆盖范围也可能随着站点改版、子域拆分而发生变化。证书出问题通常不是渐进式的，而是某一天突然所有访客看到浏览器警告，搜索蜘蛛的抓取也会同步失败。
这类事故的麻烦之处在于：它既影响用户体验，也影响抓取。访客走了，蜘蛛也可能在握手失败后减少来访。所以与其等出事再处理，不如把它当成一个固定的运维检查项。
一、到期时间与续期方式
- 记录每一张证书的到期日，留出至少两周缓冲，不要等到最后三天再动手。
- 确认续期是自动还是人工。自动续期也要确认执行结果，别只看到定时任务存在就放心。
- 把到期提醒发给至少两个人或一个公共渠道，避免负责人休假、离职时出现断档。
- 续期成功后，从外部访问一次站点，确认新证书确实已经生效，而不是只更新了本地文件。
二、域名覆盖范围是否完整
列出站点实际在用的所有入口：主域名、带 www 的版本、移动端子域、静态资源域名、接口域名、活动专用子域。逐一验证证书是否包含这些域名。泛域名证书只覆盖同一级子域，二级子域往往需要单独确认。站点做过结构调整后，这一步尤其容易被忽略。
三、证书链是否完整
服务器只配置了站点证书、漏掉中间证书，是很多“部分设备能打开、部分设备报错”的根源。检测时要从外部发起，而不是只在服务器本地用命令行测试。完整的链路应该让不同浏览器、不同系统都能顺利握手。
四、页面里的混合内容
HTTPS 页面中如果还引用 http 的图片、脚本、字体或样式，浏览器会拦截或给出降级提示。常见来源包括：老文章里粘贴的外链图片、旧模板残留的 CDN 地址、第三方小工具代码。可以按协议批量扫描页面源码，把 http 资源逐条替换或改为相对协议引用。
五、跳转与协议统一
确认 http 到 https、裸域到 www 的跳转只有一层，并且跳转目标本身可访问。如果目标地址又跳一次，既浪费抓取，也容易在证书异常时形成循环。跳转规则最好集中在服务器或 CDN 配置里，不要一处一处在页面代码中零散设置。
六、CDN 与多节点证书同步
使用 CDN 时，证书可能同时存在于源站和边缘节点。续期之后要确认两边都已更新，否则会出现源站正常、用户访问报错的情况。回源协议同样值得检查，不要让源站成为整条链路上的薄弱点。
七、外部监控与告警
从外部对首页和几个关键栏目做定时探测，检查证书剩余天数、握手是否成功、返回状态是否正常。告警要发到有人看的地方，比如值班群或工单系统，而不是只写进日志文件。监测频率不必太高，每天一次通常就够用。
证书真的失效了，按这个顺序处理
- 先确认影响范围：是全部域名还是某个子域，是全部访客还是部分网络环境。
- 优先恢复可访问性：尽快完成续期并部署，不要在此时做其他变更。
- 从外部重新验证：检查证书链、跳转规则、页面内资源是否还有 http 残留。
- 复盘提醒机制：把这次的触发时间往前挪，补上更早的提醒节点。
证书适合用固定检查项加自动提醒来管理，而不适合靠记忆。把检查动作写进运维清单，比事后补救省力得多。
小结
把证书当成一个需要持续维护的对象，而不是一次性的配置动作。到期日、覆盖域名、证书链、混合内容、跳转规则、CDN 节点、外部探测，这几项在每次续期后各看一遍，基本能把大部分意外挡在前面。对站点运营来说，这类基础项做得稳，后续的内容和结构优化才有意义。