企业官网建设流程全解析

简介：VMware证书过期是虚拟化运维中常见且棘手的问题，轻则出现安全警告，重则导致vCenter管理界面无法访问、ESXi主机失去连接，甚至影响业务连续性。这套脚本专门面向VMware管理员和虚拟化运维人员，聚焦vSphere/vCenter证书过期场景，提供从检查到修复的完整处理思路，适合有一定虚拟化基础、需要快速排障的技术人群。资源共4个文件，包含1个Python脚本和3个Shell脚本，压缩包仅7KB，轻量易用。checksts.py负责检查Service Trust Reputation（STR）状态，帮助定位过期证书；fixsts.sh用于修复STR过期问题；fix_encipherment_cert.sh专门处理加密证书更新；clean_backup_stores.sh则用于清理旧备份存储，避免残留配置干扰新证书。目前已有1990人学习下载，是运维排障中值得收藏的实用工具集。通过这套脚本，读者可以快速理解证书过期排查逻辑，按步骤完成状态检查、修复和清理，有效降低因证书过期导致的管理风险和业务中断概率。 vCenter 5.5的证书过期，绝对是老运维人绕不过去的一课。前两天半夜被电话叫醒，说虚拟化平台登录不进去了，Web Client一直报“证书已过期”，SSO服务起起停停，ESXi主机一片已断开。我远程一看，果然是机器证书过了期。折腾了几个小时，手工重置完又因为漏了iphash的刷新，二次返工。这事过去之后，我索性把整套排查、处理、验证流程全部固化成脚本，以后再遇到类似问题，直接按流程跑，既不慌也不会漏步骤。

这篇东西就是围绕“vmware证书过期问题处理相关脚本”整理的实战经验，覆盖vCenter 5.5老版本和6.7以上新版本两种典型场景，也包含批量巡检、服务重置、问题排查的Shell/PowerShell脚本。适合整天维护VMware虚拟化环境的运维、虚拟化管理员，也适合正在被vCenter证书问题折磨、想找现成处理方案的朋友。我按实际处理的顺序来讲，从怎么判断“真的是证书过期”开始，到脚本怎么设计、关键步骤怎么拆，最后把踩过的坑和排查技巧一并列出来。

1. 先判断“是不是证书过期”：典型症状与快速验证

1.1 症状画像：不是所有故障都是证书过期

证书过期之后的表象五花八门，而且很多时候第一眼根本看不出是证书的问题。我遇到过最典型的情况是：vSphere Web Client能打开登录页，但输入账号后提示“服务器证书不受信任”，或者干脆一直转圈进不去；vCenter管理服务里，vmware-vpxd、vmware-sso等几个服务处于Stopped状态，手动启动几秒钟后又自动停止；用PowerCLI连接vCenter时，提示SSL握手失败；通过vSphere Client添加主机时，报证书校验不通过。

这里要特别提醒，有些症状和证书过期非常相似，但根因完全不同。比如“VMware Workstation 无法连接到虚拟机”很多时候是权限、服务或者虚拟机配置文件的问题；“无法在更新服务器上找到组件”大概率是补丁源或更新配置的问题。遇到这些报错，先别急着重置证书，否则处理完发现根本不解决问题，反而把环境搞得更乱。

1.2 快速验证：openssl和PowerCLI查证书有效期

判断证书是否真的过期，最快的方式是直接看证书的有效期。在Linux或macOS终端下，可以用openssl命令远程查看vCenter的证书信息：

echo | openssl s_client -connect vcsa01.example.local:443 -servername vcsa01.example.local 2>/dev/null | openssl x509 -noout -dates -subject

如果命令输出里的notAfter字段已经早于当前时间，那基本可以下定论了。在Windows环境里，可以用PowerShell通过SSL流来获取远程证书：

function Get-CertExpiry { param([string]$HostName, [int]$Port = 443) $tcp = New-Object System.Net.Sockets.TcpClient($HostName, $Port) $ssl = New-Object System.Net.Security.SslStream($tcp.GetStream(), $false, { $true }) $ssl.AuthenticateAsClient($HostName) $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]$ssl.RemoteCertificate $ssl.Dispose() $tcp.Dispose() [PSCustomObject]@{ HostName = $HostName NotAfter = $cert.NotAfter DaysLeft = ($cert.NotAfter - (Get-Date)).Days } } Get-CertExpiry -HostName vcsa01

下面这个表格是我在实际排障中总结的快速对照，能帮你在第一时间缩小问题范围：

2. 脚本方案的整体思路与设计原则

2.1 为什么必须上脚本，而不是手工点来点去

证书处理不是“点一个重置按钮”就完事。vCenter的证书体系牵扯到多个组件，仅Windows版vCenter就有SSO服务、vmafd目录服务、vpxd服务、机器SSL证书，每一个组件都有自己独立的证书。手工处理时，一旦服务重启顺序不对，或者遗漏了一个证书的重置，接下来会出现一连串莫名其妙的报错。而且实际操作过程非常长，中间还要备份、记录、验证，人脑很容易漏细节。

脚本最大的价值是可重复、可追溯、顺序固定。处理过一次之后，把整个流程固化成脚本，下次再遇到证书过期，不需要回忆“上次我到底先停了哪个服务”，直接执行脚本就行。对团队运维来说，脚本也能保证不同的人处理时走的流程完全一致，避免“A这么做能好，B那么做就坏了”的尴尬情况。

2.2 脚本需要解决的三类任务

在设计脚本方案时，我把它拆成三类，这样职责清晰，调用也灵活：

• 巡检类：定期检查vCenter、ESXi主机、带外管理地址的证书有效期，提前发现快要过期的证书，避免“半夜被电话叫醒”。
• 处理类：根据vCenter版本执行证书重置、SSO初始化、iphash刷新等核心修复动作。
• 验证类：处理之后自动检查服务状态和证书日期，输出处理结果报告，确认问题真正被解决。

一个完整的处理流程应该遵循这样的顺序：检查证书情况、备份当前配置、停止相关服务、重置证书、重建配置信息、按顺序启动服务、最后重新验证证书和服务状态。脚本的骨架就是围绕这个顺序搭建的。

3. 核心脚本实现与关键步骤拆解

3.1 证书批量巡检脚本（Linux Shell版）

巡检是性价比最高的环节。我在生产环境的跳板机上放了一个Shell脚本，定时对所有vCenter和ESXi的443端口做证书有效期检查。核心逻辑其实很简单，就是循环遍历主机列表，用openssl抓取证书结束日期，然后换算成剩余天数：

#!/bin/bash HOSTS=( "vcsa01.example.local 443" "esxi01.example.local 443" "esxi02.example.local 443" ) for item in "${HOSTS[@]}"; do host=$(echo "$item" | awk '{print $1}') port=$(echo "$item" | awk '{print $2}') end_date=$(echo | openssl s_client -connect "${host}:${port}" -servername "${host}" 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2) if [ -n "$end_date" ]; then end_epoch=$(date -d "$end_date" +%s) now_epoch=$(date +%s) diff_days=$(( (end_epoch - now_epoch) / 86400 )) echo "$host:$port 证书剩余 ${diff_days} 天" else echo "$host:$port 无法获取证书" fi done

把这个脚本加到crontab里，每两周跑一次，结果输出到日志文件。如果剩余天数少于15天，日志里会出现非常明显的数字，我一眼就能看到需要处理的目标。这个习惯帮我躲过了好几次“被动故障”。

3.2 vCenter 5.5场景：重置SSO与机器证书

老版本的Windows版vCenter（尤其是5.5）处理证书过期是整套环境里最麻烦的。因为组件都是Windows服务，重置时没有像新版VCSA那样统一的管理入口，全靠命令行。我整理了一个比较稳妥的处理顺序，脚本化之前先在测试环境验证过。

第一步，用管理员权限停止关键服务：

# 以管理员身份执行，此步骤要在高权限PowerShell中运行 net stop "VMware VirtualCenter Server" net stop "VMware SSO Service"

第二步，备份现有配置。证书操作前必须备份，这是底线。主要备份SSO目录和SSL证书目录：

$backupRoot = "C:\backup\vcenter_cert_backup" New-Item -ItemType Directory -Path $backupRoot -Force Copy-Item "C:\ProgramData\VMware\vCenterServer\cfg\sso" "$backupRoot\sso" -Recurse Copy-Item "C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx\ssl" "$backupRoot\vpx_ssl" -Recurse

第三步，重置SSO证书和机器证书。不同小版本的vCenter 5.5工具路径可能有些差异，脚本里建议用全路径调用，部署前先确认一下实际路径。比较常用的是vmafd-cli和certool这两个工具：

$vmafdCli = "C:\Program Files\VMware\Infrastructure\VMware\CIS\vmafdd\vmafd-cli.exe" $certool = "C:\Program Files\VMware\Infrastructure\VMware\CIS\vmcad\certool.exe" # 获取当前机器ID，确认vmafd服务可用 & $vmafdCli get-machine-id --server localhost # 重置机器SSL证书（核心步骤，不同环境需要结合RUFCTemplate.cfg配置执行） # & $certool --genkey --privkey=... --pubkey=... --name=...

网上流传的lsdoctor脚本能处理一部分SSO问题，但它只修SSO证书，重置完之后机器证书照样是过期的，该出的问题还会出。我的经验是：不能把lsdoctor当成万能方案，用它之前一样要备份现场。

第四步，检查vpxd.cfg里的iphash。这一步非常容易被遗漏。vCenter 5.5中，vpxd与ESXi主机通信时会用到ssl指纹相关的hash值，如果重置证书后这个值没有同步更新，主机在vCenter里会一直处于“未响应”或“正在连接”状态。脚本里可以加一个提示，处理完证书后重新检查每个主机的连接状态，必要时通过vSphere Client移除并重新添加主机来强制重建信任关系。

第五步，按顺序启动服务。先启动SSO服务，等待它稳定，再启动vCenter服务：

net start "VMware SSO Service" Start-Sleep -Seconds 15 net start "VMware VirtualCenter Server"

3.3 新版vCenter（6.7及以上）certificate-manager重置

如果你维护的是VCSA（Linux版vCenter），处理证书过期会舒服很多。6.7及更新版本内置了certificate-manager工具，SSH登录到VCSA后执行：

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

按提示选择“Replace Machine SSL certificate with VMCA generated certificate”，系统会自动重新生成证书并注册到各个服务。整个过程是交互式的，如果要写成全自动脚本，可以用expect配合处理选项确认，也可以直接用VAMI（https://vcsa_ip:5480）页面里的证书重置功能，效果是一样的。

对于7.0、8.0这些更新版本，还有一种更快捷的命令行方式：

cmsso-util certificate-reset

这个命令会读取当前环境的拓扑结构，自动重置各个vCenter节点和Platform Services Controller的证书。注意，reset之后所有的trust关系会重建，如果有外部VC、扩展组件、第三方解决方案在跑，务必提前确认兼容性。

3.4 ESXi主机侧的检查与重连验证

证书重置完成后，别急着收工。我见过很多人在vCenter里把证书修好了，但ESXi主机侧因为指纹变化，导致管理平面上显示异常。此时可以先用命令行测试主机与vCenter的握手：

openssl s_client -connect esxi01.example.local:443 -servername esxi01.example.local

如果主机侧的证书也过期了，需要单独在ESXi主机上做证书重置（DCUI进入Troubleshooting Options，或者用esxcli命令）。大多数情况下，vCenter证书重置之后，需要把每个主机从vCenter中移除再重新添加，强制重新建立信任关系。这个操作在脚本里可以写成等待用户确认的步骤，因为移除主机的动作有一定风险，建议在业务低峰期执行。

4. 实操中的高频坑与排查技巧

4.1 服务起不来的排查顺序

证书处理完了，服务却起不来，这是最常见的翻车现场。我的排查顺序是：先看vmafd，再看vpxd日志。vmafd是整个SSO体系的根，它不正常，SSO服务肯定起不来，vCenter更别想。确认vmafd进程存在且稳定后，再去翻vpxd日志，路径一般在C:\ProgramData\VMware\VMware VirtualCenter\Logs\vpxd.log（新版VCSA在/var/log/vmware/vpxd/vpxd.log）。

还有个容易被忽略的点：重置证书后，vCenter服务首次启动比平时慢很多，可能要几分钟。别三秒钟没起来就反复重启服务，反而不利于日志写入。

4.2 时间同步问题最容易被忽略

证书的有效性判断完全是基于系统时间的。如果系统时间和真实时间偏差太大，哪怕新生成的证书也会被判为“无效证书”。我遇到过一例，客户说刚重置完证书还是报错，远程一看，vCenter虚拟机的时间慢了整整一天，和新证书35天有效期的边界一碰撞，瞬间就觉得“怎么弄都不对”。所以处理证书前，先做一次时间同步。

Windows版vCenter用w32tm /resync，VCSA用chronyc或者是ntpdate（视版本而定）。同步完再跑证书脚本，很多诡异问题会自然消失。

4.3 环境变量类报错与脚本执行环境

排查过程中免不了在PowerShell里敲命令，如果你遇到“claude : 无法将‘claude’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”或者“git : 无法将‘git’项识别为...”这类提示，先别慌，这跟VMware环境没有任何关系，就是命令所在目录没加到PATH环境变量里。这和证书处理属于两个维度的问题，但排障时特别容易混淆，让人误以为是脚本执行环境坏了。

我的习惯是，所有脚本里调用的工具都用绝对路径，避免依赖PATH。执行证书相关命令时，一定用管理员权限打开PowerShell，先把目标工具的路径验证一遍，再跑完整脚本。

4.4 IPMI/BMC带外管理证书的顺带检查

处理vCenter证书问题时，我总会顺手检查一下同机架的IPMI/BMC带外管理地址。很多机房的带外管理依然在用默认证书，过期后虽然不至于立刻断管理，但等你哪天需要远程开机、看控制台，才发现地址打不开，就已经很被动了。方法很简单，把3.1节那个Shell脚本的主机列表替换成BMC地址列表，一样用openssl去探测443端口的证书。管理网络的证书巡检和虚拟化层的证书巡检合并成一份自动化任务，能省不少事。

4.5 处理前的备份与回滚预案

最后强调一下备份的重要性。证书重置涉及的是vCenter的信任链，一旦处理到一半出问题，轻则服务起不来，重则整个管理面瘫痪。生产环境处理前，至少要完成三件事：备份SSO相关目录和SSL证书目录、手工记录当前服务状态、如果环境支持，给vCenter虚拟机打一个快照或用存储快照。VCSA做快照相对容易，Windows版vCenter则至少保留一份目录拷贝。

万一处理失败，回滚的思路是：停止所有VMware服务，把备份目录原样覆盖回去，然后按顺序重启服务。一般情况下都能恢复到处理前的状态。这个回滚流程我会在脚本末尾打印出来，提醒自己“想清楚了再操作”。

我个人在实际操作中的体会是：证书过期这事，真正熬人的不是重置命令本身，而是处理完之后的连锁反应。堆栈里的每个组件都重新握手，总有几个因为各种原因掉链子。把巡检、处理、验证三段工作都脚本化之后，至少不用每次都在凌晨靠回忆去拼步骤。如果你也维护着老版本VMware环境，建议先在测试环境把整套流程跑通，再拿到生产上用。胆大心细，脚本能救急，但别让它背锅。

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