踩坑现场
今天日常巡检 HomeLab 服务器，发现 Teleport 的证书居然失效了。点进去查看证书详情，发现有效期居然还停留在 2 月份？
奇怪的是，我服务器上跑的其他网站，SSL 证书全都是正常的。
习惯性排查与“思维定势”
遇到这种事，我的第一反应是：Nginx 代理出问题了。
于是熟练地 SSH 登录服务器，直奔 /etc/nginx/ 准备检查配置文件。但查了一半突然反应过来：不对啊，我当初部署 Teleport 的时候为了少一层转发，根本没有给它配置 Nginx 代理，而是直接让它监听固定端口的！
既然没有 Nginx，那就去检查 Teleport 的配置。打开配置一看，SSL 证书的路径指向了服务器的固定目录，路径配置没毛病。
这就更让人纳闷了：我明明写了脚本在后台定时更新 SSL 证书，并且检查了本地目录下的 .pem 文件，确实已经是最新续期的了，为什么 Teleport 还在用老证书？
破案线索：来自 Neofetch 的启示
百思不得其解时，我随手敲了一个 neofetch 看了下系统状态：
看着这行 Uptime: 83 days, 18 hours, 50 mins，我突然灵光一闪。
83 天！这个时间点太微妙了。 免费的 SSL 证书、有效期刚好是 90 天。
根本原因猜想：磁盘更新 ≠ 内存更新
真相大白：Teleport 在每次启动服务时，会将 SSL 证书直接读取并缓存在内存中。
在这服务器持续运转的 83 天里，虽然我的自动化脚本勤勤恳恳地把磁盘上的证书文件替换成了新版本，但处于运行状态的 Teleport 进程并不知道底层文件已经改变了，它依然死死抱着 83 天前加载到内存里的那份老证书在提供服务，直到老证书过期。
其他网站之所以没问题，是因为它们可能由 Nginx 托管，而我的更新脚本里大概率包含了 systemctl reload nginx 这类热重载指令。
验证与解决
既然知道了原因，验证起来就非常简单粗暴了。只需要重启服务，让它重新读取一次磁盘上的配置和证书即可：
Bash
sudo systemctl restart teleport.service
敲下回车，刷新浏览器，绿色的安全小锁又回来了。
