凌晨两点手机响了。值班同事语气有点慌“vCenter打不开了浏览器刷出来一个503 Service Unavailable。”我第一反应是vpxd服务挂了让他先把服务拉起来看看。结果他试了三四次vpxd的状态始终是启动失败日志里反反复复刷着unexpected status 503 service unavailable: cc switch local proxy failed while...这种行。我又让他翻/var/log/vmware/vpxd/vpxd.log翻到几十行报错之后基本能断定不是服务卡死而是证书过期了——这台VCSA 6.7跑了整整两年多部署之后就没碰过证书正好卡在那个时间点上。这篇文章就是把我处理这个问题的完整过程写出来。从最开始的故障判断、原因分析到实际动手做STS证书更新、修复SSL信任关系再到最后的重启验证和一堆坑适合所有正在维护vCenter 6.7的人参考。哪怕你之前没碰过证书相关操作照着这个思路走也能少走一大半弯路。1. 503报错是怎么发生的从现象到根因1.1 你看到的503和背后的日志vCenter 6.7 的 503 报错几乎可以算这个版本最经典的“老年病”了。表现非常统一打开https://vcsa地址/ui浏览器直接给你一个503 Service Unavailable什么登录框都没有。ssh 到 VCSA 里执行service-control --status能看到一堆服务处于 not running 状态或者反复重启。但如果只是普通的服务崩溃通常重启一次就能恢复而且日志也不会指向“local proxy failed”这种关键词。真正让我确定是证书问题的是下面这几条日志tail -n 200 /var/log/vmware/vpxd/vpxd.log | grep -i 503\|certificate\|ssl日志里频繁出现类似unexpected status 503 service unavailable: cc switch local proxy failed while的行。注意这里的“local proxy”不是网络代理而是vCenter内部各种服务之间的本地转发通道。vpxd要调用STS服务来验证token调用时发现证书不合法直接拒绝连接于是向上抛出了这个不咸不淡的“503”。很多人在这一步会走弯路以为要把vpxd卸载重装、或者把整个VCSA重置一遍。没必要。vpxd只是受害者不是凶手。凶手是它要依赖的STS认证链路具体来说就是那张已经过期的证书。继续往下查日志可以看到connection refused或者certificate verify failed这类关键字。1.2 STS证书过期是“主谋”的原因先解释一下vCenter 6.7里的证书体系。VCSA内部并不是只有一张证书而是按功能拆成了几个证书库store常见的有MACHINE_SSL_CERT机器SSL证书负责vCenter对外Web访问的HTTPS加密。SOLUTION_USER_CERTS解决方案用户证书里面最核心的就是STS证书。TRUSTED_ROOT受信任的根证书库。VPXD_EXTENSION_CERT、VSPHERE_WEBCLIENT_CERT等。STS服务的全称是Security Token Service安全令牌服务。它相当于vCenter体系的“发证机关”。用户登录vSphere Client时流程是客户端先向STS要一个安全令牌拿到令牌之后再拿着它去访问vpxd、vSAN health service、vSphere Web Client这些组件。如果STS证书过期了所有组件都会拒绝接受它签发的令牌哪怕签发出来也没人认。而最头疼的是STS这张证书不是“到期前一天才出问题”而是有一个提前量。证书过期之后vpxd和vsphere-client这些内部服务在启动时会校验对方的证书一旦发现不在有效期范围内直接拒绝通信。所以你在界面上看不到任何友好提示就只剩一个大白板503。1.3 证书为什么会过期自签名证书的有效期陷阱vCenter 6.7部署时默认生成的是自签名证书而不是企业CA签发的证书。自签名证书的有效期是有限的不同组件不一样有的两年有的五年。很多做运维的朋友有个误区以为“反正用的是自签名过期了也无所谓重新生成一张就行”。话是没错但难点在于你重新生成一张证书之后vCenter里其他组件、ESXi主机、外部PSC、vSphere Web Client这些角色的信任关系并不会自动跟着更新。这就引出了本文标题里的另一半——SSL信任修复。证书过期真正可怕的地方在于它的“连锁反应”。证书过期前你可能完全无感因为vCenter不像操作系统那样天天弹窗提醒。等你发现打不开的时候往往已经不只是STS这一张证书过期连带着机器证书、vpxd证书、vsphere web client证书全都处于不可信任状态。这种情况下如果只盯着某一环修修完依然是个坏的。2. 动手修复前先做这些快照、备份、状态确认2.1 必做事项快照和证书目录备份处理证书问题最忌讳的就是“直接开干”。证书这个东西是整个安全体系的骨架一旦操作到一半失败可能连SSH登录都会出问题。所以我个人的原则是能打快照就先打快照不能打快照至少把证书相关目录完整备份一遍。在VCSA上打了快照之后再执行下面的备份命令mkdir -p /root/vc-cert-backup cp -rp /etc/vmware-vmafd /root/vc-cert-backup/ cp -rp /etc/vmware-vmca /root/vc-cert-backup/ cp -rp /etc/vmware-vpx /root/vc-cert-backup/ cp -rp /var/lib/vmware/vmafd /root/vc-cert-backup/这些目录分别对应证书管理服务、证书颁发服务、vpxd服务和vmafd运行时的数据目录。有这套备份在手就算后面把证书库清空了也有退路可以回滚。另外提醒一句别只备份不做校验。备份完之后执行ls -l /root/vc-cert-backup看一眼目录大小是否正常。遇到过有人备份命令执行时报错但没看输出直接往下操作最后回滚的时候发现备份目录是空的只能干瞪眼。2.2 一条命令看清证书到底过期没有在开始修复之前先确认真的是证书过期而不是别的诡异问题。VCSA的vmafd服务里自带查询证书的命令直接用/usr/lib/vmware-vmafd/bin/vmafd-cli get-server-cert --server-name localhost | openssl x509 -noout -dates执行后你会看到类似这样的输出notBeforeMay 24 13:00:57 2022 GMT notAfterMay 24 13:00:57 2024 GMT如果notAfter已经晚于当前时间那说明机器证书还活着。但注意这一条只查了vmafd里注册的机器证书STS证书不在这里。要看STS证书需要进vecs证书库查/usr/lib/vmware-vmafd/bin/vecs-cli store list这个命令会列出VCSA里所有的证书库。然后针对每个关心的库执行/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store SOLUTION_USER_CERTS --text | egrep -i alias|not after以及/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text | egrep -i alias|not after我见过很多人的STS证书过期时间比机器证书还早一两个月。原因可能是vCenter在某个版本升级时更新过机器证书但STS证书没跟着转。所以排查时务必把MACHINE_SSL_CERT、SOLUTION_USER_CERTS、VMCA_ROOT这几个库都过一遍。如果不想进VCSA也可以在外部用openssl直接看对外服务端口证书的过期时间。比如看443端口echo | openssl s_client -connect vcsa的IP:443 2/dev/null | openssl x509 -noout -dates这就是网上经常有人问“linux查看ssl证书过期时间”怎么操作的标准答案。注意这个命令看到的是反向代理对外暴露的证书不一定是vmafd内部持有的那张但至少能让你快速判断“从外部看证书是否已过期”。2.3 判断修复范围只是STS还是整库都挂了确认证书过期之后还要判断修复范围。这里有个简单的分法如果只有SOLUTION_USER_CERTS里的STS证书过期而机器证书还是新的理论上可以只更新STS证书。如果MACHINE_SSL_CERT、SOLUTION_USER_CERTS、TRUSTED_ROOT里全部是过期的那就别纠结单点了直接走“全量重建”的路线。如果不确定具体坏在哪按“全量重建”处理反而更省事。为什么这么说因为STS证书和机器证书之间存在绑定关系。内部服务发现机器证书变了但STS证书还指向旧的指纹一样会拒绝通信。只修一半等于白修。所以大多数生产环境我建议直接重签整条证书链然后一次性把所有组件的信任关系同步好。这也是下文要讲的主要思路。3. 核心修复过程更新STS证书并重建SSL信任3.1 方案A通过VAMI图形化重签证书如果VCSA的管理端口5480还能访问那恭喜你最省事的路径摆在眼前。浏览器打开https://vcsa的IP:5480用admin账号登录。左侧菜单找到“证书”进入Certificate Management界面。6.7的这里会区分几个页面包括“机器证书”“解决方案用户证书”“证书颁发机构”“信任的根证书”。我的做法是优先在“解决方案用户证书”里找到STS对应的条目直接选择“更换证书”-“生成新的自签名证书”。如果这一步能成功等于把STS证书刷新成了新的理论上503应该立刻缓解。但实际情况往往不会这么顺利。STS证书已经过期的时候VAMI这个页面虽然能打开但执行“更换证书”时很可能报错或者一直转圈没反应。我遇到过一次页面直接提示The operation is not allowed in the current state翻译成人话就是你让我换证书但当前系统连认证都过不去我没法干。这种情况下不要硬等直接放弃VAMI改用命令行方案。另外就算VAMI能换STS证书也建议顺手把机器证书一起换掉避免过段时间机器证书过期再次引发类似问题。3.2 方案B命令行重建证书库命令行修复是真正能兜底的方案。流程比较长但每一步都是必要动作。建议先退出所有登录vCenter的客户端然后通过SSH登录VCSA。第一步停止所有服务避免在运行中换证书导致更多一致性错误service-control --stop --all这个过程会持续几分钟别中断。停止完成后必须再确认一遍服务确实已经停了service-control --status看到大面积为not running再继续下一步。第二步清理旧的证书库。这里我不建议用vecs-cli store delete去删整个store风险太大。更稳妥的是只删除对应entry。先查看每个store里的alias名称/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text | egrep -i alias /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store SOLUTION_USER_CERTS --text | egrep -i alias拿到alias之后使用entry delete删除过期证书。有些环境里STORE内部存在系统级保护直接删除会报错这时可以绕过vecs-cli直接备份并重命名底层数据目录。操作前再次确认备份完成mv /var/lib/vmware/vmafd/vecs /var/lib/vmware/vmafd/vecs.bak.$(date %Y%m%d)然后重新创建空目录mkdir -p /var/lib/vmware/vmafd/vecs注意这个动作等同于把整个证书库归零后面的步骤必须一次性做完否则服务起不来。第三步重新生成VMCA根证书和机器证书。VCSA的证书颁发服务是VMCA生成根证书用/usr/lib/vmware-vmca/bin/certool --selfca --config /etc/vmware-vmca/vmca.cnf然后生成新的机器证书私钥和证书请求/usr/lib/vmware-vmca/bin/certool --genkey --privkey /root/vcsa-new.key --pubkey /root/vcsa-new.pub /usr/lib/vmware-vmca/bin/certool --gencert --privkey /root/vcsa-new.key --cert /root/vcsa-new.crt --config /etc/vmware-vmca/vmca.cnf如果vmca.cnf里的字段和你的环境不匹配生成出来的证书CN名可能不对之后Web访问会出现域名/IP不匹配的警告。不过对于已过期的自签名证书来说能恢复系统可用的优先级远高于消除浏览器警告。第四步把新生成的证书重新导入到vecs证书库/usr/lib/vmware-vmafd/bin/vecs-cli entry create --store MACHINE_SSL_CERT --alias MACHINE_CERT --cert /root/vcsa-new.crt --key /root/vcsa-new.key再把根证书导入TRUSTED_ROOT/usr/lib/vmware-vmafd/bin/vecs-cli entry create --store TRUSTED_ROOT --alias VMCA_ROOT --cert /root/vmca_root.crt这里需要说明不同版本的6.7里alias名称可能存在细微差异如果导入时报“alias已存在”先用entry delete把旧的删除再重新导入。第五步同步STS证书。STS证书的更新不完全是“生成新证书”而是要把新机器证书的密钥信息同步给STS服务。vmafd提供了dir-cli命令/usr/lib/vmware-vmafd/bin/dir-cli service --action update --service sts --cert /root/vcsa-new.crt --key /root/vcsa-new.key这条命令的意思是把STS service的证书绑定关系更新为新的证书和私钥。执行成功之后可以再从solution user certs库里查看STS证书的过期时间确认已经变成新证书。千万不要跳过这一步。很多人在命令行里重新生成了机器证书、也导入了store但忘了同步STS服务结果重启之后依然503还在那纳闷为什么。3.3 修复SSL信任让ESXi和其他组件重新承认新证书证书换完不代表万事大吉因为vCenter和ESXi主机之间的信任还是旧关系。证书更新后最典型的现象是vSphere Client能打开但所有ESXi主机显示“证书已更改”或“主机连接已禁用”甚至SSH到主机调用vpxa服务时直接报证书校验失败。处理这个问题的核心思路是让vCenter和ESXi双方都持有对方的新根证书。先处理vCenter这一侧。在VAMI的“证书”-“信任的根证书”页面把每台ESXi当前使用的根证书导入到vCenter的TRUSTED_ROOT证书库里。ESXi的证书路径通常在/etc/vmware/ssl/下文件名是rui.crt。可以用scp把每台主机的rui.crt拷贝下来然后通过VAMI逐个导入。再处理ESXi这一侧。在每台ESXi主机上将vCenter新的根证书/root/vmca_root.crt导入esxcli system settings trustedRoot import -c /tmp/vmca_root.crt导入完成之后重启ESXi与vCenter之间的agent服务让证书重新加载/etc/init.d/vpxa restart这一步在某些场景下会被省略但只要你环境里有vSAN或分布式交换机建议不要省。vSAN集群的成员在vCenter证书变更后健康检查会长时间报证书错误只有双向信任重建干净才能消除。4. 服务重启与修复验证4.1 正确的服务重启顺序证书库重建完成、信任关系也处理完之后最后一步就是重启vCenter服务。千万别只启动vpxd一个服务要按依赖关系从底层往上拉。先启动全部服务service-control --start --all启动过程比较久15到30分钟都很正常。期间可以通过下面的命令实时观察状态service-control --status或者盯关键日志tail -f /var/log/vmware/vpxd/vpxd.log大多数情况下整套服务会在一个相对固定的顺序里依次起来。如果某个服务长时间卡在starting状态不要反复重启先看它依赖的上游服务是不是已经起来。比如vpxd依赖vmafd和vmonapivmafd没起来的话vpxd永远起不来。4.2 怎么确认这次修复真的成功了服务全部启动之后做下面几项验证第一浏览器访问https://vcsa的IP/ui看是否出现正常登录页面。如果依然503先不要慌用隐身窗口再试一次。因为旧登录页可能已经在本地缓存了无效的STS响应普通刷新可能还会命中缓存。第二用openssl确认对外证书已经更新echo | openssl s_client -connect vcsa的IP:443 2/dev/null | openssl x509 -noout -dates第三登录vSphere Client之后进入“主机和集群”逐个检查ESXi主机是否连接正常。正常情况下之前因为证书过期而报错的主机现在应该能正常显示状态不再提示证书错误。第四检查STS服务本身是否正常。可以看看STS服务对应的8443端口的证书echo | openssl s_client -connect vcsa的IP:8443 2/dev/null | openssl x509 -noout -dates如果这些验证都能通过基本可以断定修复完成。5. 常见问题排查与避坑记录5.1 常见问题速查表现象可能原因处理办法VAMI 5480能进但ui 443报503STS证书过期先尝试VAMI更换解决方案用户证书失败则命令行清库重建命令执行后证书还是老的vecs入库未生效检查alias是否冲突删除旧alias后重新导入重启服务后vpxd反复启动失败机器证书和STS证书不匹配用dir-cli重新同步sts服务的证书绑定ESXi主机显示“证书已更改”vCenter和ESXi信任关系断裂双向导入根证书重启vpxa网页提示证书不匹配警告新证书CN和访问域名不一致不影响可用性如需消除需要按企业CA签发流程重新制作内部服务时间不同步导致校验失败NTP异常先修复NTP时间同步再重新生成证书5.2 几个踩坑经验第一个坑千万别只修STS证书。我第一次遇到这个故障时觉得“问题定位在STS那就只更新STS证书”结果机器证书仍然是旧的内部服务校验时匹配的还是老指纹vpxd照样起不来。最后还是回到全量重建证书库这条路。第二个坑VAMI证书管理界面的“更换证书”按钮不一定可靠。线上环境里STS过期时VAMI页面上操作经常超时。所以我的经验是如果VAMI点一下就能成功那最好一旦出现“转圈”超过两分钟直接放弃图形界面别再反复点了。反复点反而可能让证书库状态更混乱。第三个坑更新完证书之后浏览器还一直报503。这不是系统没修好而是本地会话缓存了旧的STS令牌。用隐身窗口登录或者清一次浏览器缓存基本能恢复。第四个坑不要忘记检查NTP时间。证书校验要求系统时间在有效期内如果VCSA的时间本身就漂了哪怕证书是新生成的也一样校验不过。修复证书前顺手执行ntpq -p看一眼时间同步状态能省掉很多莫名其妙的问题。就我个人实际体感来说vCenter 6.7的证书问题不是偶发而是这个版本生命周期内必然会遇到的坎。证书过期不像硬件故障那样有预兆但也不是无迹可寻提前用openssl做个证书到期时间巡检脚本每个月跑一次然后在证书到期前三个月重新签发是成本最低的维护方式。如果你这次只是紧急恢复不妨把巡检脚本这件事排上日程下次就不用半夜爬起来对着503挠头了。