如果你负责的 vCenter 6.7 环境突然在所有人登录时跳出一个 503vSphere Web Client 页面刷不出来服务列表一堆红色第一反应大概率是“vCenter 是不是挂了” 我遇到过不止一次最后定位到根因往往不是 vCenter 本身宕机而是证书过期。尤其是 STSSecurity Token Service证书过期的时候vCenter 的各个服务之间互相认证失败对外表现为 HTTP 503账号密码输对了也进不去。这篇文章我就把从 STS 证书更新到 SSL 信任修复的整个流程完整梳理一遍包括怎么确诊、怎么操作、有哪些坑尽量让看过的人可以直接照着处理。下文涉及的命令和操作我都是基于 vCenter 6.7 接入式部署embedded实测过的外部 PSC 的场景也会在相应位置补充差异。1. 503 报错背后vCenter 证书过期为什么会引发整套服务不可用1.1 先看现象这时候 vCenter 到底“病”在哪证书过期导致的 503和 vCenter 宕机、磁盘写满、数据库连接断了的表象非常像。vSphere Web Client 打开后提示“503 Service Unavailable”vCenter 上的所有虚拟机管理操作基本停摆比较稳定的一个端口是 5480 的 VAMI 管理界面有时还能打开但登录进去也是各种服务红色。最让人迷惑的是你直接 SSH 到 vCenter 上系统正常运行内存和 CPU 也不高进程似乎都在但从 Web 层面怎么都进不去。我刚遇到这种情况时第一反应是重启 vCenter 虚拟机结果重启完之后问题依旧。后来查了 /var/log/vmware/vpxd/vpxd.log 才发现一大堆 token 校验错误再去检查 STS 证书才发现签发时间已经过期。所以遇到 503 时不要急着重启先确认证书状态往往是更高效的排查方向。1.2 vCenter 6.7 的证书体系机器证书、STS 证书、解决方案用户证书vCenter 6.7 的证书体系其实分了好几种很多人容易混在一起。平时我们浏览器访问 vCenter 时看到的证书一般是 machine SSL certificate负责 Web 界面的 HTTPS 加密。而 STS 证书是 Security Token Service 用来签发 SAML 令牌的证书vCenter 内部服务之间、vCenter 与 SSO 域之间做身份认证时全靠它。另外还有 solution user certificate是各个解决方案用户比如 vpxd、vsphere-ui、vapi 等用来向 SSO 证明自己身份的证书。这三种证书虽然都受 VMCAVMware Certificate Authority管理但生命周期和更新方式不完全一样。我们在证书过期场景中遇到最多的就是 STS 证书因为 STS 签发的令牌有效期很短但令牌的签名密钥来自 STS 证书如果这个证书过期所有依赖令牌的服务就会立刻失联。1.3 为什么证书一过期服务就立刻“翻脸”vCenter 各个服务之间的认证不是实时去查数据库对密码而是通过 STS 颁发短时令牌。令牌本身有时间戳STS 证书一旦过期新令牌签不出来旧令牌的签名验证也过不去。vpxd、vsphere-ui 这些服务在相互调用时无法完成身份确认就会拒绝请求最终 Web 层返回 503。可以简单类比成公司门禁系统你的工牌是门禁中心STS发的如果门禁中心的印章过期新工牌印不出来旧工牌上的印章又验不了真假门口保安就会把所有人拦住。vCenter 的“门口保安”就是 vpxd 和 vsphere-ui表现就是 503。在实际排障中我们还会遇到一种情况机器 SSL 证书过期浏览器会提示“您的连接不是私密连接”但 vCenter 内部服务还能用。而 STS 证书过期内部服务之间直接互不信任这才是真正的“全面瘫痪”。所以修复指南里我通常建议先区分清楚你撞上的是哪一种。2. 动手前先确诊三步判断是不是证书过期在作祟2.1 第一步查看 vCenter 服务状态锁定异常服务先 SSH 到 vCenter 或者通过 VAMI 打开控制台切换到 root 账户执行service-control --status --all正常情况下应该能看到 vmware-sts-service、vmware-vpxd、vmware-vsphere-ui、vmware-vapi 等核心服务都是 RUNNING。如果 STS 证书过期vmware-sts-service 本身可能还活着因为服务进程只是睡了但 vmware-vpxd 或 vmware-vsphere-ui 常常会进入已停止或不断重启的状态。看到服务状态不对时可以再用 systemctl 或者直接查日志确认具体原因。比如 vpxd 相关日志tail -n 200 /var/log/vmware/vpxd/vpxd.log如果日志里反复出现类似error code: 401、Failed to authenticate、SAML token validation failed、STS is not responding这样的关键字基本就可以往证书方向查了。2.2 第二步用 Linux 命令查看证书过期时间这里要重点说下“linux查看ssl证书过期时间”这件事。vCenter 本身是基于 Linux 的Photon OS所以我们可以直接用 OpenSSL 命令来检查证书有效期不用非得登录 vSphere Client。如果你想检查 vCenter Web 服务当前返回的证书过期时间可以用echo | openssl s_client -connect localhost:443 -showcerts 2/dev/null | openssl x509 -noout -dates如果要看 vCenter 本地机器 SSL 证书文件的有效期可以直接看openssl x509 -enddate -noout -in /etc/vmware-vpx/ssl/rui.crtSTS 证书通常不在这个路径它由 VMware Certificate Service 管理。最简单的办法是直接运行证书管理工具查看选项菜单或者在检查服务健康的同时看 certificate-manager 的状态。如果你熟悉 vault 和 lwcert 工具也可以查/usr/lib/vmware-vmca/bin/certificate-manager --list这里需要注意不要只看一个证书机器证书、STS 证书、解决方案用户证书要分别看。STS 证书过期往往不会直接显示在浏览器访问 vCenter 的警告里因为浏览器看到的是 machine SSL 证书可能还有效。所以线上环境里最容易漏掉的就是 STS 证书。2.3 第三步检查浏览器访问时 503 的具体页面和日志当你在浏览器里访问 vCenter 出现 503 时不要急着关掉先看看页面里面有没有更具体的提示。有时候是 vsphere-ui 返回的“503 Service Unavailable”有时候是 vpxd 报错。再到 vCenter 虚拟机里查看 vSphere UI 日志tail -n 200 /var/log/vmware/vsphere-ui/logs/vsphere_client_vici.log如果你在日志里看到java.security.cert.CertificateExpiredException那基本就是证书过期实锤了。如果看到PKIX path building failed那就是信任链问题常见于机器 SSL 证书或根证书不被信任。STP 证书过期时vsphere-ui 和 vpxd 的日志里通常会出现STS certificate validation failed或No trusted STS certificate found这类字样。整个确诊过程最好控制在 10 分钟以内。因为服务可能处于崩溃循环状态拖久了还有可能把 SSO 数据库和证书库搞成不一致后面更麻烦。3. STS 证书更新实操从生成新证书到重启 vCenter 服务3.1 更新前准备快照、备份、维护模式一个都不能少证书更新最忌讳的就是“裸奔”操作。虽然 VMware 官方有 certificate-manager 工具理论上可以自动完成但也保不齐某个环境有自定义证书或第三方 CA 证书操作过程会中断。所以我在任何证书修复现场都会强制自己先做这几件事给 vCenter Server 虚拟机打一个快照最好能保留 24 小时以上别修完立刻删除。确认 vCenter 的 NTP 时间同步正常。证书的 valid from / to 是基于系统时间的如果系统时间快了或慢了就算刚签出来的证书也可能被认为无效。如果环境中还有 vCenter HA 配置先停止切换不要让它自动 failover。备份 /etc/vmware-vpx/ssl 下的证书和密钥以防万一。外部 PSC 的环境还要多一步确认你的 vCenter 和 PSC 都是 6.7 同版本且补丁级别一致低版本连高版本经常会有证书轮换不兼容的情况。提示证书更新期间 vSphere Client 会掉线vpxd 服务会重启这属于正常现象提前通知业务窗口。3.2 使用 certificate-manager 替换 STS 证书vCenter 6.7 自带的证书管理工具路径是/usr/lib/vmware-vmca/bin/certificate-manager直接运行后会有一个交互式菜单。不同的 6.7 Update 版本菜单编号不完全一样但大体类似。以下是我在 6.7 U3 上实测的选项分布选项 1Replace Machine SSL certificate选项 2Replace STS Server certificate选项 3Replace solution user certificates选项 4Replace VMCA Root certificate选项 5Reset all certificates to default如果只是证书过期且确认是 STS 证书导致 503我的建议是先选 2 替换 STS 证书。操作过程中它会要求你输入 vCenter SSO 的管理员账号默认是 administratorvsphere.local和密码还会要求输入 SOAP 请求超时时间一般保持默认即可。它会自动生成自签名的新 STS 证书并把新证书注册到 SSO 的信任库。整个过程大概几分钟视 vCenter 性能而定。执行完之后会提示重启服务。有一点要提醒这个工具在交互式菜单下如果网络连接不稳SSH 窗口可能因长时间无操作而断开因此建议先通过 VAMI 或控制台把 SSH 超时时间改长或者直接在 vCenter 控制台里操作。3.3 要不要顺便替换机器 SSL 证书和解决方案用户证书这个问题我在实战中反复纠结过。先说结论如果环境里没有自定义证书需求证书过期时最好的做法是所有证书一起重置或统一替换而不是只修一个。因为 vCenter 内部各证书的信任关系有点像环环相扣的齿轮你换了一个 STS 证书但机器 SSL 证书马上就快过期过一两个月又坏到时候还得再经历一次全套流程。但如果你只想尽快恢复 503 故障那就先做 STS 证书让服务转起来再评估是否要更新机器 SSL 证书和解决方案用户证书。原因很简单STS 证书过期是最要命的换完它服务就能通机器 SSL 证书过期虽然浏览器会报警但多数内部服务还能跑。如果选择用 certificate-manager 的选项 3 替换 solution user certificates它会更新 vpxd、vsphere-ui、vapi 等服务账号的证书同时也会把这些新证书注册到 SSO。这样做的好处是所有服务侧的信任一次性重建坏处是操作时间更长重启服务范围更大。我个人习惯是如果 STS 证书已经过期导致服务崩了那我先用选项 2 恢复恢复后再观察 1~2 周找一个窗口期把整个证书体系拉齐。3.4 服务重启与第一次验证证书替换完成后工具会提示是否重启所有服务输入 yes 即可。如果你想手动重启可以执行service-control --stop --all service-control --start --allvCenter 服务全量启动比较慢尤其 vpxd 和 vsphere-ui 可能要等 3 到 5 分钟。启动完用下面命令确认关键服务状态service-control --status --all确认 vmware-sts-service、vmware-vpxd、vmware-vsphere-ui、vmware-vapi 都是 RUNNING 之后再用浏览器访问 https:// /ui看是否还报 503。这一步通常能解决“服务不能登录”的问题但先别高兴太早因为浏览器端很可能还会接着报证书信任错误这就是我们要做的下一件事。4. SSL 信任关系修复为什么证书更新完还是红叉或警告4.1 浏览器和客户端的旧证书缓存必须清掉证书更新完之后浏览器里可能还存着旧的证书或旧会话。最常见的表现是访问 https://vCenter-ip/ui 时浏览器提示证书无效或者直接显示红叉。这个问题不是 vCenter 没换好而是浏览器不认新的自签名证书。处理办法是重新下载并信任 vCenter 的根证书。vCenter 提供了一个公开的根证书下载地址https://vCenter-ip/cert/在浏览器里打开这个地址会看到一个下载目录一般有download.zip或者单独的.crt文件。下载后导入到操作系统的“受信任的根证书颁发机构”里。导入之后务必重启浏览器最好清理一下特定站点的缓存。因为浏览器对证书的信任决策有时会缓存会话不彻底刷新的话可能还是旧的警告页。另一个常见问题是浏览器开了 HSTS强制 https 并缓存了旧证书信息这时可以试着用无痕窗口访问。如果无痕窗口正常那就是缓存问题。4.2 vCenter 信任存储的修复别再手动改一堆文件vCenter 6.7 里所有信任关系并不是简单存在浏览器里vCenter 自身的 trust store 也要更新。用 certificate-manager 更新 STS 证书后理论上自动注册了新证书但如果你之前手动拷贝过旧的根证书或者用自定义 CA 证书则有可能出现新证书没被某几个服务信任的情况。一个比较稳妥的做法是在证书更新后重新调用 certificate-manager 选项 4 或选项 5 把整个 VMCA Root 证书也重置为标准自签名。但这要非常谨慎因为如果把根证书也换了ESXi 主机和 vCenter 之间的信任关系也要重新建立影响面一下子就大了。更保守的方法是通过 vSphere Web Client 重新连接 ESXi 主机或者对每台 ESXi 主机执行“重新连接”操作。在主机配置界面里会弹出证书告警选中“信任并连接”即可。如果 ESXi 和 vCenter 之间用的是 vSphere 标准端口 443还可能需要把各主机的指纹同步一下但这些在 vCenter Web 界面上勾选信任后就能处理好。有个小技巧如果你只是为了让浏览器不再报警可以先用 VAMI 管理界面5480 端口确认服务健康再用命令行工具验证 STS 证书是否被 vpxd 信任/usr/lib/vmware-vmafd/bin/dir-cli service list用 dir-cli 能列出当前 vCenter 信任的服务主体至少能确认 STS 服务证书是否注册在 SSO 域里。如果这里没有新证书那后面即使浏览器信任了内部服务可能还是会有认证问题。4.3 清空 vSphere Web Client 本地缓存和 Known Hosts更新证书后还有一个隐蔽的坑vCenter 所在服务器上的 known_hosts 文件可能记录着旧指纹。如果你是 SSH 到 vCenter 里操作之后再用 WinSCP 或命令行连接 vCenter很有可能会出现 “Host key verification failed”。这不是证书导致的但容易和 SSL 信任问题混淆。需要在 vCenter 的 /root/.ssh/known_hosts 里删除对应 IP 的旧记录。如果你用的是 vSphere ClientHTML5页面本地浏览器插件的缓存也会造成误导。可以按 F12 打开开发者工具在 Application 标签里清掉 Cache Storage。或者直接用一个新的浏览器 profile 去访问这种方法最快能直接排除本地缓存干扰。总之SSL 信任修复的核心思路就是让所有客户端和服务端都认识新的根证书或机器证书。只要有一层不认识就会继续报错。5. 实战避坑指南这次修复过程中容易踩的五个坑5.1 第一坑在故障现场随手点“重置所有证书为默认值”certificate-manager 菜单里有一个“Reset all certificates to default”选项看起来像是万能恢复但千万不要一上来就选它。这个选项会把 vCenter 所有证书都重置成 VMCA 默认自签名证书包括 vpxd、vsphere-ui、STS、solution user 等全部。对于纯新建测试环境没问题但在生产环境这么做会引发一连串次生故障ESXi 主机的信任失效、备份软件集成失效、vSphere Replication 和 vSAN 健康检查可能都会出问题。它更适合的场景是vCenter 里大量自定义证书严重混乱且你有充分的时间重新建立所有信任关系。所以先用选项 2 替换 STS必要时再用选项 3 或 4一步一步来。5.2 第二坑NTP 不同步新证书照样“马上过期”证书有有效期验证有效期依赖系统时间。如果 vCenter 的系统时间比真实时间快了一天刚签出来的证书可能显示尚未生效或已经过期。我在一次故障中就遇到过用户坚持说证书是刚续期的但 vCenter 始终认为证书无效。查了一圈才发现vCenter 虚拟机底层 ESXi 主机的时间快了 15 分钟导致新证书的 valid from 时间点还在未来。解决办法是先在 ESXi 主机配置里把 NTP 时间同步好再同步 vCenter 虚拟机时间然后重新生成证书。生产环境建议在 vCenter 上配置两个以上的可靠 NTP 服务器并且定时检查时间偏移。命令可以用chronyc tracking确认系统时钟处于同步状态后再做证书操作。5.3 第三坑快照没有保留足够长时间回滚无门证书更新过程中的很多报错是延迟出现的。比如你当天更新完了 STS 证书第二天才发现 vCenter 与其他组件比如 vROps、Veeam的集成不可用这时才想回滚发现快照早已被你删了那就非常被动。所以我给自己定的规矩是证书操作完至少保留快照 72 小时确认所有业务系统都恢复正常后再删除。尤其对于外部 PSC 环境vCenter 和 PSC 之间的信任变更往往有缓存传播时间快照留久一点没有坏处。5.4 第四坑vCenter 6.7 不同 Update 版本的菜单差异vCenter 6.7 的 certificate-manager 在 U1、U2、U3 里的选项编号和提示信息有细微差异。比如某些版本里选项 2 的英文是 Replace STS Server certificate而另一些版本里可能叫 Replace STS Signing certificate。如果你照着网上的教程直接按编号输入可能选错功能。靠谱的做法是先只输入 certificate-manager 打开菜单仔细读一遍选项描述确认选的是 STS 相关选项再回车。如果界面上还有“SOAP timeout”和“SSO URL”提示按照 vCenter 实际地址填写不要照抄别人环境里的 vCenter IP。5.5 第五坑修复完成后没有盯日志带着隐患上线就算看到登录页不报 503 了也不要立刻宣布修复完成。我建议至少再观察 30 分钟同时盯这几个日志/var/log/vmware/vpxd/vpxd.log /var/log/vmware/vsphere-ui/logs/vsphere_client_vici.log /var/log/vmware/sso/vmware-sso.log重点看有没有CertificateExpiredException、peer not authenticated、SSLHandshakeException这类关键字。如果这些关键字在日志里不断出现说明某个服务的信任库还是旧证书需要回到第 4 节做信任修复或者用 certificate-manager 选项 3 更新 solution user certificates。6. 证书过期后的日常体检预防下次再踩坑6.1 不登录 Web 界面也能批量查证书剩余天数经历了一次 503 之后我相信你会理解“定期查看证书过期时间”有多重要。在 Linux 环境下可以写一个简单的循环脚本检查多台机器上证书的过期时间for host in vcsa-01 vcsa-02; do echo $host: echo | openssl s_client -connect $host:443 -servername $host 2/dev/null | openssl x509 -noout -dates done如果是检查本地证书文件也可以把指定证书文件路径作为参数。建议把 vCenter 机器 SSL 证书、STS 证书、解决方案用户证书的有效期都记录到一张表里每月检查一次。如果你只想快速看剩余天数可以用下面这个命令openssl x509 -in /etc/vmware-vpx/ssl/rui.crt -noout -enddate -checkend 2592000-checkend后跟秒数如果证书在 30 天内会过期命令会返回非零状态适合写进监控脚本。6.2 给 vCenter 证书加监控告警vCenter 自身的 VAMI 管理界面可以配置证书告警吗在 6.7 里VAMI 可以展示证书有效期但没有太灵活的第三方告警。常见做法是把你刚才写的 openssl 检查脚本接入 zabbix、Prometheus 或者 vRealize Operations定期采集证书剩余有效期。我自己的环境里会把 30 天作为 warning7 天作为 critical。因为 vCenter 团队申请维护窗口通常需要提前一两周等只剩 7 天再操作会很紧张。另外vCenter 里的证书有效期并不是固定的。VMCA 默认签发的证书有效期为 10 年实际上 vCenter 6.7 中很多证书默认有效期是 2 年但不同组件和不同 CA 策略可能不一样。不要凭记忆判断必须实际查。6.3 建一份自己的证书台账比供应商知识库更管用很多团队都有这样的经历出了故障后开始翻找“上次是谁更新的证书”结果发现没有记录。证书台账不需要做成多复杂的系统一张简单的表格就够了。需要记录的信息至少包括证书用途machine SSL、STS、solution user、VMCA Root证书文件路径或登录管理界面入口签发机构VMCA、内部 CA、公开 CA到期日期和序列号上次更新时间和操作人员每次以证书为主题做变更时随手更新一下这张表遇到问题时能省好多时间。尤其是 STS 证书到期这种故障如果台账里明确写了预计到期时间你完全可以提前几十天就申请窗口根本不用等到 503 爆发。按我个人的习惯每次做完这类修复后还会顺手做一次“证书基线导出”。用 certificate-manager 或 dir-cli 把当前所有证书信息导出到文本保存下次再出问题时有参照物能很快判断是哪个环节的信任断了。vCenter 的证书体系并不复杂但确实是个“平时想不起来、出问题就要命”的部分。经过这次从 STS 证书更新到 SSL 信任修复的完整流程我最大的体会是不要把 503 单独当成服务问题而要有意识地联想到证书。排查时先看时间同步再看证书有效期最后才是服务重启。如果你能提前用脚本做好监控和台账这类故障其实完全可以避免。