企业官网建设流程全解析

如果你负责的 vCenter 7.0 突然在浏览器里弹出证书过期告警，你的第一反应多半是打开 vSphere Client，找到证书管理页面点一下“续期”。巧的是，我也这么干过，然后等来的是一个让人血压升高的结果：续期失败，界面上只剩下一行冷冰冰的错误提示。更麻烦的是，有些情况下点完续期之后 vpxd 服务直接起不来，连登录页面都打不开。

这篇内容我会按实际排错的思路来讲，先把 vCenter 7.0 里证书的“全家桶”关系梳理清楚，再说 Web 续期为什么容易翻车，最后给出我实测可用的命令行操作方案。无论你遇到的是浏览器提示 CA 根证书不受信任，还是点续期后服务崩了，这篇文章都值得你从头看到尾，尤其是后面几节的操作步骤，可以当手册用。

1. 续的是哪张证书？先搞懂 vCenter 7.0 的证书全家桶

证书续期报错这件事，大部分人栽在第一步：根本没搞清楚自己到底在续哪张证书。vCenter 7.0 不是一个单证书应用，它内部由一堆组件组成，每个组件都有自己的证书，而这些证书之间又存在信任链关系。想在报错时迅速定位问题，得先把这些证书各自的角色和过期表现记清楚。

1.1 从安装时就注定的证书体系

vCenter 7.0 在部署阶段会初始化一个内部 CA，也就是 VMCA（VMware Certificate Authority）。VMCA 是整个证书体系的根，安装完成后它会自动给 vCenter 自身的各个组件签发证书，也会给接入的 ESXi 主机签发证书。所以正常情况下，vCenter 与 ESXi 主机之间的信任，以及浏览器与 vCenter Web 界面之间的 HTTPS 信任，全部建立在 VMCA 签发的这套证书链上。

VMCA 根证书的有效期很长，通常是 10 年，而 VMCA 给机器签发的叶子证书（也就是 Machine SSL 证书和解决方案用户证书）默认只有 2 年有效期。这就导致一个很常见的现象：根证书还没过期，但机器证书到期了，于是 Web 界面提示证书告警，你去点续期，结果出错。根因往往不是续期流程本身的问题，而是你忽略了证书体系里有好几张证书在同时服役。

1.2 vCenter 7.0 里到底有几张证书

我整理了一张表，把最容易碰到的几张证书列了出来，方便你排查时对照：

很多人以为自己在续 Machine SSL 证书，实际上 Web 界面的证书续期操作往往会把多个证书一起重新生成。问题就出在这里：解决方案用户证书被替换后，如果某些组件没有及时更新信任关系，vpxd 或 STS 服务会处于“不知道信谁”的状态，表现出来就是 Web 操作失败，甚至整个服务崩掉。ESXi 主机那边的证书同理，如果你手动替换过主机证书，vCenter 再重新签发时，主机的信任记录和实际证书对不上，就会报证书状态异常。

1.3 判断当前证书状态的快速命令

在点续期之前，先用命令确认一下当前各证书的实际到期时间，能避免很多无效操作。通过 SSH 登录 vCenter 的 Bash shell 后，查看 Machine SSL 证书有效期：

/usr/lib/vmware-vmca/bin/certool --getcert --cert=/etc/vmware-vpx/ssl/rui.crt | grep -E "Not Before|Not After"

查看 vCenter 证书存储 VECS 里所有证书的情况：

/usr/lib/vmware-vmca/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text | grep -E "Alias|Not Before|Not After"

这两个命令输出里的 Not After 就是到期时间。如果它已经过期，或者距离当前时间不到 30 天，那你确实需要处理。但请注意，处理的方式不一定是在 Web 界面里点续期，具体原因后面详细说。

2. Web 续期报错的三种常见现场与根因定位

我在帮客户处理 vCenter 证书问题时，发现大部分人遇到的报错其实都属于少数的几种典型情况。把现场拆开看，每个报错背后对应的是不同层面的问题，盲目点续期只会加重故障。

2.1 现场 A：点续期之后直接弹出“操作失败”

这类报错最让人烦躁，因为 Web 界面不会告诉你任何细节，就一个笼统的错误。排错时先看两个地方：一是磁盘空间，二是 VMCA 服务状态。

vCenter 证书操作依赖临时文件生成和日志写入，如果根分区快满了，续期操作会在某个中间步骤静默失败。检查方式就是登录 VAMI 的 5480 管理界面，看存储使用率；或者直接 SSH 进 Bash shell 执行df -h，重点看 /storage/log 和 / 这两个分区的余量。我遇到过一次典型的案例，就是日志分区被 vpxd 日志写满，导致证书管理操作失败，清理完日志之后续期一把就过了。

VMCA 服务异常也会导致同样的报错。检查命令：

service-control --status --all | grep vmca

如果 vmca 服务没有处于 running 状态，先尝试启动它：

service-control --start vmca

另外，日志是最重要的线索来源。后续任何证书操作都可以关注两个日志文件：/var/log/vmware/vmca/certificate-manager.log和/var/log/vmware/vpxd/vpxd.log。报错的具体原因，十有八九都写在里面。

2.2 现场 B：浏览器提示“此 CA 根目录证书不受信任”

这个提示很有迷惑性，很多人以为证书过期了，实际上这是信任链的问题，跟续期失败没有直接关系。vCenter 的 Machine SSL 证书由 VMCA 根证书签发，浏览器不认识 VMCA 这个内部 CA，自然不信任它的下级证书。

出现这种情况，先确认你怎么访问 vCenter 的。如果是用 IP 地址访问，证书里的 SAN 字段根本不会包含这个 IP，浏览器的提示就非常正常。正确做法是用 FQDN 访问，比如https://vcenter.example.com/ui，然后把 VMCA 根证书导入客户端机器的“受信任的根证书颁发机构”存储里，这样浏览器就不会再报警告。

如果你看着的是 VAMI 管理界面 5480 端口，同样会有证书告警，因为 VAMI 默认也使用同一套证书链，处理方式和上面一致。总结一句话：这个现场不是续期失败，是客户端不信任 vCenter 的根证书，优先解决信任问题，不要贸然去动服务端证书。

2.3 现场 C：续期到一半中断，vpxd 服务起不来

最棘手的场景是续期过程中断了，然后 vpxd 服务罢工，vSphere Client 直接打不开。这种情况说明之前那次 Web 续期可能已经替换了部分证书条目，但后续的组件重启和信任更新没完成，系统里新旧证书混用，导致 vpxd 校验证书时直接放弃启动。

应急处理分两步。第一步，登录https://vcenter-ip:5480，在 VAMI 的 Services 页面看 vpxd、sts、vmcad 这几个服务的状态。第二步，如果服务是红色的，尝试在 VAMI 里重启，不要先想着重新续期，先把服务恢复到能跑的状态。如果 VAMI 都打不开，那就只能 SSH 进系统，在 Bash shell 里执行：

service-control --restart --all

把所有服务一起重启，让组件重新加载证书信息。若这样还起不来，说明证书库已经混乱，需要走后面第 4 节介绍的证书重置方案。

3. 为什么 Web 点按钮容易翻车，Certificate Manager 反而稳

既然 Web 界面提供了续期按钮，为什么还会出这么多幺蛾子？我在排错过程中总结了几点原因，理解了这些，你就知道该在什么情况下放弃 Web 操作，改用命令行了。

3.1 Web 续期的本质是一个“乐观”的 API 调用

vSphere Client 的证书续期按钮，本质上是调用 vCenter 内部 API 去执行证书替换。这个 API 调用的前提是 vCenter 的各项服务，尤其是 vpxd 和 STS，处于健康运行状态，并且当前登录用户的权限足够高。但问题是，证书过期本身就会导致 STS 服务不可用，vpxd 的启动又依赖 STS 签发的内部令牌。这就形成了一个死循环：证书已经过期导致服务不正常，服务不正常导致 API 调用失败，API 调用失败又无法帮你换证书。

所以我一直强调一个原则：如果证书已经过期，或者服务已经出现异常，不要去 Web 界面点续期，那只会得到一次失败的 API 调用。应该直接上命令行工具，在服务层面完成替换。

3.2 Certificate Manager 不依赖 Web API

vCenter 自带的 certificate-manager 命令行工具运行在本地，直接操作 VECS 证书库和 VMCA 服务，不需要经过 vpxd 的 Web API。也就是说，即使 Web 界面打不开，只要系统还能 SSH 登录，证书就有救。这也是所有 vCenter 管理员必须掌握 Certificate Manager 的原因——它是证书问题最后的救命稻草。

3.3 商业 CA 证书上传时的 SAN 校验更严格

还有一个常见但容易被忽略的失败点：如果你不是让 VMCA 内部签发，而是从商业 CA 申请证书来替换 Machine SSL，Web 界面在上传环节对证书的 SAN（Subject Alternative Name）字段校验非常严格。证书的 SAN 列表必须同时包含 vCenter 的 FQDN、IP、shortname 等，缺一个都会直接报错。而通过 certificate-manager 方式操作时，你可以用配置文件明确指定 SAN 列表，并在生成 CSR 之前就把所有需要的名称写全，容错空间大得多。

我用一个比喻来说明两者差别：Web 续期按钮像是坐高铁检票进站，任何环节不对都过不去；Certificate Manager 像是走人工通道，你可以把问题在通道口当场说清楚，处理起来更灵活。在救火场景下，人工通道永远更可靠。

4. 实操：用 certificate-manager 完成续期与证书重置

下面这部分是真正的干货。我会把 vCenter 7.0 上通过命令行续期和重置证书的完整流程走一遍，并提醒你每一步该注意什么。请务必在维护窗口执行，涉及服务重启的操作会中断业务。

4.1 操作前的准备

首先要开启 vCenter 的 SSH 和 Bash shell。用浏览器打开https://vcenter-ip:5480，登录后依次点击“Access”和“Edit Settings”，把 SSH 登录和 Bash shell 都设为启用。这里的登录账号是 root，如果你不记得 root 密码，先去 VAMI 的“Admin”区域重置密码，这是很多人最终卡住的地方。

然后确认磁盘空间。证书替换过程会生成新密钥和新证书，还会备份旧证书，空间不足会导致所有步骤失败。执行：

df -h

至少保证 / 和 /storage/log 分区有 5GB 以上的剩余空间。

4.2 第一步：备份现有证书

替换前必须备份，这不是建议，是规定动作。证书一旦被覆盖，旧证书不会自动保留，没有备份的话回滚就是天方夜谭。执行：

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

进入交互菜单后会看到一个编号列表。不同 build 的菜单编号略有不同，但一定有一个“备份”选项，通常叫 Backup all certificates，备份文件会生成在当前目录下，名字类似vcenter_2025xxxx.tgz。把备份文件下载到本地或者移到 /root 之外的安全目录存放，然后继续操作。

4.3 第二步：针对“机器证书即将到期”的标准续期

如果你的 VMCA 根证书仍然有效，只是 Machine SSL 证书快到期了，那不需要动整个证书链，只需要替换 Machine SSL 证书。在 certificate-manager 菜单里选择对应的“Replace Machine SSL certificate”选项（在 7.0 中通常是选项 4，具体以菜单标题为准）。

选择后工具会要求你确认 vCenter 的 FQDN 和 IP，并询问是否生成新的私钥。这里我建议全部选择生成新私钥、新证书，不要复用旧私钥。复用旧私钥虽然也能延长有效期，但既然要换就一次换干净，避免后续又出问题。确认之后，工具会读取旧的 Machine SSL 配置，生成新的证书并自动写入 VECS 证书库的 MACHINE_SSL_CERT store。

这个过程中你会看到屏幕上一堆输出，最后大概率会提示替换完成，并询问是否立即重启服务。选是，或者稍后手动重启：

service-control --restart vpxd

重启完成后，新的 Machine SSL 证书已经生效。

4.4 第三步：针对“根证书异常或整套证书链都需要重置”的操作

如果你的 VMCA 根证书本身有问题，或者系统里多个组件证书状态混乱，比如之前现场 C 描述的那种服务起不来的情况，就需要做整套证书链的重置。在 certificate-manager 菜单里选择“Reset VMCA certificates and regenerate all certificates”这个选项（部分 7.0 版本里是选项 7 或 8，务必看菜单位置和说明）。

这个操作会做两件事：重新初始化 VMCA 根证书，然后基于新的根证书重新签发 vCenter 所有组件的证书。代价是 ESXi 主机那边原本对 VMCA 根证书的信任记录全部失效，vCenter 会在后台重新向每台主机推送新的证书。所以在重置完成后，你会看到 ESXi 主机的证书状态短暂地变成“未知”或“不健康”，等后台推送完成并刷新之后才会恢复为正常。

执行命令后同样会有确认环节，它会提示你这是一次影响范围较大的操作，要求输入 vCenter FQDN 确认。确认后耐心等待，日志会打印在/var/log/vmware/vmca/certificate-manager.log里。整个过程耗时可能从几分钟到十几分钟不等，取决于 vCenter 环境的规模。完成后重启所有服务：

service-control --restart --all

4.5 验证新证书确实生效

服务重启完之后，回到 SSH 窗口，再次执行开头的检查命令：

/usr/lib/vmware-vmca/bin/certool --getcert --cert=/etc/vmware-vpx/ssl/rui.crt | grep -E "Not Before|Not After"

确认 Not After 日期已经变成新的到期时间。同时检查 VECS 证书库里的条目：

/usr/lib/vmware-vmca/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text | grep -E "Alias|Not Before|Not After"

注意 MACHINE_SSL_CERT store 里可能有多个别名条目，确认默认条目对应的到期日期已经更新。验证无误后，用浏览器用 FQDN 访问 vSphere Client，正常应该不会再出现证书错误，除非客户端本身没导入新的根证书。

5. 续期成功不等于彻底解决：验证与日常巡检要点

证书替换成功只是第一步，真正的考验在于整个环境的信任关系是否完全恢复。我见过很多管理员换完证书就以为万事大吉，结果第二天发现 ESXi 主机报“证书状态异常”，或者某些集成服务开始失败。这一节把验证清单和巡检思路讲透。

5.1 三个层面的验证一个都不能少

第一层是 Web 访问验证。用浏览器打开https://vcenter-fqdn/ui，点击地址栏的小锁图标，查看证书有效期是否为新日期，证书链是否完整。如果浏览器提示不受信任，你需要把新 VMCA 根证书导出并导入到客户端机器的“受信任的根证书颁发机构”存储中。导出方法：

/usr/lib/vmware-vmca/bin/vecs-cli entry export --store TRUSTED_ROOTS --alias "VMCA" --file /root/vmca.cer --format PEM

把 /root/vmca.cer 下载到本地导入即可，注意是导入到“本地计算机”的根证书存储，不是当前用户存储。

第二层是服务状态验证。在 VAMI 界面或者命令行检查所有服务的健康度：

service-control --status --all | grep -E "vpxd|vmca|sts|vmafd"

这些核心服务都处于 running 状态，才算真正正常。

第三层是主机信任关系验证。在 vSphere Client 的“主机和集群”界面，逐个查看 ESXi 主机的证书状态。正常应该是“正常”或“绿色”状态。如果显示“证书状态异常”，在主机上执行“重新连接”或者通过 vCenter 的“证书”操作重新建立信任关系；如果是之前手动替换过主机证书的，可能需要先把主机证书恢复为 VMCA 签发，再让 vCenter 重新接管。

5.2 巡检建议：别等证书过期再动手

证书问题最大的坑在于它是一个“慢性病”，管理员很容易忽视，直到过期那天才匆忙处理，而那时服务已经半死不活。我的习惯是给所有 vCenter 做定期巡检，重点看三个指标：Machine SSL 证书剩余有效期、VMCA 根证书剩余有效期、ESXi 主机证书状态。

最简单的巡检方式，就是写一个定时任务，每隔一周跑一次证书有效期检查，把剩余天数小于 60 天的证书信息输出。比如用 cron 定时执行：

#!/bin/bash CERT_FILE=/etc/vmware-vpx/ssl/rui.crt END_DATE=$(/usr/lib/vmware-vmca/bin/certool --getcert --cert=$CERT_FILE | grep "Not After" | awk -F"Not After: " '{print $2}') END_EPOCH=$(date -d "$END_DATE" +%s) NOW_EPOCH=$(date +%s) DAYS_LEFT=$(( (END_EPOCH - NOW_EPOCH) / 86400 )) echo "$DAYS_LEFT days left for Machine SSL cert"

把这个脚本放到监控系统里，到期前 30 天就开始告警，你就有充足的时间安排维护窗口，而不是半夜爬起来救火。另外，vCenter 的 root 密码一定要有记录且定期验证，我碰到过的证书排障案例里，有一半以上败在“root 密码找不到了”这一步。密码丢失后虽然可以通过 VAMI 重置，但如果 VAMI 因为证书问题本身不可用，那整个恢复流程就会非常被动。

5.3 顺手分享一个省心的做法

如果你所在的单位有 AD CS 或者其他企业 CA，建议把 vCenter 的证书申请纳入到企业的证书生命周期管理里，通过证书模板自动续期，从源头减少手工操作。如果条件不具备，那就老老实实按本文的流程，在证书到期前用 certificate-manager 手动续期，同时把备份文件归档好。实际上，只要在到期前一个月做好检查和备份，整个替换过程十分钟内就能完成，完全不需要经历 Web 续期报错那种提心吊胆的体验。

我个人的经验是，每次处理完证书问题之后，把操作日期、替换类型、新证书到期时间记录在案，下次巡检时直接对照到期时间表，心里就有底了。运维这一行，最贵的永远是故障发生时的那几个小时，而证书问题恰恰是最能通过提前动手来避免的一类故障。