企业官网建设流程全解析

凌晨两点，手机连续震动，运维群里炸了锅：vCenter Web Client 打不开，业务部门反馈虚拟机调度已停摆，外网监控平台也同步发了“vCenter 证书剩余有效期 0 天”的告警。打开浏览器试了一次，页面直接红屏显示证书错误；用 vSphere Client 登录，卡在“无法建立安全连接”；后台 SSH 还能进，但 vpxd 服务一直在反复重启。这种场景，凡是搞过 VMware 虚拟化的人，早晚都会碰到一次——vCenter 证书过期。

先说个结论：遇到证书过期，绝大多数情况下根本不需要重装 vCenter，也不用去改系统时间糊弄，用 VMware 自带的 certificate-manager 工具就能把整套证书重新签回来。这篇文章我会把“证书还能救”和“证书彻底废了”两种场景都讲透，也会把证书推进过程里最容易忽略的 SSO 密码过期问题一起解决。文章写给刚从“证书到期不知所措”状态里走出来的新手，以及想把这套流程固化成标准操作的老运维。

1. 证书过期不是简单“点掉警告”的事：先搞懂 vCenter 的证书体系在保护什么

1.1 一次证书过期引发的全线故障

很多人觉得“证书警告嘛，浏览器里点一下继续访问不就行了”，但 vCenter 这种企业级管理平台远没有那么简单。vCenter 自己的 Web Client、VAMI（5480 端口管理界面）、ESXi Agent、SDK 接口之间，全部依赖 TLS 双向认证来建立信任关系。一旦证书过期，麻烦是一连串的：

• vSphere Web Client 直接拒绝加载，页面上只有一个大红的“证书无效”。
• VAMI 界面登录后，证书管理区块显示“已过期”状态，部分版本连登录都进不去。
• vpxd（vCenter 的核心管理服务）启动后由于 TLS 握手失败不断退出，表现为服务反复重启。
• 底层 ESXi 主机虽然本身还在跑虚拟机，但和 vCenter 之间的心跳断开，管理面彻底失联。
• 任何基于 vCenter API 的自动化、备份、云管平台，全部开始报证书验证失败。

我在 SSH 到后台翻日志时看到，/var/log/vmware/vpxd/vpxd.log里刷满了certificate verify failed和 TLS 握手失败记录。原因不是 vpxd 的程序坏了，而是它找不到一条可信任的证书链来证明“我就是我”。

1.2 vCenter 内部到底有几套证书在各自生效

cer 这个问题之所以复杂，是因为 vCenter 不是只有一张证书。我整理了一个简化版清单：

在这套体系里，VMCA 相当于一个内部“发证机关”。它给机器签 Machine SSL 证书，给各服务账号签 Solution User 证书。只要 VMCA Root 还在有效期内，证书体系就没有彻底坏死，用 certificate-manager 重新签发下游证书就能恢复。但如果是 VMCA Root 本身过期了，问题就要升级到“强制重签”的层面。

1.3 哪些临时手段能用，哪些是深坑

网上有一些所谓的“应急方案”，很多是不靠谱的。我建议你记住这几点：

• 浏览器“继续前往”只能让管理员手动用一下，API、SDK、vSphere Client、第三方平台全都会拒绝连接，所以这不是修复方案，只是临时查看手段。
• 改系统时间是最坑的操作。把时间强行调回证书有效期，表面看着不红了，但一来 vCenter 内部组件的日志时间轴全乱，二来域认证、时间同步服务全部跟着出问题，后续排查难度成倍增加。
• 反复重启 vpxd 是没用的。证书过期是信任链层面的问题，不是服务状态问题，你重启一百次也改变不了证书已失效的事实。

正确思路只有一条：用官方工具把这套证书重新生成、替换、重新建立信任链。接下来我就讲 certificate-manager 这个工具怎么用。

2. 动手之前先摸清家底：certificate-manager 工具定位与自检清单

2.1 certificate-manager 到底是干什么的

certificate-manager 是 VMware 在 vCenter Server Appliance（VCSA）里内置的命令行工具，路径通常在/usr/lib/vmware-vmca/bin/certificate-manager。它本质上是对底层 VMCA、VECS（vSphere Endpoint Certificate Store）和多个服务配置的一层封装脚本。

它的核心能力有四个：

1. 查看当前证书状态，列出现有证书的指纹、有效期、存储位置。
2. 重新生成证书，就是用 VMCA Root 重新签发一套新的内部证书，替换掉旧的。
3. 替换为自定义证书，比如公司 CA 或商业 CA 签发的证书，实现对外证书合规。
4. 强制恢复，在证书链彻底损坏或过期时，绕过部分校验把整套证书拉回可用状态。

有了这个工具，你不需要手工去改每个服务的证书配置，也不用去碰底层的 VECS 存储。它会自动完成“生成新证书 → 写入 VECS → 分发到各服务 → 触发服务重载”这条链路。它就像一个内部“证书管家”，把最容易出错的手工环节全部自动化了。

2.2 登录与菜单切换的基本操作

操作 certificate-manager 前，你需要先 SSH 登录到 vCenter Appliance。默认情况下，登录后进入的是 appliance shell（命令行提示符类似Command>），输入shell并回车，再输入root的密码，才真正进入 BASH shell。然后执行：

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

工具运行后会出现一个交互式菜单，常见选项大致是：

• Option 1: Replace Machine SSL certificate with Custom Certificate
• Option 2: Replace VMCA Root certificate with Custom Signing Certificate
• Option 3: Replace Solution User Certificates
• Option 4: Regenerate all certificates（有些版本叫 Reset expired certificates）
• Option 5: Replace STS Signing certificate
• Option 6: Regenerate Missing VMCA Certificates

菜单项在不同版本（6.5、6.7、7.0、8.0）里略有差异，但核心逻辑是一样的。你不需要记住全部选项，关键在于能判断哪个菜单适合当前场景。

2.3 动手前必须完成的三项检查

在实际执行任何修复动作之前，我强烈建议你先完成下面三个检查，避免修到一半发现“密码忘了一个”“备份没做”之类的尴尬情况。

第一，确认 SSO 密码可用。证书重签过程中，工具会反复要求输入administrator@vsphere.local的密码，这个密码就是 vCenter SSO 域管理员密码。如果你不确定它还能不能用，先想办法确认；如果密码已过期，就按第 5 章的流程先把它重置了再继续。

第二，定位当前过期的证书范围。用下面的命令快速查看关键证书的到期时间：

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

这个文件是 vpxd 使用的 Machine SSL 证书。如果输出显示notAfter=...已经不合法，那基本可以确认证书过期。想看所有证书存储，可以用：

/usr/lib/vmware-vmafd/bin/vecs-cli store list /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text

第三，备份当前证书配置目录。在 vCenter 里执行：

cp -a /etc/vmware-vpx/ssl /root/ssl-backup-$(date +%F)

备份这一步虽然不能百分之百保证“还原现场”，但至少能让你在出现问题时有原始材料可查。另外，如果环境里有多个节点（比如外部 PSC + vCenter 的架构），还要先记录各节点的角色和操作顺序。虽然 vCenter 7 之后大多是嵌入式架构，但如果你还在维护 6.7 时代的外部 PSC 环境，顺序错了会连不上。

3. 证书还能救的普通场景：直接用 regen 重新签发

3.1 先判断“还能救”的边界

不是所有证书过期都到了“全套推倒重来”的程度。certificate-manager 的普通重新生成流程，适用于下面这种情况：

• SSH 还能登录，系统本身没有报“证书验证失败导致工具无法运行”的错误。
• vpxd 虽然起不来或反复重启，但 SSO 服务（vmdird、vmafd）还活着。
• VMCA Root 证书本身没有过期，或者只过期了下游的部分证书。

简单说，只要这个工具还能启动并正常读取现有证书信息，那就属于“还能救”的范畴。这时候不需要强制模式，用普通选项就能把整套证书刷新一遍。

3.2 操作步骤：是全部重签还是只签过期的

运行 certificate-manager 后，在菜单里选择对应“Regenerate all certificates”的选项。有些版本里，它会进一步问你：是“重新生成所有证书”还是“只重新生成过期证书”。我的建议是：

• 如果只有 Machine SSL 证书或某个 Solution User 证书过期，优先选择只重签过期的部分，影响面更小。
• 如果有多张证书都显示异常，或者你不确定哪些证书已经坏了，直接选择全部重签，省得签完这张又报下一张。

选择完后，工具会要求输入 SSO 密码。然后开始自动重签流程。整个过程中，你会看到它在生成 key、写 VECS、同步 Solution User 证书等操作。正常情况下，几分钟到十几分钟后就会出现类似Completed successfully的提示，然后回到 shell 提示符。

等待期间，不要中断 SSH 连接，也不要手动重启其他服务。工具在跑证书同步时如果被强行打断，遗留的中间状态反而更麻烦。

3.3 操作完成后，为什么我依然建议重启一次 vCenter

证书重签完成后，虽然工具内部已经尝试让各服务加载新证书，但很多后台服务（vpxd、vsphere-ui、vmonapi 等）对于证书变更的响应并不及时。尤其是一些常驻进程，可能还持有旧的证书信息。

所以在工具提示完成后，我会再执行一次干净的重启：

reboot

vCenter 重启一般需要 10 到 15 分钟。等它起来以后，再用 VAMI 或 CLI 去验证证书状态。这一步不算多余，它能让所有服务以全新的证书链初始化，避免“证书明明换了，服务还是报错”的假象。

3.4 一个常见问题：为什么不用手动生成 CSR 替换

有朋友问：“我用自己的内部 CA 签一张多省事，为什么还要用 VMCA 重签？”答案是：手动替换自定义证书的路，比想象中要宽但坑也更深。VMware 允许你把 Machine SSL 证书替换成自己 CA 签发的证书，但前提是你要同时处理好整个信任链：

• 自定义证书必须包含完整的中间证书链；
• VMCA Root 必须信任你的自定义 CA（或你把它导入到对应信任库）；
• 如果你替换了 VMCA Root，整套 Solution User 证书也需要跟着重新签发，这一步经常被漏掉，漏掉的结果就是模块间互相不认证。

所以，如果你的主要诉求是“把过期证书救回来，让平台恢复正常”，而不是“对外证书合规审查”，那最简单、最安全的方式就是让 certificate-manager 用 VMCA 重新生成整套证书。等平台稳定了，再慢慢规划自定义证书的合规替换也不迟。

4. 证书全面过期时的强制通道：force-regenerate 与环境恢复

4.1 什么时候必须走强制通道

我遇到过一种更棘手的情况：VMCA Root 证书本身已经过期，或者整个证书链损坏到连 certificate-manager 自身都无法通过校验。表现就是，运行工具时直接报错：

Exception in certificate verification: certificate has expired Error: Please verify that the certificate is valid and try again

看到这类报错，普通重签流程走不下去，因为工具在启动时就校验了现有证书链，链上过期证书直接堵住了入口。这时候需要强制模式。

需要说明的是，“强制模式”是 VMware 官方为这类场景准备的手段，不是什么民间 hack。它的作用就是绕过工具启动时的证书链校验，强制把整套证书重新生成一遍。

4.2 强制重签的两个关键动作

强制重签的操作，关键在于设置一个环境变量再启动工具：

export VMWARE_CERT_MANAGER_ALLOW_FORCE=1

然后重新运行：

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

这时菜单里会出现一个带force的选项，选项名称类似Force Regenerate all certificates。选择后，流程和普通重签一样：输入 SSO 密码，等待工具重新生成整套证书链。

这里想强调一点：强制模式虽然能绕开校验，但它不会帮你处理“SSO 密码不可用”的情况。如果你在过程中发现自己连administrator@vsphere.local的密码都不知道，那就得先走第 5 章的密码重置方案，把 SSO 密码拿回来再继续。先重置密码，再回来强制重签，这是比较顺畅的顺序。

4.3 强制重签后的“服务水位”检查

强制重签完成后，可比普通重签多留一个心眼。因为强制模式往往意味着系统已经处于相对恶劣的状态，可能有一段时间没有正常服务了，所以重签结束后建议先检查服务状态：

service-control --status --all

重点看这几个服务的状态：

• vpxd
• vsphere-ui
• vmonapi
• vmdird
• sts

如果 vpxd 仍不在 RUNNING 状态，第一时间去看/var/log/vmware/vpxd/vpxd.log，里面如果有 TLS 或证书相关报错，说明可能还有组件没有加载到新证书，再用service-control --restart --service vmware-vpxd重启一次 vpxd。如果日志里是数据库或其他业务层面报错，那就是另一个方向的问题了，需要单独排查。

5. 密码过期时的第二条自救通道：vCenter SSO 密码重置技巧

5.1 分清是 root 密码过期还是 SSO 密码过期

证书过期这件事，经常和另一个运维痛点同时出现：密码过期。很多环境的 vCenter 密码策略默认设了一段时间自动过期，于是你会在同一时间遇到“证书过期”和“密码过期”的双重打击。但这两类问题的处理方法完全不同。

在证书重签、VAMI 登录这些场景里，卡住你的通常是 SSO 密码。所以下面重点说这个。

5.2 使用 vdcadmintool 重置 admin@vsphere.local 密码

vdcadmintool 是 vCenter 内部维护 vmdir（VMware Directory Service）账户的工具，位置在：

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

操作步骤：

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

菜单里选择Set account password（不同版本选项号可能不同），然后输入账户的 UPN，比如：

administrator@vsphere.local

接下来输入两次新密码。需要注意，vmdir 对密码复杂度的校验是比较严格的，通常要求至少 8 位，并且包含大写字母、小写字母、数字和特殊字符。如果设置得太简单，工具会直接拒绝。

设置成功后，重启相关的身份服务，让新密码在内部同步生效：

service-control --restart --service vmdird service-control --restart --service vmafd service-control --restart --service sts

之后再去 Web Client 登录，一般就能通过了。

5.3 重置密码后，还有几个“隐藏位置”要记得同步

SSO 密码重置完成后，很多运维会忽略一个问题：对外集成平台的凭据已经旧了。如果你在 vCenter 上配置了 vRO、vRA、VMware Aria Automation、备份代理、监控告警插件，这些平台的 SSO 账号密码还是老的，会在接下来几天里接二连三地报“认证失败”。

这类集成凭据没法用命令一键全部更新，只能一个个到对应平台的控制台里重新输入新的 SSO 密码。虽然繁琐，但总比事后被连环告警追着跑要好。另一个隐藏位置是 VAMI 里的备份任务配置，如果备份任务用的是 SSO 账户，密码重置后也要重新验证一次，否则定时备份可能默默失败。

5.4 一个容易踩的坑：vdcadmintool 连不上数据库

我在实际执行中遇到过几次 vdcadmintool 报 LDAP 连接失败或无法打开 vmdir 数据库的情况。这通常是因为 vmdir 服务不在运行状态。遇到这种状况，不要慌，先启动 vmdir，再重新跑工具：

service-control --start --service vmdird /usr/lib/vmware-vmdir/bin/vdcadmintool

如果 vmdir 一直启动失败，那问题就不只是密码过期了，可能还叠加了证书层面的信任问题。这种情况建议先回到第 4 章的强制重签流程，把证书链拉通，再回过来处理密码。

6. 修完不等于完事：三层验证、日常巡检与几个真实踩坑记录

6.1 三层验证一看就会

证书修复和密码重置都做完后，别急着宣布收工。我习惯用三层验证来确认系统真的恢复正常了。

第一层，浏览器访问。打开https://<vcenter-ip/，点击地址栏的锁形图标，查看证书有效期是否已经刷新到当前日期之后。同时登录 Web Client 确认能正常进入。

第二层，命令行验证。用 openssl 直接对 443 端口做一次 TLS 握手，取出服务器证书的过期时间：

echo | openssl s_client -connect <vcenter-ip>:443 -servername <vcenter-ip> 2>/dev/null | openssl x509 -noout -enddate

这条命令在 Linux 机器上就能执行。如果输出里的notAfter已经是未来日期，说明 Machine SSL 证书已经生效。

第三层，VAMI 验证。访问https://<vcenter-ip>:5480，在证书管理和健康区域查看整体证书状态，确认没有红色告警。

这三层都过了，修复才算真正闭环。

6.2 给证书建一份“到期日历”

证书过期这种问题，最大的特点就是可预见。它不像磁盘故障那样来得突然，而是有一个明确的到期日期。所以最好的处理方式，是建立主动监控，而不是等别人发现平台挂了再来救火。

建议至少做到：

• 用外部监控平台周期性探测https://<vcenter-ip>:443的证书剩余天数，提前 30 天告警。
• 在运维日历上，把 vCenter 证书“主动续签”设为每两年一次的例行事项，不要等时间恰好卡在节点上。
• vCenter 自身的 VAMI 页面也有证书到期信息，偶尔登录看看，别把它当成“平时不用看”的页面。

如果你已经经历过一次生产事故，就会明白，提前 30 天收到一封“证书将于 30 天后过期”的邮件，和凌晨两点被监控电话叫醒，感受是完全两回事。

6.3 三个真实踩坑记录，写在最后

第一个坑：证书过期第一天，我差点选择重装 vCenter。当时觉得系统已经不可用，不如直接重建省事。但后来在 VMware 官方 KB 里找到 certificate-manager 的强制重签方案，几分钟就恢复了。所以你第一反应不应该是重装，而是评估当前系统盘、数据库和服务状态是否完好。只要能 SSH、日志里没有硬件或数据库故障，优先尝试证书重签。

第二个坑：只重签 Machine SSL 证书，没处理 Solution User 证书。我早期有一次只替换了对外证书，结果 vpxd 和 vsphere-ui 之间还是互相不认，日志里刷满了 401 和 403 错误。后来才意识到，Solution User 证书是每个内部服务用来证明身份的“工牌”，你只给大门换了锁，员工手里的卡还是旧的，照样进不去。所以重签时要么选择全部重签，要么就按工具提示把涉及到的证书类型一次都换了。

第三个坑：证书修完后忘了同步外部平台凭据。那次折腾完 vCenter，第二天业务反馈备份平台连接到 vCenter 失败，一查是备份代理还在用旧证书握手。这个问题严格来说不是证书修复本身的问题，而是“证书信任变更”波及了所有关联系统。教训就是：修证书前先梳理一下哪些平台在跟 vCenter 做 TLS 对接，修复后主动去更新它们的信任配置。

最后再提醒一句：处理完证书后，第一件事就是去监控平台更新 SSL 探活任务的预期证书指纹，别让它继续用老证书去探测然后一直报错。证书修复这套流程，说到底就是让 vCenter 自己重新信任自己一次，动手前多做备份、多记信息、分清优先级，真出问题了也总能退回来。