证书到期
SysAdmin Crisis 中的证书到期：先有一行早期预警日志，随后 TLS 握手失效。了解它的特征以及如何与其他事件区分。
最后更新:
游戏中最小的事件，也是最常因疏忽而中招的事件。它只明明白白地提示一次，然后在一段时间内毫无动静。
它做什么
它分两个阶段到来。注入时，一行警告日志说明负载均衡器的 TLS 证书即将到期——除此之外什么都不会发生。没有指标变动，没有条形图变色，没有机器改变状态。
宽限期一过，证书到期，两件事同时发生：合法流量下降，因为客户端无法再连接；这些客户端的重试风暴则烧着负载均衡器的 CPU，直到它进入 CRIT。可用率从两个方向同时下跌。
日志特征
先是负载均衡器上 monit 的一条警告；证书到期之后，握手错误出现在 nginx 的错误日志中：
00:14:22 lb-01 monit[540]: 'shop-tls' certificate expiry test failed -- certificate expires in less than 1 day
00:19:40 lb-01 nginx: [crit] SSL_do_handshake() failed (SSL: error:0A000415:SSL routines::sslv3 alert certificate expired:SSL alert number 45) while SSL handshaking, client: 198.51.100.23, server: 0.0.0.0:443
这条警告会从日志流中一闪而过，且不会重复。证书的真实到期日期可以用 openssl x509 -enddate -noout -in <cert> 读取；openssl 命令显示的就是证书中的原始日期。
置之不理的后果
影响会持续到班次结束。警告不会重复。在所有事件中，只有这一个事件，“及时解决”与“发现得太晚”的差别仅仅是一行文字：读到了，或者没读到。
如何区分
游戏中没有别的事件会产生 TLS 握手错误，也没有别的事件会在造成损害之前发出警告。日志行里只要出现 certificate，诊断就很简短；真正的问题在于何时认真对待这条警告。
何时出现
| 最早出现的夜 | 4 |
| 前提 | 一台 lb 机器（负载均衡器在第 3 夜加入） |
| 权重 | 55——事件目录中最罕见的事件 |
| 同时出现 | 一个实例 |
处置不会立即显出效果；即便已经动手，修复也不是即时的。