vSphere 6.7证书突然过期，凌晨三点我这样救活了vCenter
凌晨三点拯救vCenter：一场与证书过期的生死时速
深夜的手机震动声划破了寂静，屏幕上刺眼的告警信息显示vCenter无法登录。这不是普通的故障，而是STS证书过期引发的系统性瘫痪。作为运维人员，我们最怕的就是这种毫无预警的"定时炸弹"——两年前部署时埋下的隐患，在某个深夜突然爆发。本文将还原这场惊心动魄的修复过程，从故障定位到应急方案，手把手带你走过每个关键决策点。
1. 故障现象与初步诊断
凌晨3:17，监控系统突然发出刺耳的警报声。vCenter的可用性检测连续失败，尝试通过Web客户端登录时，出现了诡异的交互现象：
- 输入正确的admin凭证后，系统反复提示"需要用户名和密码"
- 故意输入错误密码时，反而能得到"无效凭证"的错误响应
- 浏览器开发者工具显示HTTP 400错误，控制台出现
Signing certificate is not valid的提示
这种矛盾现象立即触发了我的警觉——认证服务本身是正常的（能识别错误密码），但正确的凭证却被当作"未输入"处理。通过SSH连接到vCenter服务器后，快速检查了几个关键日志：
tail -n 50 /var/log/vmware/vpxd-svcs/vpxd-svcs.log日志中赫然出现关键报错：
Server rejected the provided time range. Cause:ns0:InvalidTimeRange... Signing certificate is not valid at [当前时间]
此时，一个可怕的猜测浮现在脑海：STS证书可能已经过期。为验证这个猜想，我做了个大胆的测试——将系统时间回拨到前一天：
timedatectl set-time '2023-05-14 23:59:59'奇迹发生了：vCenter登录页面突然恢复正常！这确认了证书过期的猜想，但也带来了新的问题——所有服务都依赖系统时间，人为回拨时间绝非长久之计。
2. 深入理解STS证书机制
为什么一个证书过期会导致如此严重的连锁反应？这需要理解vSphere的安全架构设计。STS（Security Token Service）是vSphere单点登录(SSO)的核心组件，负责颁发和验证安全令牌。其证书具有以下特点：
| 特性 | 说明 |
|---|---|
| 默认有效期 | vSphere 6.5U2及以后版本默认为2年（早期版本为10年） |
| 影响范围 | 所有API调用、UI登录、服务间通信 |
| 过期表现 | 突然完全不可用（不同于普通HTTPS证书的浏览器警告） |
| 监控盲点 | 不会触发常规证书告警，必须主动检查 |
通过以下命令可以检查所有证书存储的过期时间：
for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo "=== $store ===" /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $store --text | grep -A1 "Not After" done在输出中，重点关注vpxd-extension存储的STS证书。我的案例中，它显示的有效期截止时间正好是当天凌晨。
3. 紧急修复全流程
确认问题后，必须立即执行证书替换。VMware官方提供了fixsts.sh修复脚本，但使用过程充满陷阱。以下是完整操作记录：
3.1 准备工作
- 创建系统快照：这是不可逆操作，必须先在vCenter管理界面创建完整快照
- 下载修复工具：
wget https://kb.vmware.com/sfc/servlet.shepherd/version/download/068f400000JAn50AAD -O /tmp/fixsts.sh - 处理Windows换行符问题（常见于直接下载的脚本）：
sed -i 's/\r$//' /tmp/fixsts.sh chmod +x /tmp/fixsts.sh
3.2 执行证书重置
运行脚本时需要提供SSO管理员凭证（通常为administrator@your-domain）：
cd /tmp ./fixsts.sh典型成功输出如下：
================================== Resetting STS certificate started on [时间] Detected DN: cn=vc01.example.com,ou=Domain Controllers,dc=lab,dc=local Detected PNID: vc01.example.com Detected SSO domain name: lab.local ================================== Enter password for administrator@lab.local: [交互输入密码] ================================== Replacement finished - Please restart services ==================================3.3 服务重启策略
直接重启所有服务可能遇到超时问题，推荐分阶段操作：
- 先停止关键服务：
service-control --stop vpxd vapi-endpoint - 然后按顺序启动：
service-control --start vpxd sleep 30 service-control --start vapi-endpoint - 最后验证状态：
service-control --status --all | grep -v "running"
注意：如果遇到
Operation timed out错误，可能需要强制重启整个vCenter设备。通过5480管理端口执行干净重启更安全。
4. 防患于未然的运维实践
经历这次惊魂后，我建立了系统的证书管理制度：
定期检查流程：
- 每月运行STS检查脚本：
python checksts.py # 需从VMware KB下载 - 设置日历提醒，在证书到期前90天开始跟踪
- 将证书有效期纳入监控系统，通过API定期获取
更新策略对比：
| 场景 | 推荐操作 | 风险等级 |
|---|---|---|
| 证书到期前90天 | 通过UI正常续订 | 低 |
| 证书已过期但能登录 | 立即续订+服务重启 | 中 |
| 证书过期导致无法登录 | 必须使用fixsts.sh+完整验证 | 高 |
关键检查点：
- 每年审计所有vCenter的部署日期
- 对vSphere 6.5/6.7系统特别关注2年有效期限制
- 测试环境提前模拟证书过期场景
5. 故障背后的技术启示
这场危机暴露了几个值得深思的技术现实：
- 时间敏感型故障最危险——它们总在深夜或假期爆发
- 证书生命周期管理不能依赖默认配置，特别是：
- 自签名证书
- 自动生成的内部证书
- 版本升级保留的旧证书
- 应急方案必须经过验证：fixsts.sh在实际执行时可能遇到：
- 权限问题（需root执行）
- 编码问题（Windows换行符）
- 依赖缺失（某些版本需要额外库文件）
我在事后建立了"末日演练"机制，定期选择非关键系统主动触发类似故障，训练团队应急能力。毕竟，在IT运维领域，最贵的学费总是由生产环境的事故来收取。