vSphere证书过期怎么办？VMCA续订与ESXi主机证书更新实战

简介：vSphere环境证书更新与续订是保障虚拟化基础架构安全可靠运行的重要操作。围绕证书管理全流程，这份资料面向vCenter管理员与虚拟化运维人员，系统整理了常用工具与关键注意事项，涵盖系统状态检查、单点登录问题修复、健康诊断、证书导入导出与替换等典型环节，帮助读者在证书即将过期或续订失败时快速定位问题并制定处理方案。资源包共包含一百八十三个文件，YAML与JSON配置类文件占多数，对应不同版本vCenter的证书与部署参数，另有Python脚本用于自动化检查与修复；压缩包整体仅1.29MB，轻量实用。已有五百一十人学习下载，适合需要为vSphere环境建立周期性证书更新规范，或临时应对证书告警的运维工程师参考。资料还提炼了更新前备份与恢复验证、兼容性核对、维护窗口选择、更新后验证、周期性检查和文档记录等十个实践要点，可直接借鉴以降低误操作风险。

1. 问题背景与证书体系认知

1.1 vSphere 证书到底承担什么角色

先说个实际场景。我接手过一套运行了两三年的 vSphere 环境，某天登录 vCenter 时浏览器直接弹出红色警告，提示连接不安全。一开始还以为是访问方式的问题，后来一查，是机器 SSL 证书过期了。当时 vSphere Client 虽然还能打开，但是很多功能已经不正常，比如无法正常注册主机、SDK 调用报证书错误、甚至部分自动化脚本直接失效。这还不是最麻烦的，最麻烦的是 ESXi 主机上的证书也同步过期，导致 vCenter 对主机的管理通信全面告警。

很多运维同行在日常维护里很少主动关注证书，觉得它是“基础设施里的基础设施”，平时不显山不露水，出事就是大事。实际上，vSphere 环境里的证书体系承担的是组件之间互相验证身份的职责，包括 vCenter Server、PSC（Platform Services Controller）、ESXi 主机、vSphere Client 以及各种解决方案用户（如 vpxd、vsphere-ui 等）之间的通讯。这套信任链一旦断了，整个管理面就处于半瘫痪状态。

vSphere 的证书体系在 6.0 之后发生了明显变化。旧版本里每台主机各自为政，证书管理比较散；6.0 开始引入了 VMCA（VMware Certificate Authority）作为内置证书颁发机构，统一为环境里的组件签发证书。VMCA 就像是整个 vSphere 环境里的“身份证办理中心”，所有组件默认信任它签发的证书。这套设计让新部署的环境开箱即用，但也带来一个隐患：VMCA 根证书默认有效期是 10 年，机器证书默认有效期是 2 年左右，ESXi 主机证书默认有效期也是 2 年。很多人部署完就把这事忘了，等到证书到期那几天才开始折腾。

1.2 证书类型与过期影响范围

要理解续订，先搞清楚环境里到底有哪些证书。我按自己的经验把 vSphere 证书分成四类：

• VMCA 根证书：整个信任链的源头，所有机器证书都由它签发或由其签发的中间 CA 签发。根证书过期意味着所有依赖它的下级证书全部失效。
• 机器 SSL 证书：vCenter Server、PSC、ESXi 主机各自持有的身份凭证，用于 HTTPS 通信和组件间认证。
• 解决方案用户证书：vSphere 内部服务账号使用的证书，比如 vpxd、vsphere-ui、vcha 等。这类证书比较隐蔽，很多人漏掉。
• 第三方/企业 CA 签发的证书：有些企业为了合规，会把自己的域 CA 或商业 CA 签发的证书导入 vSphere 环境。这种证书的续订周期完全由企业 CA 策略决定，VMCA 管不着。

每种证书过期后的表现也不一样。机器 SSL 证书过期，最直接的表现是 vSphere Client 网页登录时提示证书无效；ESXi 主机的证书过期，vCenter 在主机摘要页面会持续告警显示证书过期，并且无法对主机执行某些操作，比如进入维护模式或迁移虚拟机；解决方案用户证书过期，往往表现为某些服务启动异常，或者在 vCenter 服务状态页面能看到红色错误。最让人头疼的是 VMCA 根证书过期，这种情况会导致环境里所有由 VMCA 签发的证书同时失效，基本上整个管理面全线告警。

2. 更新前的检查与准备

2.1 如何快速判断证书是否快过期

我在实际工作中总结了一套检查顺序，从图形界面到命令行逐层排查。第一次处理证书问题的同行，建议按照这个顺序来，不要上来就动命令。

先在 vSphere Client 的 vCenter Server 管理页面里查看证书状态。路径是：vCenter Server 管理 → 证书，这里会列出 vCenter 相关的所有证书、签发者、有效期。这个页面最直观，能看到哪些证书状态正常，哪些快过期了。但要注意，这里默认展示的是 vCenter 自身的证书，ESXi 主机的证书不在这里统一展示，要每台主机单独看：选中主机 → 配置 → 系统 → 证书。

如果想精确查看证书的有效期和序列号，命令行更靠谱。在 vCenter Server Appliance（VCSA）上 SSH 登录，使用/usr/lib/vmware-vmafd/bin/vmafd-cli get-server-certificate --server-name localhost --xml可以查看 vmd 服务的证书详情；用vecs-cli store list可以列出 VECS 证书存储里的所有条目。VECS 全称是 vSphere Endpoint Certificate Store，相当于 vSphere 的证书保险柜，所有证书和私钥都存在这里面。查看某个存储里的证书内容，可以用vecs-cli entry list --store MACHINE_SSL_CERT --text这样的命令。

我经常用一条更直接的命令来批量检查证书有效期。在 VCSA 上执行for i in $(vecs-cli store list | grep -v "Store" | awk '{print $2}'); do echo "Store: $i"; vecs-cli entry list --store $i --text | grep -E "Alias|Not After"; done，能把 VECS 所有存储里的证书过期时间一次性列出来。这个命令适合巡检时用，几秒钟就能看出哪些证书快到期了。

ESXi 主机上的证书检查也不难。SSH 登录到 ESXi 主机后，执行/usr/lib/vmware-vmca/bin/certool --getservercert --ssl能看到当前机器证书，执行openssl x509 -in /etc/vmware/ssl/rui.crt -noout -dates可以直接查看该证书的生效和过期时间。rui.crt就是 ESXi 的机器 SSL 证书文件，位于/etc/vmware/ssl/目录下，对应的私钥是rui.key。

2.2 备份与风险评估

在动手续订之前，备份是绝对不能跳过的步骤。证书更新涉及到 vCenter 和所有主机的信任关系，一旦中间出了问题，至少还能恢复到原状。

备份工作分两个层面。第一层是 vCenter 层面的备份，建议做一次 VCSA 的文件级备份或基于 vSphere Data Protection 的完整备份。如果环境里有 VCHA（高可用）配置，先把它停掉，因为证书更新过程中主备节点需要同步，有 VCHA 在可能会干扰操作。第二层是证书本身的备份，VECS 存储里的所有证书和私钥都应该导出留存。在 VCSA 上执行vecs-cli store list查看存储列表后，可以逐个执行vecs-cli entry export --store <store_name> --alias <alias> --file /tmp/backup/<alias>.pem --passin <password>导出。没有导出私钥的话，备份意义会打折，因为不少场景下私钥才是关键。

风险评估方面，有几个点必须提前确认。环境里有没有使用第三方证书？如果有，更新 VMCA 根证书并不会覆盖这些第三方证书，需要单独处理。vCenter 是什么版本？6.0 和 6.5 的证书更新命令略有差异，尤其是 PSC 分离部署的场景要格外小心。ESXi 主机的数量有多少？主机数量多的话，更新完整信任链的时间会比较长，需要规划变更窗口。还有一个容易被忽略的点：vCenter 和 ESXi 主机之间的时间是否同步。证书验证的原理就是比对当前时间和证书的有效期，时间不一致，即使证书本身没问题，也会被判断为过期或无效。

3. 证书续订实操流程

3.1 使用 VMCA 重新签发证书

我以一个实际处理过的 vSphere 6.7 环境为例：vCenter 采用嵌入式 PSC 部署，机器 SSL 证书和所有 ESXi 主机证书都将在 30 天后过期，VMCA 根证书还有两年多有效期。这种场景是最常见的，只需要重新由 VMCA 签发新证书，不需要动根证书。

操作前先 SSH 登录到 VCSA，确认当前的环境信息。执行vami_set_network可以查看 vCenter 的网络配置，确认主机名和 IP 是否正确。主机名解析有问题的话，证书续订会失败，这是一个很隐蔽的坑。我遇到过一例，vCenter 主机名解析指向了旧 IP，执行证书续订后服务起不来，查了半天才发现是 /etc/hosts 里的映射不对。

证书更新使用/usr/lib/vmware-vmca/bin/certool工具。核心思路是生成新的 CSR（证书签名请求），然后交给 VMCA 签发。先创建一个配置文件，定义证书的各个字段：

cat > /tmp/cert_req.cnf <<EOF [req] distinguished_name = dn req_extensions = ext prompt = no [dn] CN = vcenter.example.com O = Example Organization OU = IT Department C = CN ST = Beijing L = Beijing [ext] subjectAltName = DNS:vcenter.example.com,IP:192.168.1.100 EOF

CN 字段必须和 vCenter 的 FQDN 完全一致，SAN 里要包含所有访问 vCenter 的域名和 IP，否则浏览器会报证书名称不匹配。接下来生成私钥和 CSR：

/usr/lib/vmware-vmca/bin/certool --genkey --privkey=/tmp/vcenter.key --pubkey=/tmp/vcenter.pub /usr/lib/vmware-vmca/bin/certool --gencsr --privkey=/tmp/vcenter.key --pubkey=/tmp/vcenter.pub --config=/tmp/cert_req.cnf --output=/tmp/vcenter.csr

然后把 CSR 交给 VMCA 签名：

/usr/lib/vmware-vmca/bin/certool --gencert --csr=/tmp/vcenter.csr --privkey=/tmp/vcenter.key --output=/tmp/vcenter.crt

这里需要特别注意，certool --gencert默认使用 VMCA 根证书签发，生成的证书有效期通常是 2 年。如果想指定有效期，可以用--cert-expires参数。但我不建议在家用场景随意改有效期，保持默认最稳妥。

拿到新生成的证书和私钥后，把它们导入 VECS 的 MACHINE_SSL_CERT 存储：

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CERT --yes /usr/lib/vmware-vmafd/bin/vecs-cli entry create --store MACHINE_SSL_CERT --alias __MACHINE_CERT --cert /tmp/vcenter.crt --key /tmp/vcenter.key

导入完成后重启 vCenter 相关服务让新证书生效。VCSA 上最直接的方式是重启 vpxd 服务：

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

全量重启服务会有一段时间 vCenter 不可用，属于正常的变更窗口。如果只是更新了机器 SSL 证书，只重启 vpxd 和 vsphere-client 也能生效，但为了保险起见，我通常还是全量重启。服务全量启动后，用浏览器访问 vCenter 地址，确认证书已经被新证书替换，再继续下一步。

3.2 更新 ESXi 主机信任链

ESXi 主机的证书更新分两种情况。第一种是主机上的 VMCA 签发的证书过期，第二种是 VMCA 根证书发生更换，导致主机不再信任 vCenter。这里只讨论第一种情况，因为更常见。

在 vSphere Client 中操作比较直观：选中一台 ESXi 主机，进入“配置 → 系统 → 证书”，点击“续订”。系统会提示将由 VMCA 重新签发证书，确认后会自动完成。这种方式适合主机数量少的环境。

主机数量多的时候，我推荐用命令行批量处理。在 ESXi 主机上执行如下命令，可以让主机向 vCenter 发起证书续订请求：

/usr/lib/vmware-vmca/bin/certool --selfsign --outcert=/etc/vmware/ssl/rui.crt --outkey=/etc/vmware/ssl/rui.key --config=/etc/vmware/ssl/cert.cnf

但注意，--selfsign是生成自签名证书，并不是由 VMCA 签发的。如果 vCenter 的证书信任模式是“VMCA 签名”，自签名证书会导致 vCenter 无法验证主机身份。正确的做法是在 vCenter 侧为每台主机续订证书。用 SSH 登录 vCenter，执行下面的命令为指定主机重新签发：

/usr/lib/vmware-vmca/bin/certool --gencert --hostname=esxi01.example.com --output=/tmp/esxi01.crt

签完后通过 vSphere API 或 vSphere Client 将新证书应用到主机上。实际上，vCenter 的证书管理功能里有一个“续订”按钮，会自动完成签发和应用的过程。批量操作时能省很多事。

不管用哪种方式，主机证书更新后都需要在 vCenter 里刷新主机的证书信息。在主机摘要页面点击“刷新”按钮，或者在主机“配置 → 系统 → 证书”页面查看状态，确认不再是红色告警。

ESXi 主机证书更新完成后，主机的管理网络可能会短暂中断几秒钟，因为证书变更会触发服务重载。变更窗口内如果有虚拟机正在做 vMotion 或备份任务，可能会受到影响。我建议提前通知业务方，或者先暂停相关的迁移任务。

3.3 验证更新结果

证书更新完，验证环节不能省。以前曾遇到过证书都换完了，但 vCenter 界面仍然提示证书无效的情况，原因是某个服务没有重新加载证书。

验证分三个层面。第一层是浏览器层面，用无痕窗口访问https://vcenter_fqdn/ui，点击地址栏的小锁图标，确认证书的颁发者、有效期和名称匹配。第二层是 vCenter 自身层面，登录 vSphere Client，进入 vCenter Server 管理 → 证书，查看所有证书的状态，确认没有红色警告条目，有效期已刷新。第三层是命令行层面，在 VCSA 上执行vecs-cli entry list --store MACHINE_SSL_CERT --text，确认新证书的生效时间和过期时间都是预期值。

ESXi 主机的验证相对简单，在 vSphere Client 的“证书”页面里点击“验证”，系统会向主机发起 TLS 握手并校验证书链。如果主机证书已经重新签发，验证结果应该是绿色对勾。

4. 典型错误与排坑经验

4.1 时间不同步导致的续订失败

这个坑我踩过不止一次。某次给一套测试环境更新证书，怎么执行都是报错，提示证书尚未生效或者已经过期。后来查了 vCenter 和 ESXi 的系统时间，发现差了将近 15 分钟。ESXi 主机的 NTP 配置失效了，vCenter 的时钟也跑偏了。证书验证的机制本质上就是拿当前时间和证书有效期做比对，时间不对，结论永远不可能是“有效”。

建议在更新证书前，先统一检查 vCenter 和所有 ESXi 主机的 NTP 配置。在 VCSA 上执行timedatectl status确认时间同步状态，在 ESXi 主机上执行esxcli system time get查看当前时间，或者直接去“管理 → 系统 → 时间和日期”里确认 NTP 服务是否正常运行。如果 NTP 有问题，先在主机上重新配置并同步时间，等所有组件时间偏差在 1 分钟以内，再执行证书续订。

如果环境不允许使用公共 NTP 服务器，那就确保 vCenter 和所有 ESXi 都指向同一个内部 NTP 服务器。这个环节做得不到位，后续排查证书问题很容易绕远路。

4.2 服务未重启导致的报警残留

证书文件已经替换成新的，但 vCenter 界面还是报证书过期或无效。这是新手最容易困惑的地方。原因很简单：vCenter 的很多服务（vpxd、vsphere-ui、vcha 等）是常驻进程，启动时加载一次证书，运行期间不会自动重新读取证书文件。证书换了，服务还在用内存里的旧证书。

正确做法是更新证书后显式重启相关服务。在 VCSA 上可以用service-control --restart vpxd单独重启 vpxd 服务，或者用service-control --restart --all重启所有服务。我倾向于全量重启，因为解决方案用户证书、vsphere-ui 服务、vcha 服务等都可能和证书加载有关，只重启一个服务，界面刷新后可能其他位置还会冒出新告警。

重启服务会带来一段管理面中断时间，这是正常的。提前通知好业务方，该停的自动化任务先停掉，不要在变更窗口里跑计划任务。

4.3 企业 CA 签发的证书续订特殊情况

如果 vSphere 环境用的是企业 AD 域内 CA 签发的证书，情况会复杂一些。VMCA 自动续订只对 VMCA 签发的证书有效，对第三方 CA 签发的证书，需要手动生成 CSR、提交给企业 CA 签名，再把签好的证书导入 VECS。关键是不能把企业 CA 签发的证书和 VMCA 签发的证书混在同一个存储里，否则 vCenter 在验证证书链时可能分不清该信任谁。

具体操作时，先在 VCSA 上生成 CSR：

/usr/lib/vmware-vmca/bin/certool --gencsr --privkey=/tmp/machine.key --config=/tmp/cert_req.cnf --output=/tmp/machine.csr

然后将 CSR 提交给企业 CA 签名。拿回签好的证书后，把根 CA 证书和中间 CA 证书一并导入 VECS。导入顺序有讲究：先导入 CA 根证书到 TRUSTED_ROOTS 存储，再导入机器证书到 MACHINE_SSL_CERT 存储。顺序反了，证书链验证时找不到信任锚点，同样会报错。

导入命令参考如下：

/usr/lib/vmware-vmafd/bin/vecs-cli entry create --store TRUSTED_ROOTS --alias "Enterprise Root CA" --cert /tmp/root_ca.crt /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CERT --yes /usr/lib/vmware-vmafd/bin/vecs-cli entry create --store MACHINE_SSL_CERT --alias __MACHINE_CERT --cert /tmp/machine.crt --key /tmp/machine.key

还要检查企业 CA 证书是否在 ESXi 主机的受信任根列表里。如果没有，需要手动将根证书添加到每台 ESXi 主机。在 vSphere Client 的主机“证书”页面里，有个“添加受信任根证书”的功能，或者用esxcli vsphere cert命令批量添加。企业 CA 场景下的证书更新，步骤比较多，要留出足够的时间。

5. 证书更新常见问题速查

6. 几点个人心得

证书更新这件事，说难不难，说简单也不简单。我处理过好几套环境之后，最大的感受是：平时巡检比出事再修重要得多。每季度顺手看一下 vCenter 和几台核心主机的证书有效期，花不了几分钟，能省掉后续一整天的加班。

另一个心得是尽量让环境里的证书保持统一管理。能用 VMCA 签发的就不要混用第三方证书，能自动续订的就不要手动替换。vSphere 7.0 之后内置证书续订策略和告警机制更加完善，只要在部署时注意规划好证书命名规范和时间同步策略，日常维护会轻松很多。

最后，每次证书变更结束后，记得把新的证书文件、操作命令和验证结果整理成文档存档。换一次环境、隔个半年，再回来看自己的操作记录，你会感谢当时的自己。

本文还有配套的精品资源，点击获取