企业官网建设流程全解析

简介：面向VMware管理员与虚拟化运维人员的vSphere证书更新/续订工具与案例资源包。内容围绕vCenter证书管理，汇总了checksys.py、fixsts.sh、lsdoctor与vCertTool四类工具的用途与操作要点，附有证书到期检查、SSO故障修正、健康诊断及证书导入导出替换等常见场景说明，可帮助读者规避更新前的配置隐患和兼容性问题。包内共183个文件，以yaml和json配置清单、py脚本为主，其中约96个yaml与56个json对应不同vCenter版本/补丁的环境配置数据，便于按版本对照；29个py脚本则覆盖检查与辅助操作，整体压缩包仅1.29MB，文件结构清晰，适合快速下载与直接参考。已有510人学习下载。对于需要规划证书维护窗口、准备备份、更新后验证以及建立周期性续订计划的团队，这份资料能提供可落地的检查清单和注意事项，减少因证书过期导致的SSO中断与服务异常风险。 先说一个我自己的真实经历。某个周五下午，监控平台连续报警，打开一看是vCenter的Machine SSL证书还有不到20天就到期。我当时没当回事，想着下周一找个空闲窗口再更新。结果周六上午，同事发来消息说vSphere Client登不进去了，浏览器访问vCenter提示证书不可信，整个管理面瘫痪。那次之后我才意识到，vSphere环境里的证书更新/续订这件事，看着不起眼，一旦错过时间窗口或者操作顺序不对，轻则服务中断，重则整个虚拟化平台需要恢复快照才能救回来。

这篇文章就围绕vSphere环境里最常见的证书更新/续订场景展开，包含vCenter Server Appliance（VCSA）上的VMCA证书续订、ESXi主机证书重新生成，以及我自己在实战中总结出来的各种注意事项。不管你环境是6.x还是7.x，只要还是VMware这套体系，核心思路和命令基本都能直接套用。

1. 先搞明白vSphere里的证书都藏在哪，哪些会到期

vSphere的证书体系初看很绕，VCSA内部通过VECS（vSphere Endpoint Certificate Service）统一管理所有组件的证书和密钥。但从运维视角，不需要把VECS所有细节都扒一遍，只需要盯住几类证书就好。

1.1 VMCA、Machine SSL、Solution User、ESXi主机证书，一张表说清

其中Machine SSL和Solution User证书是最容易触发告警的，因为默认只有两年有效期。VMCA根证书时间很长，很多环境里还没有人见过它到期，但一旦到了就是“全军覆没”。ESXi主机证书在独立部署时是自签名的，被vCenter纳管后会由VMCA重新签发，它过期的最直接后果就是vCenter和ESXi之间失联，主机状态变成“已断开”。

1.2 证书过期后的连锁故障是什么样

证书过期不是“单个服务不可用”那么简单。vCenter内部有大量的服务间通信，vpxd要调用sts做认证，vsphere-ui要访问vpxd拿数据，这些调用全部建立在TLS之上。Machine SSL证书一过期，vSphere Client首先打不开；Solution User证书一过期，后台各个服务之间就开始互相不信任，表现往往就是“服务看着全在运行，但界面就是进不去，或者登录后一直转圈”。

ESXi这边的连锁反应更直接：hostd这个管理服务的证书一旦失效，vCenter连不上主机，Web Client也打不开主机的管理界面。如果主机上还跑了生产虚拟机，紧急情况下想通过vSphere Client做操作，会发现根本连不上，只能绕过管理面从控制台处理。所以证书问题不是“虚拟化平台的颜值问题”，而是实打实的可用性问题。

1.3 如何提前发现证书危机

我平时检查证书基本靠三个入口，都很简单，一条条说给你。

第一个入口是VAMI管理界面。浏览器访问https://vCenter-FQDN:5480，用root登录后，在“证书”菜单里可以看到各store的证书状态和过期时间。这个界面很直观，适合快速巡检。

第二个入口是vSphere Client。登录vCenter后，在“主机和集群”视图中选中一台ESXi，进入“配置”-“安全配置文件”-“证书”，能看到该主机的证书状态。vCenter自身证书的有效期，通常在系统配置的相关位置也能看到。

第三个入口是命令行，适用于想确认更多细节的场景。SSH登录VCSA后执行：

/usr/lib/vmware-vmca/bin/vecs-cli entry list --store machine --text | grep -A 1 "Not After"

这条命令会把machine store里的所有证书过期时间都打出来，几十秒就能判断整套环境是否安全。

2. 续订前的准备：这是整套操作里最容易被省略的一步

证书更新本质是一次变更操作，绝对不建议“上来就动手”。我见过太多人因为跳过准备步骤，最后把vCenter弄得起不来。

2.1 快照备份怎么做才靠谱

VCSA的快照，严格按照VMware的建议，是先把vCenter所有服务停掉，拍完快照再启动服务。操作为：VAMI的“服务”页面里点“停止”，确认所有服务都已停止后，在虚拟化平台中对VCSA这台虚拟机拍快照，拍完再回到VAMI点“启动”。

很多环境因为业务窗口不允许停服太久，会选择运行时直接拍快照。这样做的风险是快照恢复时可能出现数据不一致，尤其是vCenter自身的数据库（VCDB）在拍摄快照时有未落盘的事务。如果确实没办法停服，至少要在业务低峰期操作，并且确保vCenter数据库做了一次在线备份。

除了虚拟机快照，certificate-manager自己也支持备份证书库。VCSA上执行：

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

工具会导出所有证书、密钥和配置文件到备份目录。这个备份文件和快照不是二选一的关系，我的习惯是两个都做。毕竟快照恢复最干净利落，而certificate-manager自己的备份恢复在某些版本上存在兼容性问题，只靠它心里不踏实。

2.2 FQDN、NTP、DNS、浏览器缓存，齐全才能动手

证书和主机名、IP是绑定在一起的。更新证书前必须确认环境里所有访问入口都使用vCenter的FQDN，而不是IP，也不是短主机名。如果平时习惯了用IP访问，证书更新后大概率会继续弹证书警告，因为新证书（尤其是外部CA签发的证书）里通常只包含FQDN。

NTP时钟同步是另一个容易翻车的地方。证书的有效期判断依赖系统时间，VCSA和ESXi之间如果时间偏差过大，新证书刚生成出来就可能被判定为“尚未生效”或“已过期”。所以更新证书前，我一般会顺手确认所有宿主机和vCenter的NTP状态正常，时间偏差控制在30秒以内。

浏览器缓存这个坑藏得更深。证书更新完成后，浏览器如果还缓存着旧证书的会话状态，打开vSphere Client一样会显示证书错误。遇到这种情况先开一个无痕窗口测一下，能登录就是浏览器缓存问题，不需要怀疑证书没更新好。

2.3 判断你的是VMCA自签还是外部CA签发

下一步是要搞清楚当前环境里证书的签发方式，这决定了后面走哪条路。

最简单的判断方法：在vSphere Client里看证书信息。如果签发者是VMCA，说明走VMCA体系的续订流程就行；如果签发者是AD CS或者其他商业CA，那就不能依赖一键续订，需要重新走CSR申请和导入流程。

命令行也可以确认：

/usr/lib/vmware-vmca/bin/vecs-cli entry list --store machine --text | grep -A 1 "Subject:"

查看Subject和Issuer字段，能一清二楚地看到哪些证书是VMCA签发的，哪些是外部CA签发的。这一步不用花太多时间，但能避免在后续步骤里用错方案。

3. 案例一：vCenter 6.7全套证书续订实操记录

直接上案例。我处理的一套环境是VCSA 6.7 Update 3，管理着8台ESXi 6.7主机，所有证书都是VMCA默认签发的。监控告警显示Machine SSL证书还有25天到期，虽然理论上还有时间，但我不想等到最后一周再处理。

3.1 先在VAMI里看清楚证书现状

登录VAMI后，左侧菜单点“证书”，页面会列出vCenter维护的所有证书store，包括machine、vsphere-webclient、vpxd等。每张证书下面都有“有效期”和“状态”两个关键列。当时看到machine这张证书的过期时间比其余证书都早，状态显示“即将过期”。

这里的续订按钮可以直接点击，但VAMI界面一次只处理一个store，如果整套证书里有好几张都快到期，一个个点太费劲，而且中间还涉及服务重启顺序问题。所以我选择了命令行方式。

3.2 certificate-manager把所有过期证书一次搞定

SSH登录VCSA的shell，执行：

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

交互式菜单会出现几个选项：替换Machine SSL证书、续订VMCA下的所有证书、替换VMCA根证书、替换Solution User证书、强制续订过期证书。针对整套环境证书都快到期的情况，我选了“续订VMCA下的所有证书”这一项。

选择后工具会先执行一次备份，并向你确认备份路径。确认之后，它会自动为各个store重新生成证书，并按顺序重启vpxd、vsphere-ui、sts等服务。整个执行过程大概五到八分钟，期间vSphere Client会短暂掉线，这是正常现象，不要误以为操作失败了。

如果你不想面对交互式菜单，直接跑这个命令效果一样：

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

-r参数表示续订所有过期或即将过期的VMCA证书。这个适合放在变更窗口的脚本里跑，也可以结合-s跳过备份步骤，但我建议保留备份，多一步没坏处。

3.3 续订之后的服务检查与ESXi重连

证书续订完成后，第一件事不是急着登录vSphere Client，而是确认服务都正常。用命令：

service-control --status --all

检查vpxd、vsphere-ui、sts这几个关键服务，状态是“Running”才算正常。如果某个服务显示失败，优先去看日志，别急着重复执行续订命令。

服务正常之后，打开vSphere Client登录。这时候最常见的现象是主机列表里的ESXi状态变得异常，或者在主机上出现证书指纹相关的告警。原因很简单：vCenter自己的证书变了，ESXi和vCenter之间的信任关系也需要重新确认。处理方式是对每台ESXi主机执行“断连再重新连接”，连接时vCenter会提示新的证书指纹，确认信任即可。如果主机数量多，这个过程建议写成脚本或分批执行，避免全部同时重连造成vCenter瞬时压力过大。

4. 案例二：ESXi主机证书重新生成与信任重建

ESXi证书的处理比vCenter简单，但容易在细节上踩坑，尤其是“托管状态”和“独立状态”两种场景的操作方式完全不同。

4.1 vCenter托管状态下的ESXi证书更新

如果ESXi已经加入vCenter管理，不要直接在ESXi本地乱动证书，正确的方式是让vCenter统一管理。vCenter证书升级后，可以在vSphere Client中选中某台ESXi，进入“配置”-“安全配置文件”-“证书”，这里能看到当前证书的过期时间和签发者。如果显示证书不匹配或状态异常，操作是断开再重连，vCenter会为ESXi重新签发证书并完成注册。

这里有个细节：vCenter会自动向托管ESXi分发证书，但有的时候分发不及时。如果重连后还是证书告警，可以SSH登录ESXi执行：

esxcli system security certificate refresh

这条命令会向vCenter请求最新的信任配置，并把本地的证书更新到正确状态。

4.2 独立ESXi重新生成证书

不归vCenter管的独立ESXi，要么手动重新生成证书，要么导入外部CA签发的证书。如果你的ESXi Web管理界面还能登录，直接在“管理”-“安全”-“证书”页面点击“重新生成”，几秒钟就能完成。

如果Web界面已经因为证书过期进不去了，只能走SSH。先确认SSH服务已开启，然后执行：

esxcli system security certificate generate

重新生成证书后，重启管理服务让新证书生效：

/etc/init.d/hostd restart

如果这台主机还受vCenter管理（只是临时独立处理证书的情况），还需要：

/etc/init.d/vpxa restart

重启后浏览器再用https访问ESXi，会提示新的证书指纹，确认信任即可。

4.3 指纹验证和连接测试

证书更新完不能立刻关窗口。我习惯用openssl确认一下对外端口上的证书是否已经变成新的，命令如下：

echo | openssl s_client -connect <ESXi-IP>:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates

对比输出的Not After日期是否比之前晚了，基本就能判断更新是否生效。如果证书的新旧时间没有变化，说明操作没生效，需要回头检查是否有缓存或服务没重启干净。

在vCenter侧，如果主机重新连接后仍然显示证书不匹配，可以在主机列表里右键选择“重新连接”，并手动信任新的证书指纹。做完这一步，主机的“证书状态”才会恢复成正常。

5. 翻过车才知道的五个注意事项

5.1 客户端登录不了怎么办，应急路径是什么

最紧急的场景：vCenter的Machine SSL证书完全过期，vSphere Client已经登不进去。这时记住一个原则：5480端口的VAMI管理界面永远可能还活着。用root登录VAMI，虽然界面里的证书状态是红色的，但至少还能进。如果VAMI里点续订不生效，就转SSH执行certificate-manager菜单里的“强制续订过期证书”选项。

对于ESXi，如果hostd证书过期导致Web界面也进不去，而SSH也没启用，那就很被动了，只能到物理控制台或通过虚拟机串口操作。所以我建议平时给ESXi保留SSH的应急通道，至少确保需要时可以快速开启。

5.2 换CA后主机全部“不兼容”，多半是忘了TRUSTED_ROOTS

为了满足安全合规，不少环境会把VMCA证书替换成AD CS之类的内部CA证书。替换后经常出现一种情况：vCenter能登录，但所有ESXi主机都变成“不兼容”，原因是vCenter的TRUSTED_ROOTS证书库里没有放入新CA的根证书，ESXi不信任新的证书链，连接自然建立不起来。

解决办法是在VAMI的证书页面，把新CA的根证书和中间证书导入TRUSTED_ROOTS存储里，导入后重启vpxd服务。这一步远比想象中容易被忽略，我见过好几个环境就是因为漏掉了它，替换证书后整个虚拟化平台的主机全部失联，最后只能回滚证书重来。

5.3 服务启动失败的排查方向

证书续订过程中vCenter服务启动失败，最常见的原因有两个。一个是权限问题，certificate-manager必须以root身份运行，如果换用普通账户去跑，写入证书库时会被拒绝。另一个是磁盘空间不足，证书库的写入需要磁盘空间，VCSA的日志盘一旦写满，服务就会启动失败。

遇到启动失败，先看磁盘占用，再用VAMI导出的日志看vpxd的报错细节。别急着反复执行续订命令，那样可能把证书链弄得更乱，反而拖长故障时间。

5.4 时钟漂移比证书本身更坑

有一次更新完证书，怎么验证都显示“证书无效”，排查了很久最后发现是ESXi的时钟比vCenter慢了4分钟，而新证书的生效时间以签发方也就是vCenter的时间为准，ESXi在验证时看到证书还没到生效时间，就判定为不合法。这种问题如果不往NTP方向想，能排查一晚上。所以我在前文反复强调时间同步，这不是随便说说，是实打实的教训。

5.5 内容库、vSAN、Update Manager这些组件别漏掉

证书更新后，很多人只盯着vSphere Client和主机列表，很容易忽略vCenter里的其他依赖证书的组件。内容库（Content Library）在证书更新后可能出现访问异常，vSAN环境中vCenter和Witness节点之间同样有证书信任关系，老的vCenter环境里还有Update Manager，它的证书也不会出现在默认的VAMI菜单里。

我的习惯是整套证书更新完成后，把vCenter里所有“证书”和“信任”相关的页面都过一遍，再看看内容库和vSAN的告警是否正常。这套检查不会花超过五分钟，但能避免“明明续订了证书，过了几天却冒出新的证书告警”这种莫名其妙的情况。

6. 长期运维建议：怎么把证书风险控制在变更窗口之前

处理过几次证书故障之后，我在每个vSphere环境里都会固化一套简单的运维习惯，这里也分享给你。

6.1 每月三分钟检查和一条命令

不需要装额外的监控工具，一个月登录一次VAMI点开“证书”页面，看看最近的过期时间就够。如果你习惯命令行，把这条加到巡检脚本里：

/usr/lib/vmware-vmca/bin/vecs-cli entry list --store machine --text | grep -A 1 "Not After"

对于ESXi主机，也可以用openssl批量扫一遍443端口的证书过期时间。只要把上面那条s_client的检查命令循环跑一遍所有管理IP就行。设置监控工具的话，把“SSL证书剩余天数低于45天”作为告警阈值比较合理，既留足了处理时间，又不会一年到头被无关紧要的提醒打扰。

6.2 把证书更新固化到运维流程里

证书更新应该和打补丁一样进入标准变更流程：备份、检查时间同步、执行续订、验证服务、检查所有关联组件。这个流程固化之后，不管谁接手这套环境，都有一份可执行的清单，不至于临时翻文档。

经历过VMware证书翻车的人应该都有同感：证书问题本身并不可怕，可怕的是它总在你不注意的时候冒出来，而且一旦拖到过期再处理，所有操作都变成了“救火模式”，压力翻倍、出错概率也翻倍。所以我的建议很简单，把证书检查做成习惯，把续订步骤提前演练熟，等告警真正来的时候，你只需要按部就班执行就行。

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