一个未续费的证书，支付转化直接归零
去年底，我合作的一个SaaS服务商老吴在续费季出了个问题。他的域名证书过期后，所有线上支付中断了整整一个上午。
老吴的团队周三早上九点四十开始收到用户反馈，支付页打不开。订单量在后台监控大屏上几乎一条直线，而正常情况下那个时段应该有两百多笔入账。技术主管在十点零三分确认：域名证书过期，所有支付回调接口全部返回TLS握手失败。
一个证书的过期，直接掐断了所有在途交易的链路。这比很多人想象的支付故障更致命——不是通道挂了，不是回调地址配错了，而是浏览器直接拒绝连接。
起因：为省几百块的证书管理成本，选择了手动续签
老吴做的是垂直行业的课程支付平台，月流水几万到十几万。系统上线时用的是某商业证书品牌的一年期OV证书，两千多块。运维同事觉得免费证书也够用，第二年换成了Let‘s Encrypt的三个月DV证书。
问题就出在这里：证书类型从OV换到DV不是问题，续签策略从商业自动续费变成手动脚本才是隐患。那个运维同事年中离职，交给新人的文档里没提证书自动续签这回事——脚本放在cron里但从来没跑成功过，因为当时申请证书用的ACME验证路径在迁移CDN后失效了，报错邮件发到了一个无人监控的组邮箱。
经过：排查过程暴露出三个被忽视的环节
十点零七分，我远程看了下他们的Nginx配置和浏览器的开发者工具。支付环节报错非常统一：ERR_CERT_DATE_INVALID，证书有效期到周二晚上八点截止。也就是说，已经有超过十二个小时的窗口期，所有支付请求都是暴露在失效证书下的。
更麻烦的是，他们在线支付的回调通知依赖HTTPS双向验证。证书一挂，上游支付机构的异步通知也全部失败，订单状态全部卡在“待支付”。这意味着即使手工补单，也需要先确认哪一笔确实扣款成功了——这是一个极其被动的数据对账场景，和我在易支付订单状态异常：一个配置疏忽引发的连环问题里写过的状态机紊乱非常相似。
当时他们的应急操作是：先在服务器上临时生成一张自签名证书顶上，然后逐笔查询上游订单状态，人工修正本地订单。这个操作额外带来一个安全风险——支付机构的回调接口会校验证书链，自签名证书直接被拒绝，回调依然跑不通。
转折：HSTS头让临时方案失效，加速了问题暴露
真正让团队意识到严重性的是：他们在修复DNS指向一个临时支付页时，发现浏览器根本不加载那个非HTTPS页面。
排查后发现，主域名之前配了HSTS（HTTP严格传输安全）头，max-age设了半年。这个安全策略一旦写入浏览器本地，即使服务器关闭HTTPS或使用无效证书，浏览器也绝不允许降级到HTTP连接。临时页面根本打不开，用户看到的永远是那个令人不安的红色证书警告页。
这个冷门细节从业者才知道：生产环境如果配置了HSTS，证书失效的后果会被放大数倍——你连一个安抚用户的静态公告页都挂不上去。唯一的恢复路径就是以最快速度换上有效证书。
于是技术主管紧急申请了一张新的免费证书，走DNS验证，好在CDN后端源站没挂，整个切换过程用了不到二十分钟。证书生效那一刻，支付回调队列积压的通知瞬间涌入，十几笔重复通知需要手动去重。
结果：半天损失可控，但信任恢复花了一周
上午十一点前后，支付恢复。当天损失几百笔订单，金额谈不上巨大，但用户侧的影响更大——有近两成的用户在证书报错页直接选择了关闭，且当天没有再回来。
后续运营同事花了整整一周逐一联系受影响用户，解释是“系统维护”，并提供优惠券补偿。与支付通道稳定性测试方法：一次并发超时复盘中提到的技术故障不同，证书过期给用户的感知是网站“不安全”，这个标签比支付超时更难洗掉。
如果重来：我会给老吴的三点建议
第一，证书续签必须走自动化。不管是Let’s Encrypt的certbot还是商业证书的ACME协议，部署后必须在监控平台配置到期告警，提醒时间至少提前十五天。实操命令：certbot renew --dry-run 每月跑一次校验脚本，确认续签动作确实能完成，同时把通知渠道绑定到运维即时通讯群组，而不是一个邮箱。
第二，生产支付环境如果启用了HSTS，必须维护一个证书过期应急预案。至少准备一份证书失效后通过CDN层重定向到公告页的方案，这个公告页需要一个独立的、长期有效的证书保护，不能和主业务域共享同一个证书。
第三，把证书监控纳入支付链路健康检查的一部分。很多人只监控接口的HTTP状态码，这不够。必须加上TLS握手时延和有效期检查，比如用Blackbox Exporter监控证书剩余天数，阈值推送到告警群。这几个动作属于支付运维的基本功，按行业通行做法，任何直接或间接承载支付表单的域名，证书剩余有效期低于七天就应触发响应流程。