VCSA 6.5证书过期连环坑：从重置密码到一键修复脚本的完整踩坑实录

VCSA 6.5证书过期连环坑：从重置密码到一键修复脚本的完整踩坑实录

那天凌晨三点，监控系统突然狂闪红光——整个vSphere环境失去响应。登录VCSA 6.5管理界面时，熟悉的登录框变成了刺眼的红色警告："Signing certificate is not valid"。作为运维老兵，我本以为这只是个简单的证书更新操作，没想到就此踏入了长达8小时的故障修复深渊。本文将用第一视角还原这场战役的全过程，包含7个致命陷阱和3种绝地反击方案。

1. 故障初现与错误的第一步

当浏览器首次弹出证书过期警告时，我下意识地点击了"继续浏览"。这个习惯性动作埋下了第一个隐患——实际上此时SSO服务已经出现异常。尝试用administrator@vsphere.local登录时，系统提示"密码过期"，这是典型的连锁反应开端。

致命陷阱1：直接重置密码而不检查证书状态。我执行了密码重置操作：

/usr/lib/vmware-vmdir/bin/vdcadmintool

选择选项3重置密码后，虽然获得了新密码，但服务依然无法启动。此时应该立即检查证书状态：

for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo "STORE $i"; sudo /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done

输出显示6类关键证书同时过期：

• SSL证书（影响HTTPS通信）
• machine证书（影响主机认证）
• vpxd证书（影响核心服务）
• webclient证书（影响界面访问）

2. 官方脚本的有限救赎

从VMware KB下载了checksts.py和fixsts.sh脚本后，我犯下第二个错误——没有切换正确的shell环境。VCSA默认使用appliancesh，而脚本需要bash环境：

chsh -s /bin/bash root # 切换至bash chmod +x {checksts.py,fixsts.sh} ./checksts.py # 检查STS证书状态

关键发现：STS（Security Token Service）证书是核心症结。执行修复脚本后：

./fixsts.sh service-control --stop --all service-control --start --all

虽然STS服务恢复了，但其他服务仍然报错。这就是陷阱2：单一修复STS证书无法解决复合型证书过期问题。

3. 证书核爆区的全面修复

进入真正的攻坚阶段——使用Certificate Manager更新所有证书。这里存在陷阱3：直接运行certificate-manager会因环境变量缺失导致失败。必须先配置Java路径：

export JAVA_BIN=/usr/java/jre-vmware/bin/java export CLASSPATH=/opt/vmware/lib64/*:/usr/lib/vmware-sso/commonlib/*

完整修复流程分三步走：

1. STS证书重装：

$JAVA_BIN -cp $CLASSPATH com.vmware.identity.installer.STSInstaller \ --install \ --root-cert-path "/etc/vmware-sso/keys/ssoserverRoot.crt" \ --cert-path "/etc/vmware-sso/keys/ssoserverSign.crt" \ --private-key-path "/etc/vmware-sso/keys/ssoserverSign.key"

2. 全量证书更新：

/usr/lib/vmware-vmca/bin/certificate-manager

选择选项8，注意：

• Hostname必须与初始部署完全一致（IP或FQDN）
• VMCA Name需与Hostname相同

3. 清理证书坟场：

vecs-cli entry delete --store BACKUP_STORE --alias bkp___MACHINE_CERT -y vecs-cli entry delete --store BACKUP_STORE --alias bkp_vpxd -y # 其他备份证书同理... vecs-cli store delete --name BACKUP_STORE -y

4. 服务启动的隐藏玄机

当所有证书更新完成后，陷阱4悄然出现——服务启动顺序影响最终结果。正确的排序应该是：

1. vmware-stsd（STS服务）
2. vmdird（目录服务）
3. vmcad（证书服务）
4. vpxd（核心服务）

使用这个命令序列更可靠：

service-control --stop --all for svc in vmware-stsd vmdird vmcad vpxd; do service-control --start $svc sleep 30 # 关键间隔 done service-control --start --all

5. 终极验证与防护策略

最终验证需要检查三个关键点：

1. 证书有效期：

openssl x509 -in /etc/vmware-vpx/ssl/rui.crt -noout -dates

2. 服务状态矩阵：

3. Web控制台测试：

• 清除浏览器缓存后访问
• 检查https://{vcenter}/psc的健康状态

长效防护方案：

• 创建证书到期监控脚本（crontab每月运行）

#!/bin/bash EXP_DATE=$(openssl x509 -in /etc/vmware-vpx/ssl/rui.crt -noout -enddate | cut -d= -f2) DAYS_LEFT=$(( ($(date -d "$EXP_DATE" +%s) - $(date +%s)) / 86400 )) [ $DAYS_LEFT -lt 30 ] && alert-send "证书即将过期"

6. 环境差异的应对之道

在不同部署模式下会遇到陷阱5：

• 嵌入式PSC：需要先处理STS证书
• 外部PSC：必须先在PSC节点执行修复
• Windows版VC：证书路径完全不同（C:\ProgramData\VMware\vCenterServer\ssl）

对于使用IP地址部署的环境（陷阱6），certificate-manager中的Hostname必须输入IP而非FQDN。这是导致很多修复失败的隐藏原因。

7. 日志分析的黄金法则

当上述步骤仍不成功时，需要检查三个核心日志：

1. STS日志：

tail -n 100 /var/log/vmware/sso/ssoAdminServer.log

2. 证书管理器日志：

grep -i error /var/log/vmware/vmcad/certificate-manager.log

3. VPXD日志：

tail -f /var/log/vmware/vpxd/vpxd.log

典型错误模式对照表：

那次凌晨的故障最终在日出前解决，但留下的教训远比证书有效期长久——关键系统的证书管理不能依赖人工记忆，必须建立自动化监控体系。现在我的团队所有vCenter实例都部署了双重检查机制：Zabbix监控证书日期+自定义脚本提前90天预警。毕竟在运维的世界里，预防永远比救火更有价值。