VCSA证书过期修复实战：certificate-manager重置与密码恢复

VCSA 的证书过期，是很多运维同行最不想碰、但迟早要碰的问题。我用 certificate-manager 处理过好几回 vCenter 证书过期，从 6.x 一直做到 8.x，这套流程也被我在多个客户现场验证过。这篇文章就把完整的处理过程、命令细节和踩坑经验都写出来，顺带把配套的密码重置技巧一并讲清楚，不管是刚接手 vCenter 的新手，还是被故障通知打断了节奏的骨干，应该都能照着走通。

1. 证书过期不是小事：先搞清楚你在面对什么

1.1 证书过期后那些让你抓狂的症状

VCSA 的证书体系，本质上是一套内部信任链。vCenter 里的每个服务——从 vSphere Client 到 vpxd、vpostgres、sts、vapi-endpoint——彼此通信时都需要拿证书来证明身份。可以把它想象成公司大楼的门禁卡：之前你天天刷卡进出没感觉，一旦门禁卡到期或者后台系统判定它无效，你连走廊都进不去，更别提进机房了。

证书刚过期的那一两天，故障现象非常隐蔽，通常会从下面几个方向陆续浮现：

• 打开 vSphere Client，登录页面能出来，但输入账号密码后一直转圈，或直接提示 SSL certificate verification failed
• 已经在浏览器里放过行的老环境，突然出现证书告警，而且证书详情里显示的过期日期已经是昨天
• 使用 vSphere API 或 PowerCLI、Terraform 这类接口工具做自动化时，连接全部失败，日志里全是 SSL 错误
• vCenter 的系统配置页面里，服务状态一列亮起大面积的黄色或红色，伴有 vmafd、vmca、vmon 相关的报错
• 对 ESXi 主机做重新连接、添加主机操作时，需要重新验证指纹，有时直接报证书已过期，主机加不回来

这些症状往往是连着出现的。为什么？因为 vCenter 的证书不是孤立的，所有证书都托管在 VECS（VMware Endpoint Certificate Store）里，服务之间通过信任链互相校验，一个节点出问题，整条链路都开始报错。

1.2 为什么证书问题容易被拖到最后一刻

我见过不少环境，vCenter 从 6.5 升到 6.7，再到 7.0、8.0，证书一直没换过。VMCA 给机器证书签发的默认有效期是十年，长归长，但项目生命周期里动辄三年一次升级、两年一轮大迁移，中间人员来来去去，文档交接往往只写了 IP 和账号，没人提证书什么时候到期。

等到某天 client 弹窗提示证书过期，运维才发现原来 VAMI 里的证书明细页已经红了一大片。

而且时间漂移也会让过期时间提前爆发。证书校验靠的是系统时间，一旦 vCenter 或者浏览器的本地时间差出几个小时甚至一天，本来还有几十天有效期的证书，在校验时会被认定为过期。这种问题经常被误判成证书坏了，实际只是 NTP 没同步好。所以后面我会把时间检查作为修复前的一个固定步骤。

1.3 动手前先确认环境信息

翻车的人和翻车事故的共同点，都是没确认环境就上手。证书修复工具在不同版本的 VC 上，命令和选项有差异，所以我每次开工前都会先回答下面几个问题，并把答案记下来：

这些信息直接决定你走 renew 重置还是 replace 替换。如果本来就是企业 CA 签的证书，用 renew 会把整套证书重置成 VMCA 签发的，业务上如果要求合规证书，那就不能这么干，你需要走证书替换流程。弄错了方向，修完反而更麻烦。

2. 修复前的关键准备与备份策略

2.1 给 vCenter 拍一个快照，别拍完就忘

不管你的 vCenter 是跑在另一套 vSphere 环境里，还是跑在 Workstation 上，操作前做快照基本是我处理这类问题的默认第一步。证书重置虽然属于官方支持的常规操作，但中间涉及服务重启、VECS 写入、SSO 验证等多个环节，任何一个环节由于环境差异出问题，都可能把环境拖进更糟糕的状态。快照就是你的后悔药。

做快照时有几个细节容易踩坑：

• 快照别放在 vCenter 虚拟机当前所在的同一个数据存储？放同一数据存储不是不行，但如果该存储剩余空间紧张，快照增量可能直接把存储写满。稳妥的做法是检查存储剩余空间后再落点。
• 快照前建议勾选包含虚拟机内存，这样能保留服务运行状态，恢复时更平滑。
• 快照完成后，先去存储侧确认快照文件生成，不要拍完就当没事。曾经遇到过有环境快照失败，但 UI 上显示成功，后续恢复时才发现根本没有可用快照，只能全部手工重建。
• 快照保留时间不要过长，本次证书操作验证通过后，尽快删除快照，避免虚拟磁盘持续膨胀。

如果你用的是 vCenter Server 的文件备份功能，也需要在重置前做一次，备份文件存到外部位置。证书重置有概率影响 SSO 相关配置，单一快照不足以防住所有风险。

2.2 用 certificate-manager 给证书做一次专项备份

certificate-manager 是 VCSA 自带的证书管理工具，路径通常在 /usr/lib/vmware-vmca/bin/ 下。它最核心的职责就是证书的列出、备份、恢复、重置、替换。在做任何覆盖性操作前，先执行证书备份：

cd /usr/lib/vmware-vmca/bin ./certificate-manager certificate backup --password '你的备份密码'

执行完，工具会在本地生成一个以时间戳命名的目录，例如 /root/vmware-certs/backup_2025-01-20-15-30-00/，里面包含私钥、证书链、VECS 相关快照。此时立刻做两件事：

1. 把这个目录整体复制到 VCSA 之外的安全位置
2. 把 --password 后面那个备份密码记录到密码管理库

我见过不止一次这种情况：备份做完了，备份密码随手写在某个文本文件里，后来想恢复时怎么都找不到；或者备份密码设成了和 root 密码一样的，结果 root 密码被同事改掉，备份等于废了。certificate-manager 的备份密码是独立设置的，既不校验 SSO 密码，也不校验系统密码，它只是对备份文件做加密保护，所以必须单独管理。

和快照一样，备份只是准备动作，不是解决动作。你备份的是当前系统里证书体系的全量状态，万一重置中途失败，执行 restore 就能把整套证书体系恢复到操作前的状态。

2.3 提前备好五把钥匙

证书修复过程中，会交互式地要求输入多个账号和密码，如果临场发现某个密码不知道，整个流程会卡住。我的习惯是把这些信息先列在一个临时表格里：

很多同行在修复前只确认了 root 和 SSO，到备份密码一步才想起来，又重新去翻记录，多花不少时间。提前备齐，流程会顺畅很多。

3. 手把手完成证书重置：certificate-manager 全流程

3.1 判断当前证书状态，先别急着重置

每次遇到证书过期的工单，我做的第一件事不是重置，而是判断到底是不是真的过期、过期的是哪些证书。远程环境可以用一条命令快速查看：

openssl s_client -connect vcenter.example.com:443 -servername vcenter.example.com 2>/dev/null | openssl x509 -noout -dates

返回的 notBefore 和 notAfter 就能看出证书是否真的过期了。如果返回的是 unable to get local issuer certificate 而不是明确的过期时间，那说明问题可能出在信任链，而不是单纯到期。

进到 VCSA 本地后，更精确的判断是通过 certificate-manager 的 list 命令：

./certificate-manager certificate list

这个命令会列出 VECS 里保存的各类证书：Machine SSL Certificate、Solution User Certificates、VCSA Certificate、Trusted Root Certificates 等，每一类都带到期时间。你会经常看到一种情况：vpxd 使用的证书还没过期，但某个 solution user 的证书已经过期了，于是整个服务都报错。这类细节在界面里不容易定位，必须靠命令行。

如果只是个别 solution user 证书过期，也可以只针对出问题的证书做替换或刷新；但考虑到 vCenter 内部是一个信任链，多数情况下我把证书整体重置一遍更省心，尤其是在证书即将大面积过期的时候。

3.2 新版与旧版命令路径：renew 还是 reset

在动手之前，先把命令路径捋清楚。旧版本（6.x 和 7.0 早期）里，certificate-manager 的常规操作是 reset，有时也写作 --reset-certificates：

./certificate-manager certificate reset

而在 7.0 Update 2 及之后的版本，官方把重置为 VMCA 签名证书的语义改成了 renew，reset 这个选项逐渐不再推荐：

./certificate-manager certificate renew

如果不确定当前版本用什么，最稳的方法是直接看帮助：

./certificate-manager --help

我处理过一台 8.0u3 的 vCenter，运行 certificate reset 时提示该选项不再可用，换成 certificate renew 一次通过。所以请记住：别照抄网上老教程的命令，先看当前环境的帮助再执行。这一步能省掉很多命令不存在的困惑。

3.3 交互式执行证书重置：步骤拆解

正式执行前，再确认一遍：

• 当前用户是 root
• SSH 已开启，或已登录 DCUI 进入 shell
• VAMI 5480 端口能访问（用于后续验证）
• 时间同步正常：用 date 命令查看当前时间，确认和真实时间误差在 5 分钟以内

然后执行：

cd /usr/lib/vmware-vmca/bin ./certificate-manager certificate renew

执行过程中，工具会开始逐项检查当前证书体系，随后会出现类似 Continue with certificate renewal? [Y/N] 的确认提示。这里必须输入 Y。之后部分版本会要求提供 SSO 管理员账号和密码，输入 admin@vsphere.local 以及对应密码。这一步的作用是让工具以域管理员的身份向 vmafd 和 VECS 写入新的证书条目，而不是单独去改某个服务的文件。

实际执行时，页面大概是这样的：

[root@vcenter bin]# ./certificate-manager certificate renew ... Do you wish to continue? [Y/N]: Y Provide SSO administrator password: ******** ... Certificate renewal completed successfully.

整个流程大概会持续几分钟到十几分钟，视环境配置和服务数量而定。期间不要断开 SSH，不要让会话超时，更不要开着其他管理操作同时修改 vCenter。命令执行完成后，页面会提示证书已成功更新。

有些版本的 renew 流程会自动重启相关服务，有些版本则不会。保险起见，无论提示是否要求重启，我都会在确认证书已经更新后，重启一次全部 vCenter 服务：

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

这条命令执行时，vCenter 会短暂对外不可用，属正常现象。执行完成后，再到 VAMI 的服务页面里看每个服务的运行状态，确认没有红色告警。

3.4 重置后的最终验证

替换完证书，验证不能只停留在能打开登录页。我的验证清单比较固定，基本能做到五分钟内完成覆盖：

• 用无痕窗口打开 https:// /，确认浏览器不再提示证书不受信任；如果有提示，查看证书详情里的颁发者和有效期，确认是不是刚生成的新证书
• 用 admin@vsphere.local 正常登录 vSphere Client，进入系统配置查看证书和信任关系
• 在系统配置中查找证书管理页面，确认 Machine SSL Certificate 与 Solution User Certificates 的过期时间已经更新，错误项消失
• 如果环境里有独立 ESXi 主机，重新执行一次添加主机或重新连接，确认主机的指纹校验能被信任
• 如果 vCenter 通过 vCenter HA 或 Linked Mode 与其他节点关联，把对应节点的同步任务跑一遍，确保组件间的信任也恢复

验证过程中如果遇到某一项仍报证书错误，不要急着反复重跑 renew，先去看对应服务的日志，确认是证书链没同步，还是服务没正常重启。有些环境在服务全部起来后，首次验证时看到的问题会自动消失，这就是典型的服务状态没就绪导致的误报。

4. 密码重置技巧：SSO管理员与root密码的运维配合

4.1 SSO管理员密码忘了，先用 vmafd-cli 重置

证书重置过程中，经常会碰到一个更尴尬的问题：root 密码还有，但 SSO 管理员密码想不起来了。尤其是 admin@vsphere.local 这个账号，建完 vCenter 后就很少有人用，等到需要用的时候，密码早就淹没在历史记录里了。

vCenter 的 SSO 域账号由 vmafd（VMware Authentication Framework Daemon）负责管理。在 VCSA shell 里，使用 vmafd-cli 可以修改 SSO 域用户密码：

/usr/lib/vmware-vmafd/bin/vmafd-cli set-password --server localhost --user admin

执行后按提示输入当前密码和新密码。如果当前密码已经彻底遗忘，部分版本允许用 root 权限以域管理员的身份直接重设，命令带 --password 参数：

/usr/lib/vmware-vmafd/bin/vmafd-cli set-password --server localhost --user admin --password '新密码'

需要说明的是，这个操作在不同版本里行为不完全一致，有的版本仍然会要求旧密码。遇到这种情况，最推荐的方式是回到你手头的快照，或者找 VMware 官方支持来协助恢复。因此在密码重置这件事上，我的建议是别等到最后一步才想起密码不存在，给 vCenter 的管理密码也建立一个周期性的验证机制。

除了命令行，vSphere Client 的登录页上如果提示密码过期，输入旧密码后系统会引导你设置新密码，这也是一个很常见的改密路径。还有一个入口是 VAMI 的管理员区域，用 root 登录后可以修改 SSO 域的管理员密码。三条路都走不通的话，就得靠备份和快照兜底了。

4.2 本地 root 密码与 VAMI 的关系

VCSA 的 root 密码，可以理解成设备管理员的密码，只管 vCenter 这台设备本身，不参与 vsphere.local 域身份验证。root 密码的日常修改入口包括：

• VAMI（https:// :5480）里登录 root 后，在管理相关位置可以修改 root 密码
• DCUI（直接控制台界面）按 F2 进入系统配置，也可以修改密码
• 在 VCSA shell 里执行 passwd root 同样可以

重点提醒一下：不要尝试用传统 Linux 单用户模式去重置 VCSA root 密码。VCSA 的底层是 Photon OS 定制版，经过 VMware 深度封装，很多常规的 rescue 流程根本不适用。遇到 root 密码彻底遗忘，只有快照、配置备份、以及联系官方支持这几条正规路子。所以，把 root 密码写进团队共用的密码管理库，比什么都重要。

另外，修改 root 密码后，有些跑在 vCenter 之外的连接工具，比如指向 VCSA 的监控系统、备份代理，可能会因为密码变化而连接失败。改完密码后，顺手检查一遍这些外部集成，不要只盯着 vCenter 本身。

4.3 密码与证书的联动：重置证书时，密码的作用是什么

很多新手会问：为什么重置 VMCA 证书还要输入 SSO 管理员密码？这其实和 vCenter 的认证架构有关。证书本身由 VECS 管理，而 VECS 的读写操作会落到 vmafd 上；为了让新证书能写入 vmafd 的信任存储并用 SSO 重新生成相关资料，工具需要以 SSO 域管理员的身份完成这一步。所以你在执行 certificate-manager certificate renew 时被要求输入的 admin 密码，并不是随意的一个账号，而是必须属于 vsphere.local 域的 SSO 管理员。

明白了这一层，你也能理解为什么证书重置和 SSO 密码重置经常要放到一起处理。如果 SSO 管理员密码已经不知道了，你就必须先解决密码问题，再回到证书流程。这也是我把密码重置技巧放进这篇文章的直接原因——两者在实操中往往互为前置条件。

5. 常见问题与排查技巧实录

5.1 certificate-manager 命令卡住或报错的排查路径

证书重置流程本身不长，但报错花样不少。我处理过的失败案例主要集中在下面几类：

• 时间偏差过大。vCenter 本地时间和真实时间误差几分钟以上，或与浏览器端时间偏差过大，证书校验会立刻失败。修复方式很简单：到 VAMI 里重新设置 NTP 服务器，等待时间同步完成后再执行 cert 操作。
• DNS 解析异常。certificate-manager 在重置证书时，会通过 FQDN 或 IP 做内部校验，如果 /etc/hosts 里 vCenter 本机名解析不对，流程会卡在验证阶段。排查时先确认 vCenter 的 FQDN 能被正确解析。
• 磁盘空间不足。证书备份和新的证书文件都要写盘，如果 VCSA 的 /storage 分区写满，renew 会中途失败。执行前 df -h 看一眼分区用量。
• 交互式会话超时。SSH 会话由于空闲时间长被断开，导致证书写入到了一半。建议直接再跑一次 renew，它本身是幂等的，重复执行不会有额外风险。

碰到任何报错，日志是最好的老师。证书相关的日志主要在：

• /var/log/vmware/vmca/vmca.log
• /var/log/vmware/vmafd/vmafd.log
• /var/log/vmware/vmon/vmon.log

用 tail -f 实时盯日志，配合命令输出定位，基本能把问题范围缩小到具体服务。如果某个服务在重置后没起来，也不要急着反复重启整台设备，先看 vmon 日志里对应的服务启动失败原因，很多时候是指向后续步骤遗留的信任关系没有及时刷新。

5.2 证书错误和 SSL 探测错误的区分

还有一种情况经常被误报成证书过期，需要特别说明。使用 openssl s_client 检查时，如果看到的是 unable to get local issuer certificate，说明本地环境中缺少对端证书链中的根证书，这不一定代表证书过期，而可能是信任链不完整。同理，如果浏览器端看到 NET::ERR_CERT_AUTHORITY_INVALID，也可能是访问者本机缺少对应根证书，比如用了企业内网 CA，却没有把根证书装到客户端。

区分的方法很简单：用 openssl 直接看证书的有效期：

echo | openssl s_client -connect vcenter.example.com:443 2>/dev/null | openssl x509 -noout -dates

如果 notAfter 大于当前时间，那证书本身还没过期，问题出在信任链；如果 notAfter 已经在过去，那才确认是证书到期。不要一看到浏览器报错就认定证书过期，先分清这两类问题，处理方向完全不同。

浏览器提示证书错误时，优先用无痕窗口再试一次。普通窗口可能带着旧证书缓存，无痕窗口能绕过大部分客户端缓存导致的误判，这一步可以帮你省下不少排查时间。

5.3 运维避坑清单速查

最后把实战中踩过、也看过别人踩的坑整理成一张表，方便你处理问题时快速对号入座：

这张表不是标准答案，但基本覆盖了证书修复项目里最常见的决策点。把它和你自己的环境结合起来看，比单纯跑命令更能避免方向性错误。

6. 写在最后：一点经验体会

处理 vCenter 证书过期这套流程，我最大的体会是：证书问题从来不是换张证这么简单。它背后是一整套信任链、服务状态和账号权限的联动。只要有一个环节没照顾到，比如系统时间漂了、SSO 密码找不到、备份密码忘了，整个过程就会从修复变成救援。

所以我现在的习惯是：平时就把时间同步、密码轮换、证书有效期观测这三件事纳入巡检清单。远程用 openssl s_client 定期看一眼证书到期时间，提醒自己下个月有没有到期任务；把 root、SSO、备份密码分开记录，每季度抽查；凡是涉及证书变更都默认先做快照和备份。这些琐碎的小习惯，比任何一次大修都管用。

如果你现在手里正有一台 vCenter 因为证书过期在报警，不要慌，按照文中的步骤走：先确认环境，再做备份，最后用 certificate-manager 的 renew 或 reset 完成重置，再配合 vmafd-cli 把密码问题一并解决，大概率能在半小时内让环境恢复如初。