vCenter证书过期修复实战：certificate-manager重置与密码恢复全指南

1. 写在动手前：vCenter证书过期到底是个什么坑

先聊几句题外话。干虚拟化运维的朋友，多少都经历过这种场景：某天早上打开vSphere Client，登录页还能正常显示，输完账号密码点登录，结果直接报错“HTTP状态500”或“无法连接服务器”；或者平台里的虚拟机跑得一切正常，但VC上的任务列表、告警、日志全都刷不出来，看哪哪儿都不对劲。如果你同时发现vCenter Server Appliance（也就是常说的VCSA）的Web管理界面还能开，但vSphere Client登录始终失败，那九成九是证书过期了。

这个“证书过期”的触发点其实挺隐蔽的。VCSA在部署时会自动生成一套内部证书体系，默认有效期是两年。很多企业内部部署VCSA之后，压根没人记得证书还有到期这回事，等报警出来的时候，整个管理中心已经处于半瘫痪状态。这时候vmware官方网站上提供的修复工具就是certificate-manager，它被内置在VCSA的命令行环境里，专门负责替换、续期、重置vCenter的各类证书。

这篇博文，我会先讲清楚vCenter里面的证书体系是怎么组织的，把修复之前必须做的备份、检查、环境准备全部交代清楚，然后再详细演示用certificate-manager修复过期证书的完整流程，最后把“密码重置”这个很多人一着急就卡住的操作单独拎出来讲。整个实操我在vCenter Server 7.0和8.0上都验证过，命令基本通用，差别我会在文章里单独指出来。

另外说明一下，下面涉及的所有操作，默认你已经能够通过SSH登录到VCSA，或者能够进入VCSA的DCUI（Direct Console User Interface）界面。要是连SSH都没打开，建议先用DCUI把SSH服务开起来，否则后面所有命令都敲不了。

2. vCenter证书体系与过期后的典型故障

2.1 三种证书的角色划分

在正式执行修复操作之前，先花点时间理解VCSA里的证书关系，否则做着做着你很容易搞混该用哪个菜单、该重启哪个服务。VCSA里的证书主要分三类：

• VMCA根证书：VMCA（VMware Certificate Authority）是vCenter内置的证书颁发机构，VCSA在部署时自动生成，它签发了后面所有内部证书。
• 机器SSL证书：也叫machine SSL certificate，用于保护vSphere Client与VCSA之间的HTTPS通信。浏览器访问https://vcsa-ip/ui时用的就是这张证书。
• 解决方案用户证书：包括vpxd、vsphere-webclient、sts等组件各自的证书，它们由VMCA颁发，每个组件各拿一张，用于组件之间的内部信任。

在VCSA 7.0及以后版本中，VMCA作为根证书默认只签发机器SSL证书和解决方案用户证书。当VMCA根证书过期，或者由VMCA签发的子证书过期，整套信任链就断了。

很多运维朋友只盯着“浏览器打不开”这个表象看，其实证书过期的影响远不止登录页面报错。比较典型的故障还包括：vCenter的单点登录验证失败，报错“Cannot authenticate user”、主机无法在vCenter中完成连接（esxi主机断开后重新加不进来）、分布式交换机配置无法下发、备份任务异常等等。因为vCenter各个组件之间是通过内部证书互相认证的，只要其中一个环节过期，整个信任链就崩了。

2.2 证书还剩多少天才到期？先会查再会修

所有修复操作的第一步，都是确认到底哪些证书过期了，距离过期还有多少天。判断证书有效期的方法不止一种，我列几种常用的：

第一种是直接在浏览器地址栏访问vCenter的Web服务地址，点开地址栏的小锁图标，查看证书的详细信息。这种最直观，但只能看到机器SSL证书，看不到其他组件内部证书。

第二种是登录VCSA的Bash shell后用openssl命令直接看。比如机器SSL证书默认路径在/etc/vmware-vpx/ssl/rui.crt，可以执行：

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

这条命令会直接显示证书的notBefore和notAfter，一眼就能看到过期时间。

第三种就是通过vCenter自带的证书管理工具来查看，即后面我们要反复使用的certificate-manager：

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

进入到主菜单后选择选项1（就是检查证书有效期的那个菜单），它会列出当前所有内部证书的过期时间。这个方法最全面，能覆盖所有组件的证书状态。

注意：如果vCenter已经处于证书过期导致的半瘫状态时，选项菜单可能响应比较慢。主要是身份校验环节卡住了，属于正常现场表现，耐心等一下。

2.3 硬件环境与版本要求

证书修复这个操作，虽然看起来是执行几条命令，但本质上它要重启vCenter内部的一堆服务，什么vpxd、vsphere-client、sts、vcha等等，期间管理面会整段不可用。因此建议在业务低峰期执行，同时提前做好以下准备：

• vCenter备份完整体，至少确认最近一次备份是可用的。证书修复的失败率不算高，但一旦中途出状况，有备份心里不慌。
• 至少有DCUI或SSH其中一个通道可用。证书过期不影响SSH登录，这是命根子，建议提前把SSH开关打开。
• 断开vCenter HA的自动故障转移。如果有vCenter HA环境，先把主动节点与被动节点的同步关系解除，否则修复过程中容易误触发切换。
• 记录好当前vCenter版本与build号，方便修复后对比服务版本是否有异常。

3. 修复方案选型：为什么直接用certificate-manager

3.1 三条技术路线的对比

网上搜vCenter证书过期修复，能找到的办法大致有三类：

第一类是用Windows版vCenter时代的“证书重新生成”图形化工具。这一套在VCSA里面已经不存在了，对于部署在Linux底层上的vCenter Server Appliance来说完全不适用。

第二类是直接用openssl等工具在底层手工重做全部证书，然后再把新证书导入vCenter对应目录，手工修改权限、做配置衔接。这个方案理论上可行，但操作步骤非常繁琐，涉及的组件至少十几个，任何一个地方的权限或者属主不对，修完反而比修之前更糟。我见过不少把自己环境搞到最终只能重装vCenter的案例，都是死磕手工方案走火入魔的。

第三类就是我们今天要讲的certificate-manager工具，它是VMware官方提供的证书管理入口，不需要手工改文件，所有组件的证书生成、替换、同步全部自动化完成。用它来做修复，实际上是在VMCA和机器SSL证书层面做整体恢复。

所以选型的结论很明确：VCSA环境统一用certificate-manager，Windows vCenter Server用certificate-manager对应的Windows工具，能不改文件的手工方案绝不碰。

3.2 certificate-manager能做什么不能做什么

certificate-manager主要提供五个核心能力：

• 选项1：检查证书有效期
• 选项2：替换机器SSL证书
• 选项3：替换解决方案用户证书
• 选项4：替换VMCA根证书（这个在证书过期修复中很关键）
• 选项5：重置所有证书（将vCenter的证书体系恢复到默认状态）
• 选项6：替换证书授权机构的根证书

在证书过期的场景下，我们通常只要动两个操作：一个是选项5把整套证书重置成默认，另一个是选项4把VMCA根证书替换为新的自签名根证书。多数情况下，选项5就能解决90%的证书过期问题。

需要提前泼一盆冷水：certificate-manager解决的是“vCenter内部信任链”的问题，不会帮你申请商用的公共可信证书，也不会自动延展现有证书的有效期。它做的事情本质上是“推倒重来”——用新的自签名证书替代旧的过期证书，让各个组件重新建立信任关系。

3.3 我需要重新理解一下“密码重置”这个环节

标题里提到了“密码重置技巧”，这点在实际运维中确实经常和证书问题关联在一起。原因是：如果vCenter过期时间太长，超过半年以上，你会发现除了服务不可用之外，连SSH登录时的root密码也可能已经过期了。这是因为VCSA的root密码默认有安全策略，有效期是90天（不同版本有差异），到了时间就会要求必须修改，否则登录直接被拒。

所以做证书修复时最怕遇到的事是：证书过期导致Web登录不了，同时root密码又因为过期导致SSH登录不上，两条路都断了，只能靠DCUI来应急改密码。而DCUI的菜单只提供“修改root密码”选项，没有提供“查看密码过期状态”的功能，所以很多人会在这一步卡死。

为了让你在证书修复过程中不至于陷在这个坑里，我会在第4节讲完证书修复后，单独用一整节来梳理密码重置的几种场景和操作方法。把“证书修复”和“密码重置”两个问题放一起讲，是因为它们往往是成对出现的。

4. 手把手实操：certificate-manager修复过期证书全过程

4.1 第一步：通过SSH登录VCSA环境

这一步原本没啥好说的，但考虑到不少人使用的是高版本OpenSSH客户端，与VCSA内置的旧SSH服务之间存在密钥交换算法不兼容的问题，会直接报错“no matching key exchange method found”。这里给出一个保险的连接方式：

ssh root@<vcsa-ip> -oKexAlgorithms=+diffie-hellman-group14-sha256

加入-oKexAlgorithms参数后，就显式指定了密钥交换算法，可以绕过VCSA老版本OpenSSH与新版客户端的兼容性问题。如果你用的是Xshell、SecureCRT这类工具，工具本身会自动适配，一般不会遇到这个报错。

登录进去之后，先确认一下自己当前的版本：

vpxd -v

如果vpxd服务因为证书问题已经挂掉了，这条命令可能会报错，没关系，继续往下走。只要能通过SSH进去，就可以动证书修复的念头。

4.2 第二步：进入certificate-manager主菜单

执行以下命令：

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

命令跑起来后，你会看到一串菜单选项。此时注意，工具默认会连接本地vCenter数据库，如果vCenter服务处于不正常状态，这里可能需要等待一段时间。等到菜单完整出现后，按提示输入对应数字并回车。

在这里我要特别提醒一句：菜单操作全程不要使用Ctrl+C中断。不少朋友在等待过程中以为卡死了，忍不住来一下Ctrl+C，结果导致配置锁定文件残留，下次再跑certificate-manager就会提示“another instance is running”，白白增加一个修复步骤。

4.3 第三步：选择修复对应选项

证书过期的修复场景，最常用的是选项5（Reset all certificates）和选项4（Replace VMCA Root certificate with a new certificate）。

• 如果vCenter内的所有证书都是自签名，且没有使用企业自定义的CA证书体系，直接用选项5，把整套证书全部重置为VMCA重新生成的默认证书，简单粗暴，问题解决得也彻底。
• 如果vCenter原本就使用了企业CA签发的证书作机器SSL，则需要先记录已导入的证书路径，然后在选项2（替换机器SSL证书）里重新导入新证书。但从问题描述的“证书过期”来看，场景大概率是自签名证书，这里重点讲选项5。

选择选项5后，工具会提示确认信息，输入y回车继续，接下来的流程会自动完成所有证书的重置。整个过程大概需要5到10分钟，取决于VCSA的性能负载。期间工具会打印出每个步骤执行的状态，看到“Successfully reset all certificates”之类的输出，说明重置过程已经完成。

4.4 第四步：重启全部vCenter服务

证书重置完成后，certificate-manager会在结束阶段自动尝试重启相关服务，但实际经验是自动重启经常不彻底。为了确保修复结果，建议手工重启一次完整的管理服务：

service-control --stop --all service-control --start --all

注意，在VCSA 7.0及8.0上，service-control --all只能控制vCenter内核心服务，不包括VAMI和单独开启的SSH服务。执行之后耐心等待vCenter集群内的vpxd、sts、vsphere-client等全部启动，整个过程可能持续5到15分钟。

验证服务都起来了没有，可以这样：

service-control --status --all

看每个服务的输出是否为“Running”。如果有个别服务处于“Stopped”状态，再单独补一条：

service-control --start --name <service-name>

4.5 第五步：刷新浏览器缓存并重新登录

服务起来后，浏览器访问https://vcsa-ip/ui，第一次打开时大概率会遇到新证书不被信任的提示。这时候把旧的证书缓存清一下，换到无痕/隐私窗口，或者用另一台干净的客户端去登录，就能正常看到登录页了。

这里再提醒一下，vSphere Client（HTML5）登录页默认地址是/ui，后面别漏了。另外，如果之前有在浏览器里保存过旧的证书例外，新证书一换，旧例外会导致连接报错，所以遇到打不开的情况先检查浏览器是否还保存着旧的证书信任记录。

实操成功以后，原来UI上那些报错、服务异常告警应该全部消失，esxi主机和虚拟机的信息能正常看到，任务与事件列表也会恢复刷新。

5. 修复过程中会遇到的密码重置与应急恢复

5.1 场景一：root密码过期导致SSH无法登录

这是我在实际操作中遇到频率最高的情况。VCSA的root密码策略默认有效期是90天，无论Web界面登录还是SSH登录，只要密码到期就必须先修改密码，否则任何登录方式都会被拒。

这时候唯一的入口就是DCUI。前往控制台界面（物理控制台、ESXi Web控制台或远程KVM），在DCUI主界面按F2进入登录配置，选择“Troubleshooting Mode Options”，然后在其中找到“Enable SSH”对应的选项先确保SSH服务是开启的。然后再回到“Configure Root Password”菜单，输入新密码完成修改。

修改完root密码后，SSH登录就不会再提示密码过期了。需要注意，DCUI修改的密码长度和复杂度要求比传统Linux下的passwd规则严格不少，建议使用10位以上、包含大小写字母和数字及特殊字符的组合。

5.2 场景二：certificate-manager提示密码不匹配

还有一种场景：SSH能登录，root密码也没过期，但执行certificate-manager时提示“Unable to authenticate against vCenter SSO”或者“SSO password incorrect”。

出现这个问题的原因，通常是vCenter的SSO管理员密码（默认是administrator@vsphere.local）和系统root密码都变了，但certificate-manager在启动时需要访问SSO。此时需要用SSO管理员的密码做校验。

解决办法是先确认SSO管理员密码是否有效。在SSH中输入：

curl -k -u administrator@vsphere.local -i https://localhost/rest/com/vmware/cis/session

这条命令会尝试调用vCenter的REST API，如果返回201并且带session id，说明SSO密码没问题。如果报401，说明记的SSO密码有误。

SSO密码遗忘的情况，需要先通过“vdcadmintool”重置，工具路径在：

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

进入工具后选择选项3（Reset account password），输入需要重置的UPN（例如administrator@vsphere.local），按提示操作即可。重置过程中会要求输入vmdir的LDAP密码，这个路径也在这个工具的功能里能查到。

5.3 场景三：vCenter服务反复启动失败时的兜底手段

如果证书修复或者密码重置之后，vCenter服务仍然没办法正常起来，vpxd状态一直异常，这时就不要再反复重启服务了。正确的兜底手段是确认是否需要恢复vCenter的配置数据库。

VCSA本身带有文件级别的备份与恢复机制，如果之前配置过备份任务，可以借此恢复到修复前的状态。但注意，恢复备份操作会把包括证书在内的所有配置整体“回滚”，如果你是因为证书过期才折腾的，恢复出来的旧证书仍旧是过期的，等于白忙。

更靠谱的方法是：先确认vCenter是“证书过期”导致的不可用，还是“vpxd服务自身状态异常”导致的不可用。通过执行：

/usr/lib/vmware-vpxd/bin/vpxd -v

看版本号能否正常输出来判断vpxd的启动基础是否完好。如果版本号能出来，就结合日志看vpxd日志：

tail -n 200 /var/log/vmware/vpxd/vpxd.log

日志里如果反复出现证书相关错误，回到第4节把证书重置流程再走一遍；如果报的是数据库连接错误，就要走数据库层面的排查了。

5.4 补充：麒麟系统和其他平台的密码重置参考

这篇博文虽然聚焦在vCenter，但搜索热词里出现了大量“银河麒麟”“openeuler”“华为交换机”相关的内容，顺手多写一段。vCenter的底层系统本身是定制的Photon OS，密码重置逻辑和普通Linux发行版有差异。但如果你在同一个物理环境里还管理着麒麟V10、openEuler 22.03或CentOS，平时遇到root密码遗忘，操作思路基本一致：

• 单用户模式：重启系统，在GRUB菜单上按e进入编辑，找到linux这一行，在末尾加上“single”或“rd.break”（根据发行版选择），按Ctrl+X启动进入救援模式，再使用passwd命令重置root密码。
• 使用LiveCD挂载根分区：用启动U盘引导后，挂载根分区，通过chroot进入原系统，再执行passwd root。

这几个平台具体到命令与GRUB版本（GRUB2还是旧版GRUB）会有些微差别，但整体套路大同小异。遇到这类问题如果实在拿不准，建议直接打开发行版官方文档查对应的恢复流程，不要随便拿网上的通用方案硬套。

6. 高频故障自检与经验总结

6.1 证书修复高频问题速查表

我把实施证书修复过程中比较容易踩的坑整理成一个速查表，方便你实操时对照检查：

上表只是我平时最常用的排查路径，真正实施时如果遇到解不开的问题，还是要优先翻/var/log/vmware/vpxd/下的日志，以及/var/log/vmware/vmca/下的证书管理日志，两边对照着看，定位效率会高很多。

6.2 避免把环境“越修越坏”的几个习惯

第一，永远不要直接删VCSA上的原始证书文件。有些帖子为了图省事说“把/etc/vmware-vpxx/ssl/下的文件删了重启就会自动重建”，这个操作在部分旧版本上也许能成功，但在VCSA 7.0以后，删掉证书文件会导致服务起来时读不到配置，反而把问题扩大化。正确做法是全程使用certificate-manager。

第二，修复前一定断开vCenter HA。如果你在vCenter HA环境下执行证书重置，同步到被动节点时往往无法完全同步，在你不知情的情况下，下次切换后证书问题会再次出现。我的习惯是修复前先把HA置为关闭，全部修好之后再重新启用。

第三，密码改动后要在同一个工作窗口内完成证书操作。因为好几类密码在VCSA里是联动的，比如vSphere SSO的LDAP登录密码和系统root密码重置时间都有关联，如果你改完密码后又隔了好几天才来做证书修复，中间很可能因其他策略触发额外问题，增加排查复杂度。

6.3 做一个不会过期的运维习惯

说到底，vCenter证书过期这件事，不是技术难度高，而是容易被遗忘。与其每次都从故障中杀出一条血路，不如在环境稳定的时候就把监控和巡检做起来。

比较建议的做法是每年固定做两次证书有效期检查，可以用最简单的定时任务执行以下命令：

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

或者更直接的，把第2节里讲到的openssl检查命令写成脚本，把有效期小于60天的证书单独标红，配合短信或者企业微信做告警推送。给自己的环境加一道这样的保险，远比等到故障发生再熬夜修复来得划算。

根据我个人的经验，证书修复这个操作，最让人心惊的倒不是命令执行那十几分钟，而是前面确定“问题到底出在哪一层”的过程。只要确认了是证书体系损坏或过期，剩下的流程跟着certificate-manager走，基本都能安全落地。密码重置这个东西其实只是一个绕不开的前置动作，卡住了就按DCUI或者vdcadmintool的思路去解，比硬着头皮猜测要高效得多。希望这篇文章能帮到正好在跟vCenter证书问题死磕的你。