1. 故障现场还原与核心问题定位1.1 一个典型的VCSA 6.7登录故障场景早上九点运维群里弹出一条消息“vCenter打不开了网页提示证书错误客户端也连不上。”我打开浏览器访问vCenter的5480端口页面直接报SSL证书过期再试443端口同样无法建立安全连接。SSH倒是能连上但登录后执行任何命令都提示“Authentication token is expired”或者干脆卡在登录验证阶段。这种情况在VCSA 6.7环境中非常典型尤其是那些部署了两三年、当初装完就没再管过证书的测试环境或边缘业务环境。VCSA 6.7的证书体系比6.0之前复杂得多它引入了VMware Certificate AuthorityVMCA作为内部根证书所有服务证书都由VMCA签发。默认情况下这些证书的有效期是两年而STS签名证书的有效期更短只有一年。很多管理员在部署时勾选了“使用默认证书”后续也没有配置证书到期提醒结果就是某天突然发现vCenter彻底无法登录。更麻烦的是证书过期后VCSA的很多后台服务会进入保护状态连SSH登录后的shell都可能被限制导致你无法直接执行修复命令。1.2 为什么时间同步是恢复登录的第一把钥匙证书验证的核心逻辑是客户端拿到的证书其“有效期”字段必须覆盖当前系统时间。如果VCSA的系统时间已经超过了证书的Not After日期那么所有依赖证书的服务都会拒绝连接。这时候你可能会想那我直接续签证书不就行了问题在于续签证书的操作本身也需要通过认证而认证又依赖证书有效。这就形成了一个死循环。打破这个死循环最直接的办法就是把VCSA的系统时间回拨到证书过期之前。一旦系统时间回到证书有效期内vCenter的服务就能正常启动Web界面和SSH的完整功能也会恢复。这时候你再从容地执行证书续签或替换操作最后把时间同步回正确值。这个思路听起来简单但实际操作中有几个关键点VCSA 6.7的时间同步机制、SSH登录后的权限限制、以及时间修改后对数据库和日志的影响都需要仔细处理。1.3 适用场景与前置条件确认这套方法适用于以下情况VCSA 6.7的STS证书或VMCA根证书已过期导致vCenter Server服务无法启动Web界面报证书错误SSH登录后无法执行正常管理命令。你需要具备的条件包括VCSA的root密码或具有sudo权限的账户、能够通过SSH连接到VCSA的IP地址、以及一台能正常访问VCSA的终端设备。注意如果VCSA是嵌入式部署且PSC与VC在同一台机器上本方法直接适用。如果是外部PSC部署需要先修复PSC的时间再处理VC节点。在开始操作前建议先通过SSH尝试登录确认故障现象。如果SSH能登录但shell受限可以尝试执行shell.set --enabled true然后shell进入bash环境。如果连这个都做不到说明STS证书过期已经严重到影响认证服务需要直接进入时间修改流程。2. 通过SSH修改系统时间的完整操作流程2.1 SSH登录与受限Shell的突破方法用你常用的SSH工具连接VCSA的IP地址端口默认22。登录用户名用root密码是你部署时设置的。如果登录后直接进入的是Command提示符而不是bash shell说明你还在受限制的 applianceshell 中。这时候先执行shell.set --enabled true shell正常情况下你会看到提示符变成#表示已经进入bash环境。但如果STS证书过期严重执行shell时可能会报错“Failed to authenticate”或者直接卡住。我遇到过几次这种情况解决办法是先用SSH登录但不进入shell直接在 applianceshell 里执行时间修改命令。VCSA的 applianceshell 提供了一些基础命令其中就包括时间管理相关的。如果 applianceshell 也无法正常执行命令可以尝试通过VCSA的DCUIDirect Console User Interface在虚拟机控制台直接操作。但DCUI的功能有限修改时间需要进入shell所以还是得先解决shell访问问题。一个比较稳妥的做法是在SSH登录时使用-o PreferredAuthenticationspassword强制密码认证有时候能绕过一些认证异常。2.2 查看当前时间与证书过期时间进入shell后第一件事是确认当前系统时间和证书的过期时间。执行date你会看到类似Fri Mar 15 14:23:45 UTC 2024的输出。然后查看STS证书的过期时间openssl x509 -in /etc/vmware-sso/vmware-sts/ssl/rui.crt -noout -dates这个命令会输出证书的Not Before和Not After日期。对比一下系统时间和Not After如果系统时间已经超过了Not After那就确认是证书过期导致的问题。同时也可以检查VMCA根证书openssl x509 -in /etc/vmware-sso/vmware-sts/ssl/root.crt -noout -dates把这两个日期记下来后面修改时间时要确保回拨到这两个日期之前。通常STS证书的有效期是一年VMCA根证书是两年所以回拨到STS证书过期前一个月左右比较安全。2.3 修改系统时间的三种方式与选择建议VCSA 6.7修改时间有三种方式各有适用场景方式一使用date命令直接修改date -s 2023-06-01 12:00:00这是最直接的方法但VCSA默认启用了NTP同步你改完时间后NTP服务可能会在几分钟内把时间又同步回去。所以需要先停掉NTP/etc/init.d/ntpd stop然后再修改时间。修改完成后如果需要保持时间不再被同步可以暂时禁用NTPsystemctl stop ntpd systemctl disable ntpd方式二通过timedatectl命令修改timedatectl set-ntp false timedatectl set-time 2023-06-01 12:00:00这种方式更规范它会同时处理NTP同步和时间设置。但VCSA 6.7的timedatectl支持程度因版本而异有些版本会报错“Failed to set time: Automatic time synchronization is enabled”这时候还是得用方式一。方式三通过VAMI界面修改如果你还能访问5480端口的VAMI界面可以在“Time”选项卡里手动设置时间。但证书过期时VAMI通常也打不开所以这个方法只在部分场景下可用。我个人的建议是优先用方式二如果报错就用方式一配合停NTP。修改时间后立即执行date确认时间已经生效。然后尝试重启vCenter的核心服务service-control --stop --all service-control --start --all如果服务启动正常说明时间回拨已经生效证书验证通过了。2.4 时间修改后的服务恢复与验证服务全部启动后先别急着高兴。你需要验证几件事第一Web界面是否能正常登录。打开浏览器访问https://vcenter-ip/ui如果能看到登录页面并且能正常登录说明STS证书已经恢复有效。第二SSH的完整shell功能是否恢复。重新开一个SSH会话执行shell进入bash看看是否还会报认证错误。第三检查所有服务的健康状态service-control --status --all确保所有服务都是Running状态。如果有服务启动失败查看日志tail -f /var/log/vmware/vpxd/vpxd.log常见的问题是数据库服务vmware-vpostgres启动慢或者STS服务需要额外的时间来重新初始化。如果等待几分钟后服务仍然起不来可以尝试单独重启service-control --restart vmware-stsd service-control --restart vmware-vpxd实操心得修改时间后VCSA的日志时间戳会变得混乱因为日志是按系统时间记录的。这在排查问题时会造成困扰。我的做法是在修改时间前先记录当前真实时间修复完成后立即把时间同步回正确值然后重启一次所有服务让日志时间戳恢复正常。3. STS证书修复脚本的编写与执行3.1 为什么需要专门的修复脚本时间回拨只是临时手段让vCenter恢复可用。但证书本身还是过期的如果不续签或替换下次系统时间同步回正确值后问题会再次出现。VCSA 6.7提供了certificate-manager工具来续签证书但操作步骤繁琐而且STS证书的续签涉及多个服务重启手动操作容易出错。我写了一个修复脚本把整个流程自动化检查证书状态、备份旧证书、生成新证书、替换证书文件、重启相关服务、验证修复结果。这个脚本在多个VCSA 6.7环境中实测有效包括嵌入式部署和外部PSC部署。3.2 脚本核心逻辑与关键代码解析脚本的核心逻辑分为六步第一步环境检查#!/bin/bash VCENTER_IP$(hostname -I | awk {print $1}) STS_CERT/etc/vmware-sso/vmware-sts/ssl/rui.crt BACKUP_DIR/root/cert_backup_$(date %Y%m%d_%H%M%S) if [ ! -f $STS_CERT ]; then echo STS证书文件不存在请确认VCSA版本和路径 exit 1 fi mkdir -p $BACKUP_DIR第二步备份现有证书cp -rp /etc/vmware-sso/vmware-sts/ssl/ $BACKUP_DIR/ cp -rp /etc/vmware-sso/ $BACKUP_DIR/vmware-sso-backup/备份是必须的因为证书替换过程中如果出错没有备份就只能重装VCSA了。我见过有人直接删掉旧证书结果新证书生成失败最后只能从快照恢复。第三步生成新的STS证书VCSA 6.7的STS证书可以通过certificate-manager工具重新生成/usr/lib/vmware-vmca/bin/certificate-manager这个工具是交互式的脚本里需要用expect或者重定向输入来自动化。我选择用expect因为更稳定/usr/bin/expect EOF set timeout 300 spawn /usr/lib/vmware-vmca/bin/certificate-manager expect option { send 8\r } expect Continue { send y\r } expect username { send administratorvsphere.local\r } expect password { send $SSO_PASSWORD\r } expect IP { send $VCENTER_IP\r } expect Continue { send y\r } expect eof EOF这里的$SSO_PASSWORD需要提前设置或者从环境变量读取。注意certificate-manager的选项8是“Reset all certificates”这个操作会重新生成所有证书包括STS、VMCA和解决方案用户证书。执行前一定要确认备份完整。第四步替换STS证书文件certificate-manager执行完成后新的证书文件会生成在/etc/vmware-sso/vmware-sts/ssl/目录下。但有时候工具会报错证书没有正确替换。这时候需要手动复制cp /etc/vmware-sso/vmware-sts/ssl/rui.crt $BACKUP_DIR/rui.crt.old cp /etc/vmware-sso/vmware-sts/ssl/rui.key $BACKUP_DIR/rui.key.old然后从/root/certs/或者工具指定的输出目录复制新证书。第五步重启STS服务service-control --stop vmware-stsd service-control --start vmware-stsd等待30秒然后检查服务状态service-control --status vmware-stsd第六步验证证书有效期openssl x509 -in /etc/vmware-sso/vmware-sts/ssl/rui.crt -noout -dates确认Not After日期已经更新到未来。3.3 脚本执行中的常见报错与处理执行脚本时最常见的报错是“Failed to connect to VMware Directory Service”或者“SSO authentication failed”。这通常是因为STS服务没有完全启动或者SSO密码错误。处理方法是先手动重启STS服务确认服务正常后再执行脚本。另一个常见问题是certificate-manager执行到一半卡住没有任何输出。这通常是因为VCSA的某个后台服务响应慢或者磁盘空间不足。检查磁盘df -h如果/storage或/var分区使用率超过90%需要先清理空间。VCSA的日志文件很容易占满磁盘可以清理/var/log/vmware/下的旧日志。注意执行证书修复脚本前务必给VCSA拍一个快照。虽然脚本经过测试但不同环境的配置差异可能导致意外情况。快照是最可靠的退路。3.4 修复后的时间同步与最终验证证书修复完成后需要把系统时间同步回正确值。先启用NTPsystemctl enable ntpd systemctl start ntpd然后手动触发一次同步ntpdate -u ntp-server-ip如果没有内部NTP服务器可以用pool.ntp.org。时间同步后再次重启所有服务service-control --stop --all service-control --start --all最后验证Web界面登录正常、SSH shell正常、证书有效期正常、所有服务Running。这套流程走下来VCSA 6.7的证书过期问题基本就能彻底解决。4. 常见问题排查与独家避坑经验4.1 时间修改后服务无法启动的排查思路修改时间后如果service-control --start --all执行失败先看具体是哪个服务起不来。最常见的三个服务是vmware-vpxd、vmware-stsd和vmware-vpostgres。排查顺序如下先检查vmware-vpostgres因为vpxd依赖数据库。如果数据库起不来vpxd肯定起不来。查看数据库日志tail -100 /var/log/vmware/vpostgres/postgresql.log常见错误是“database files are incompatible with server”或者“could not connect to server”。前者通常是因为时间修改幅度太大导致数据库文件的时间戳异常。解决办法是用pg_resetwal重置事务日志但操作有风险建议先备份/storage/db/vpostgres/目录。如果数据库正常再检查vmware-stsd。STS服务启动失败通常是证书问题查看tail -100 /var/log/vmware/sso/vmware-sts.log如果看到“Certificate expired”或者“SSL handshake failed”说明证书还是没有正确替换。4.2 SSH登录后命令无法执行的几种情况SSH能连上但命令执行报错通常有三种情况情况一STS证书过期导致认证失败现象是登录后提示“Authentication token is expired”执行任何命令都返回这个错误。解决办法就是本文讲的时间回拨法。情况二shell被禁用现象是登录后进入Command提示符执行shell报“shell is disabled”。解决办法shell.set --enabled true然后重新执行shell。情况三磁盘满导致命令无法执行现象是执行命令时提示“No space left on device”。检查磁盘df -h清理/var/log/和/storage/log/下的旧日志。VCSA的日志轮转有时候会失效导致日志文件无限增长。4.3 证书修复脚本的兼容性说明我写的这个脚本在VCSA 6.7 Update 3上测试通过但在更早的6.7版本如6.7.0 GA上可能需要调整。主要差异在于certificate-manager的选项编号和证书路径。6.7.0的STS证书路径是/etc/vmware-sso/vmware-sts/ssl/但某些版本可能是/etc/vmware-sso/ssl/。执行脚本前先用find命令确认find /etc -name rui.crt 2/dev/null另外外部PSC部署的VCSA证书修复需要先在PSC上执行再在VC上执行。脚本里需要增加一个参数来指定节点角色。4.4 预防证书过期的日常维护建议与其等证书过期了再救火不如提前做好预防。三个建议第一部署VCSA时选择自定义证书用企业CA签发的证书有效期可以设长一些比如5年。虽然配置麻烦一点但后续省心。第二配置证书到期提醒。VCSA 6.7的VAMI界面有证书到期告警功能但默认不开启。可以在“Certificate Management”里设置提前90天告警。第三定期检查证书状态。写一个简单的检查脚本每月跑一次#!/bin/bash CERT/etc/vmware-sso/vmware-sts/ssl/rui.crt EXPIRY$(openssl x509 -in $CERT -noout -enddate | cut -d -f2) EXPIRY_EPOCH$(date -d $EXPIRY %s) NOW_EPOCH$(date %s) DAYS_LEFT$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 )) echo STS证书剩余天数: $DAYS_LEFT if [ $DAYS_LEFT -lt 30 ]; then echo 警告证书即将过期请及时处理 fi把这个脚本加到crontab里每月1号执行一次通过邮件或告警平台通知。4.5 常见问题速查表问题现象可能原因排查命令解决方法Web界面报证书错误STS证书过期openssl x509 -in rui.crt -noout -dates回拨系统时间后修复证书SSH登录后命令报认证失败STS证书过期date对比证书Not After回拨系统时间服务启动失败数据库时间戳异常tail /var/log/vmware/vpostgres/postgresql.log备份后重置数据库证书修复脚本卡住磁盘空间不足df -h清理旧日志时间同步后问题复现证书未真正续签openssl x509 -in rui.crt -noout -dates重新执行证书修复shell无法进入shell被禁用shell.set --enabled true启用shell后重试这套排查表覆盖了VCSA 6.7证书过期场景下90%以上的问题。剩下的10%通常是环境特有的配置问题需要结合日志具体分析。我在实际处理这类故障时最深的体会是时间回拨只是手段证书续签才是目的。很多人回拨时间后看到vCenter能登录了就以为问题解决了结果NTP一同步故障立刻复现。所以修复证书这一步绝对不能省。另外操作前拍快照、操作中记录每一步的输出、操作后验证所有服务状态这三个习惯能帮你避免绝大多数翻车情况。
VCSA 6.7证书过期导致无法登录的紧急恢复与修复指南
1. 故障现场还原与核心问题定位1.1 一个典型的VCSA 6.7登录故障场景早上九点运维群里弹出一条消息“vCenter打不开了网页提示证书错误客户端也连不上。”我打开浏览器访问vCenter的5480端口页面直接报SSL证书过期再试443端口同样无法建立安全连接。SSH倒是能连上但登录后执行任何命令都提示“Authentication token is expired”或者干脆卡在登录验证阶段。这种情况在VCSA 6.7环境中非常典型尤其是那些部署了两三年、当初装完就没再管过证书的测试环境或边缘业务环境。VCSA 6.7的证书体系比6.0之前复杂得多它引入了VMware Certificate AuthorityVMCA作为内部根证书所有服务证书都由VMCA签发。默认情况下这些证书的有效期是两年而STS签名证书的有效期更短只有一年。很多管理员在部署时勾选了“使用默认证书”后续也没有配置证书到期提醒结果就是某天突然发现vCenter彻底无法登录。更麻烦的是证书过期后VCSA的很多后台服务会进入保护状态连SSH登录后的shell都可能被限制导致你无法直接执行修复命令。1.2 为什么时间同步是恢复登录的第一把钥匙证书验证的核心逻辑是客户端拿到的证书其“有效期”字段必须覆盖当前系统时间。如果VCSA的系统时间已经超过了证书的Not After日期那么所有依赖证书的服务都会拒绝连接。这时候你可能会想那我直接续签证书不就行了问题在于续签证书的操作本身也需要通过认证而认证又依赖证书有效。这就形成了一个死循环。打破这个死循环最直接的办法就是把VCSA的系统时间回拨到证书过期之前。一旦系统时间回到证书有效期内vCenter的服务就能正常启动Web界面和SSH的完整功能也会恢复。这时候你再从容地执行证书续签或替换操作最后把时间同步回正确值。这个思路听起来简单但实际操作中有几个关键点VCSA 6.7的时间同步机制、SSH登录后的权限限制、以及时间修改后对数据库和日志的影响都需要仔细处理。1.3 适用场景与前置条件确认这套方法适用于以下情况VCSA 6.7的STS证书或VMCA根证书已过期导致vCenter Server服务无法启动Web界面报证书错误SSH登录后无法执行正常管理命令。你需要具备的条件包括VCSA的root密码或具有sudo权限的账户、能够通过SSH连接到VCSA的IP地址、以及一台能正常访问VCSA的终端设备。注意如果VCSA是嵌入式部署且PSC与VC在同一台机器上本方法直接适用。如果是外部PSC部署需要先修复PSC的时间再处理VC节点。在开始操作前建议先通过SSH尝试登录确认故障现象。如果SSH能登录但shell受限可以尝试执行shell.set --enabled true然后shell进入bash环境。如果连这个都做不到说明STS证书过期已经严重到影响认证服务需要直接进入时间修改流程。2. 通过SSH修改系统时间的完整操作流程2.1 SSH登录与受限Shell的突破方法用你常用的SSH工具连接VCSA的IP地址端口默认22。登录用户名用root密码是你部署时设置的。如果登录后直接进入的是Command提示符而不是bash shell说明你还在受限制的 applianceshell 中。这时候先执行shell.set --enabled true shell正常情况下你会看到提示符变成#表示已经进入bash环境。但如果STS证书过期严重执行shell时可能会报错“Failed to authenticate”或者直接卡住。我遇到过几次这种情况解决办法是先用SSH登录但不进入shell直接在 applianceshell 里执行时间修改命令。VCSA的 applianceshell 提供了一些基础命令其中就包括时间管理相关的。如果 applianceshell 也无法正常执行命令可以尝试通过VCSA的DCUIDirect Console User Interface在虚拟机控制台直接操作。但DCUI的功能有限修改时间需要进入shell所以还是得先解决shell访问问题。一个比较稳妥的做法是在SSH登录时使用-o PreferredAuthenticationspassword强制密码认证有时候能绕过一些认证异常。2.2 查看当前时间与证书过期时间进入shell后第一件事是确认当前系统时间和证书的过期时间。执行date你会看到类似Fri Mar 15 14:23:45 UTC 2024的输出。然后查看STS证书的过期时间openssl x509 -in /etc/vmware-sso/vmware-sts/ssl/rui.crt -noout -dates这个命令会输出证书的Not Before和Not After日期。对比一下系统时间和Not After如果系统时间已经超过了Not After那就确认是证书过期导致的问题。同时也可以检查VMCA根证书openssl x509 -in /etc/vmware-sso/vmware-sts/ssl/root.crt -noout -dates把这两个日期记下来后面修改时间时要确保回拨到这两个日期之前。通常STS证书的有效期是一年VMCA根证书是两年所以回拨到STS证书过期前一个月左右比较安全。2.3 修改系统时间的三种方式与选择建议VCSA 6.7修改时间有三种方式各有适用场景方式一使用date命令直接修改date -s 2023-06-01 12:00:00这是最直接的方法但VCSA默认启用了NTP同步你改完时间后NTP服务可能会在几分钟内把时间又同步回去。所以需要先停掉NTP/etc/init.d/ntpd stop然后再修改时间。修改完成后如果需要保持时间不再被同步可以暂时禁用NTPsystemctl stop ntpd systemctl disable ntpd方式二通过timedatectl命令修改timedatectl set-ntp false timedatectl set-time 2023-06-01 12:00:00这种方式更规范它会同时处理NTP同步和时间设置。但VCSA 6.7的timedatectl支持程度因版本而异有些版本会报错“Failed to set time: Automatic time synchronization is enabled”这时候还是得用方式一。方式三通过VAMI界面修改如果你还能访问5480端口的VAMI界面可以在“Time”选项卡里手动设置时间。但证书过期时VAMI通常也打不开所以这个方法只在部分场景下可用。我个人的建议是优先用方式二如果报错就用方式一配合停NTP。修改时间后立即执行date确认时间已经生效。然后尝试重启vCenter的核心服务service-control --stop --all service-control --start --all如果服务启动正常说明时间回拨已经生效证书验证通过了。2.4 时间修改后的服务恢复与验证服务全部启动后先别急着高兴。你需要验证几件事第一Web界面是否能正常登录。打开浏览器访问https://vcenter-ip/ui如果能看到登录页面并且能正常登录说明STS证书已经恢复有效。第二SSH的完整shell功能是否恢复。重新开一个SSH会话执行shell进入bash看看是否还会报认证错误。第三检查所有服务的健康状态service-control --status --all确保所有服务都是Running状态。如果有服务启动失败查看日志tail -f /var/log/vmware/vpxd/vpxd.log常见的问题是数据库服务vmware-vpostgres启动慢或者STS服务需要额外的时间来重新初始化。如果等待几分钟后服务仍然起不来可以尝试单独重启service-control --restart vmware-stsd service-control --restart vmware-vpxd实操心得修改时间后VCSA的日志时间戳会变得混乱因为日志是按系统时间记录的。这在排查问题时会造成困扰。我的做法是在修改时间前先记录当前真实时间修复完成后立即把时间同步回正确值然后重启一次所有服务让日志时间戳恢复正常。3. STS证书修复脚本的编写与执行3.1 为什么需要专门的修复脚本时间回拨只是临时手段让vCenter恢复可用。但证书本身还是过期的如果不续签或替换下次系统时间同步回正确值后问题会再次出现。VCSA 6.7提供了certificate-manager工具来续签证书但操作步骤繁琐而且STS证书的续签涉及多个服务重启手动操作容易出错。我写了一个修复脚本把整个流程自动化检查证书状态、备份旧证书、生成新证书、替换证书文件、重启相关服务、验证修复结果。这个脚本在多个VCSA 6.7环境中实测有效包括嵌入式部署和外部PSC部署。3.2 脚本核心逻辑与关键代码解析脚本的核心逻辑分为六步第一步环境检查#!/bin/bash VCENTER_IP$(hostname -I | awk {print $1}) STS_CERT/etc/vmware-sso/vmware-sts/ssl/rui.crt BACKUP_DIR/root/cert_backup_$(date %Y%m%d_%H%M%S) if [ ! -f $STS_CERT ]; then echo STS证书文件不存在请确认VCSA版本和路径 exit 1 fi mkdir -p $BACKUP_DIR第二步备份现有证书cp -rp /etc/vmware-sso/vmware-sts/ssl/ $BACKUP_DIR/ cp -rp /etc/vmware-sso/ $BACKUP_DIR/vmware-sso-backup/备份是必须的因为证书替换过程中如果出错没有备份就只能重装VCSA了。我见过有人直接删掉旧证书结果新证书生成失败最后只能从快照恢复。第三步生成新的STS证书VCSA 6.7的STS证书可以通过certificate-manager工具重新生成/usr/lib/vmware-vmca/bin/certificate-manager这个工具是交互式的脚本里需要用expect或者重定向输入来自动化。我选择用expect因为更稳定/usr/bin/expect EOF set timeout 300 spawn /usr/lib/vmware-vmca/bin/certificate-manager expect option { send 8\r } expect Continue { send y\r } expect username { send administratorvsphere.local\r } expect password { send $SSO_PASSWORD\r } expect IP { send $VCENTER_IP\r } expect Continue { send y\r } expect eof EOF这里的$SSO_PASSWORD需要提前设置或者从环境变量读取。注意certificate-manager的选项8是“Reset all certificates”这个操作会重新生成所有证书包括STS、VMCA和解决方案用户证书。执行前一定要确认备份完整。第四步替换STS证书文件certificate-manager执行完成后新的证书文件会生成在/etc/vmware-sso/vmware-sts/ssl/目录下。但有时候工具会报错证书没有正确替换。这时候需要手动复制cp /etc/vmware-sso/vmware-sts/ssl/rui.crt $BACKUP_DIR/rui.crt.old cp /etc/vmware-sso/vmware-sts/ssl/rui.key $BACKUP_DIR/rui.key.old然后从/root/certs/或者工具指定的输出目录复制新证书。第五步重启STS服务service-control --stop vmware-stsd service-control --start vmware-stsd等待30秒然后检查服务状态service-control --status vmware-stsd第六步验证证书有效期openssl x509 -in /etc/vmware-sso/vmware-sts/ssl/rui.crt -noout -dates确认Not After日期已经更新到未来。3.3 脚本执行中的常见报错与处理执行脚本时最常见的报错是“Failed to connect to VMware Directory Service”或者“SSO authentication failed”。这通常是因为STS服务没有完全启动或者SSO密码错误。处理方法是先手动重启STS服务确认服务正常后再执行脚本。另一个常见问题是certificate-manager执行到一半卡住没有任何输出。这通常是因为VCSA的某个后台服务响应慢或者磁盘空间不足。检查磁盘df -h如果/storage或/var分区使用率超过90%需要先清理空间。VCSA的日志文件很容易占满磁盘可以清理/var/log/vmware/下的旧日志。注意执行证书修复脚本前务必给VCSA拍一个快照。虽然脚本经过测试但不同环境的配置差异可能导致意外情况。快照是最可靠的退路。3.4 修复后的时间同步与最终验证证书修复完成后需要把系统时间同步回正确值。先启用NTPsystemctl enable ntpd systemctl start ntpd然后手动触发一次同步ntpdate -u ntp-server-ip如果没有内部NTP服务器可以用pool.ntp.org。时间同步后再次重启所有服务service-control --stop --all service-control --start --all最后验证Web界面登录正常、SSH shell正常、证书有效期正常、所有服务Running。这套流程走下来VCSA 6.7的证书过期问题基本就能彻底解决。4. 常见问题排查与独家避坑经验4.1 时间修改后服务无法启动的排查思路修改时间后如果service-control --start --all执行失败先看具体是哪个服务起不来。最常见的三个服务是vmware-vpxd、vmware-stsd和vmware-vpostgres。排查顺序如下先检查vmware-vpostgres因为vpxd依赖数据库。如果数据库起不来vpxd肯定起不来。查看数据库日志tail -100 /var/log/vmware/vpostgres/postgresql.log常见错误是“database files are incompatible with server”或者“could not connect to server”。前者通常是因为时间修改幅度太大导致数据库文件的时间戳异常。解决办法是用pg_resetwal重置事务日志但操作有风险建议先备份/storage/db/vpostgres/目录。如果数据库正常再检查vmware-stsd。STS服务启动失败通常是证书问题查看tail -100 /var/log/vmware/sso/vmware-sts.log如果看到“Certificate expired”或者“SSL handshake failed”说明证书还是没有正确替换。4.2 SSH登录后命令无法执行的几种情况SSH能连上但命令执行报错通常有三种情况情况一STS证书过期导致认证失败现象是登录后提示“Authentication token is expired”执行任何命令都返回这个错误。解决办法就是本文讲的时间回拨法。情况二shell被禁用现象是登录后进入Command提示符执行shell报“shell is disabled”。解决办法shell.set --enabled true然后重新执行shell。情况三磁盘满导致命令无法执行现象是执行命令时提示“No space left on device”。检查磁盘df -h清理/var/log/和/storage/log/下的旧日志。VCSA的日志轮转有时候会失效导致日志文件无限增长。4.3 证书修复脚本的兼容性说明我写的这个脚本在VCSA 6.7 Update 3上测试通过但在更早的6.7版本如6.7.0 GA上可能需要调整。主要差异在于certificate-manager的选项编号和证书路径。6.7.0的STS证书路径是/etc/vmware-sso/vmware-sts/ssl/但某些版本可能是/etc/vmware-sso/ssl/。执行脚本前先用find命令确认find /etc -name rui.crt 2/dev/null另外外部PSC部署的VCSA证书修复需要先在PSC上执行再在VC上执行。脚本里需要增加一个参数来指定节点角色。4.4 预防证书过期的日常维护建议与其等证书过期了再救火不如提前做好预防。三个建议第一部署VCSA时选择自定义证书用企业CA签发的证书有效期可以设长一些比如5年。虽然配置麻烦一点但后续省心。第二配置证书到期提醒。VCSA 6.7的VAMI界面有证书到期告警功能但默认不开启。可以在“Certificate Management”里设置提前90天告警。第三定期检查证书状态。写一个简单的检查脚本每月跑一次#!/bin/bash CERT/etc/vmware-sso/vmware-sts/ssl/rui.crt EXPIRY$(openssl x509 -in $CERT -noout -enddate | cut -d -f2) EXPIRY_EPOCH$(date -d $EXPIRY %s) NOW_EPOCH$(date %s) DAYS_LEFT$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 )) echo STS证书剩余天数: $DAYS_LEFT if [ $DAYS_LEFT -lt 30 ]; then echo 警告证书即将过期请及时处理 fi把这个脚本加到crontab里每月1号执行一次通过邮件或告警平台通知。4.5 常见问题速查表问题现象可能原因排查命令解决方法Web界面报证书错误STS证书过期openssl x509 -in rui.crt -noout -dates回拨系统时间后修复证书SSH登录后命令报认证失败STS证书过期date对比证书Not After回拨系统时间服务启动失败数据库时间戳异常tail /var/log/vmware/vpostgres/postgresql.log备份后重置数据库证书修复脚本卡住磁盘空间不足df -h清理旧日志时间同步后问题复现证书未真正续签openssl x509 -in rui.crt -noout -dates重新执行证书修复shell无法进入shell被禁用shell.set --enabled true启用shell后重试这套排查表覆盖了VCSA 6.7证书过期场景下90%以上的问题。剩下的10%通常是环境特有的配置问题需要结合日志具体分析。我在实际处理这类故障时最深的体会是时间回拨只是手段证书续签才是目的。很多人回拨时间后看到vCenter能登录了就以为问题解决了结果NTP一同步故障立刻复现。所以修复证书这一步绝对不能省。另外操作前拍快照、操作中记录每一步的输出、操作后验证所有服务状态这三个习惯能帮你避免绝大多数翻车情况。
