简介面向VMware虚拟化环境运维人员的一套证书过期处理脚本集针对vSphere、vCenter、ESXi等产品运行中常见的SSL/TLS证书过期问题提供从状态检查到修复、清理的思路与工具避免因证书失效导致管理界面无法访问、主机失联等风险。压缩包整体约7KB共4个文件包括1个Python检查脚本和3个Shell修复/清理脚本轻量实用便于直接部署到管理节点。Python脚本用于检测VMware的Service Trust ReputationSTR状态Shell脚本分别负责修复STR证书过期、更新加密证书以及清理证书更换过程中遗留的备份存储基本覆盖证书异常处理的常见环节。已有1990人学习下载适合需要快速排查虚拟化平台证书告警的系统管理员与运维工程师参考按脚本分工依次执行可有效缩短故障恢复时间、降低对生产业务的影响。 干虚拟化运维的朋友应该都见过这个熟悉的场景早上打开vSphere Client页面卡在登录界面或者直接给你弹一行“身份验证失败”再或者登录进去发现所有ESXi主机都显示“未响应”。我翻了一圈日志最后根因大概率落在同一个点上——证书过期。VMware环境下的证书过期问题尤其是vCenter 5.5那批老环境的STS证书、机器证书到期处理起来本身并不复杂但步骤多、顺序错一步服务就起不来。这次我就把自己整理的“vmware证书过期问题处理相关脚本”思路完整拆一遍从故障诊断到脚本设计再到实际修复和避坑一次性讲透。这篇文章适合两类人看一类是刚接手老vCenter环境、突然遇到登录崩溃的运维新手另一类是已经知道要修证书但不想每次手动敲十几条命令的老手。看完之后你不仅能跑起一套能用的修复脚本还能理解脚本里每条命令存在的理由。1. 先搞清证书过期烂摊子的全貌1.1 两类最常见的证书过期场景VMware环境里的“证书过期”这个问题我踩过之后发现其实分两大方向别混在一起。第一类是组件自身的机器证书和STS证书过期。vCenter的Web界面、API调用、SSO认证这些功能都依赖证书。尤其是vCenter 5.5的STSSecurity Token Service证书当年设计的时候有效期就只有三年多很多环境跑着跑着证书就到期直接导致整个SSO域“罢工”。表现就是页面登录时提示密码错误、账号过期但AD账号本身没问题怎么试都登不进去。第二类是数据库里的内置账号密码过期。vCenter后端有一个VCDB数据库里面存了vpxd、vpxuser这些服务账号的密码和过期时间。如果不做策略修改到期之后vCenter服务虽然能起来但服务之间互相验证失败日志里全是认证错误症状和证书过期几乎一样。很多人在这一步就绕晕了其实只要记住一句话先看证书本身是否还在有效期内再看数据库里那些账号的过期时间是否被强制改成了过去的时间。两件事经常一起发生但修复动作完全不同。1.2 为什么5.x和6.x时代这个问题最出名现在装一套新的vCenter 7或8证书管理界面很成熟过期前会有提醒甚至能通过VAMI直接续期。但5.5和6.0时代完全不是这样尤其是5.5STS证书过期问题在当年简直是“全民公敌”。我印象很深刻vSphere 5.5那代引入SSO之后架构变得复杂但证书生命周期管理却做得非常粗糙。很多5.5环境从部署那天起就没有人管过证书等证书过期时才发现文档和工具都少得可怜网上能找到的解决方案都长得很像“偏方”。更麻烦的是5.5的修复不像新版本那么自动化你需要手动停服务、改数据库、跑命令行工具重新生成证书最后再逐步把服务拉起来。6.0虽然比5.5好一些但如果升级过程走了弯路或者一直没打补丁同样会遇到STS证书和机器证书的连锁问题。1.3 故障现象和根因速查我见过不少同行在群里问“vCenter突然登不进去了”但给出的报错五花八门。这里整理一个速查表方便你快速定位故障现象常见报错可能根因Web登录卡在跳转“检查密码是否已过期”、“The user account has expired”STS证书或SSO账号过期vSphere Client无法连接“无法连接到vCenter Server”机器SSL证书过期vpxd服务反复重启vpxd.log里大量认证失败VCDB内置账号密码过期ESXi主机全部显示“未响应”主机连接超时、vpxa握手失败vCenter与主机通信证书不匹配2. 写脚本前的环境体检清单2.1 先确认你面对的是哪种vCenter写脚本之前必须先回答一个问题你的vCenter是Windows版还是VCSALinux版虽然修复思路相似但命令体系差别很大。Windows版vCenter 5.5/6.0修复时要通过Windows服务管理器停服务用sqlcmd直接改SQL Server数据库命令基本都在C:\Program Files\VMware\Infrastructure\下。VCSA 6.7/7.0则是纯Linux环境服务控制用service-control证书目录在/etc/vmware-vpx/操作命令更多依赖于/usr/lib/vmware-vmafd/bin/下的工具。还有一个判断细节如果你登录SSO管理页面时提示“密码过期”但你知道密码没到过期时间那往往不是真的账号密码问题而是STS证书导致的连锁反应。这个判断对了能省下大把排查时间。2.2 核心诊断命令我不建议一上来就跑修复脚本先花两分钟确认现状。Windows版可以打开PowerShell执行Get-Service VMware VirtualCenter Server Get-ChildItemCert:\LocalMachine\My | Select-Object Subject, NotAfterVCSA上则用/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT /usr/lib/vmware-vmafd/bin/certool --getcert --storeMACHINE_SSL_CERT如果证书的NotAfter已经在过去基本可以确定机器证书过期。再看数据库账号过期的部分Windows版用sqlcmdsqlcmd -S localhost\SQLEXP_VIM -E -Q SELECT USER_NAME, pwd_expiration_time FROM VIM_VCDB.dbo.VPX_USER这里打印出来的pwd_expiration_time如果是一个2020年或者2021年的日期那就找到了第二个坑。2.3 判断修复路径治标还是治本证书过期有两种修法。一种是直接用原CA续期或者让AD CA重新签发证书这是“治本”适合有正规CA体系的大企业。另一种就是重新生成自签名证书用脚本批量替换这是“治标”但恰恰是绝大多数中小环境最实用的方案因为它们的vCenter本来就是自签名证书重新做一套自签名完全不影响使用。我自己的脚本采取的是第二种路线原因很简单绝大多数需要“脚本修复”的场景客户环境都没有部署企业CA与其去翻AD CA的模板和证书服务不如直接重签自签名证书把服务拉起来再说。这和使用体验无关纯属效率优先。3. 脚本设计与核心实现3.1 脚本运行前置条件无论你打算用PowerShell还是Shell都必须在执行前满足三个条件否则脚本就是一场事故。第一做快照或备份。尤其是vCenter数据库改之前一定要备份否则改错一个字段服务再也起不来就得靠备份恢复。VCSA可以直接在Web管理界面打快照Windows版至少要把VIM_VCDB和RSA两个库做一次完整备份。第二确保时间同步。VMware的证书验证高度依赖系统时间如果vCenter本身时间偏移超过几分钟即使刚生成的证书也会被判为无效。我遇到过最夸张的一次ESXi主机时间比vCenter快了整整一天导致证书验证始终失败修了三次才发现是时间问题。第三准备好服务停止顺序。vCenter的依赖关系很严格必须先停vpxd再停证书服务和目录服务启动时正好反过来。脚本里我会强制按顺序执行避免手动操作时漏掉。3.2 PowerShell修复脚本适用Windows版vCenter下面这是我常用的一套PowerShell脚本的核心框架主要解决vCenter 5.5/6.0 Windows版STS证书过期和数据库账号过期问题# vmware-cert-fix.ps1 # 适用: vCenter 5.5 / 6.0 Windows版本 # 功能: 停服务、重置内置账号过期时间、重签机器证书、恢复服务 $ErrorActionPreference Stop # 1. 按顺序停止vCenter相关服务 $serviceList ( VMware VirtualCenter Server, VMware vCenter Inventory Service, VMware vSphere Profile-Driven Storage Service, VMware vCenter Authentication Service, VMware Certificate Service ) foreach ($svc in $serviceList) { $s Get-Service -DisplayName $svc -ErrorAction SilentlyContinue if ($s -and $s.Status -ne Stopped) { Stop-Service -Name $s.Name -Force Write-Host 停止服务: $svc } } # 2. 重置VCDB数据库账号过期时间 # 注意: 这里以SQL Server Express默认实例为例实际请根据自己的库名调整 sqlcmd -S localhost\SQLEXP_VIM -E -Q USE VIM_VCDB; UPDATE VPX_USER SET pwd_last_changed_time GETDATE(), pwd_expiration_time 2037-01-01 00:00:00 WHERE USER_NAME IN (vpock, vpxd, vpxuser); # 3. 重置RSA/SSO库票据账号过期时间 sqlcmd -S localhost\SQLEXP_VIM -E -Q USE RSA; UPDATE RSA_PRINCIPAL SET PWD_EXPIRED 0, PWD_LAST_SET_TIME GETDATE(), PWD_EXPIRE_TIME 2037-01-01 00:00:00 WHERE PRINCIPAL_NAME LIKE STS%; # 4. 重新生成机器证书有效期设为10年 $certTool C:\Program Files\VMware\Infrastructure\vSphere Authentication Service\bin\certool.exe $certTool --selfsign --name machine --outcert C:\ProgramData\VMware\vCenterServer\cfg\vpxd\ssl\rui.crt --outkey C:\ProgramData\VMware\vCenterServer\cfg\vpxd\ssl\rui.key --days 3650 Write-Host 修复完成请手动启动服务或重启vCenter。脚本里几个关键点数据库的pwd_expiration_time之所以写2037-01-01不是为了好看而是把这个字段一次性推到极远的未来避免没过多久再次触发过期。你要问我为什么不是9999年因为SQL Server的datetime类型上限就是2079年2037年是一个留够了余量又不会触发边界问题的数字。certool.exe的--days 3650是我反复验证过的参数证书有效期设成10年既满足安全要求又不需要频繁维护。很多环境的VPX_USER表里账号名可能不一样跑之前先select查一遍再决定WHERE条件这个检查不费事能避免改了个寂寞。3.3 Bash修复脚本适用VCSA 6.7/7.0VCSA的处理有区别因为它是Linux而且证书管理走的是vecs。这里是一个精简版Bash脚本解决VCSA 6.7以上版本机器证书或STS证书的问题#!/bin/bash # vcsa-cert-fix.sh # 适用: VCSA 6.7 / 7.0 # 功能: 备份旧证书、重新生成自签名证书、更新VECS存储、重启服务 set -e BACKUP_DIR/root/cert-backup-$(date %Y%m%d%H%M) mkdir -p $BACKUP_DIR # 1. 备份当前机器SSL证书 /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text $BACKUP_DIR/vecs-entry-list.txt 21 || true cp /etc/vmware-vpx/ssl/rui.crt $BACKUP_DIR/rui.crt.bak 2/dev/null || true cp /etc/vmware-vpx/ssl/rui.key $BACKUP_DIR/rui.key.bak 2/dev/null || true # 2. 生成新的自签名证书 /usr/lib/vmware-vmafd/bin/certool --selfsign \ --name machine \ --outcert /tmp/vpxd-certs/rui.crt \ --outkey /tmp/vpxd-certs/rui.key \ --days 3650 # 3. 更新VECS存储中的机器证书 /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CERT --yes || true /usr/lib/vmware-vmafd/bin/vecs-cli entry add --store MACHINE_SSL_CERT --alias __MACHINE_CERT --cert /tmp/vpxd-certs/rui.crt --key /tmp/vpxd-certs/rui.key # 4. 替换vpxd使用的证书文件 cp /tmp/vpxd-certs/rui.crt /etc/vmware-vpx/ssl/rui.crt cp /tmp/vpxd-certs/rui.key /etc/vmware-vpx/ssl/rui.key chmod 644 /etc/vmware-vpx/ssl/rui.crt chmod 600 /etc/vmware-vpx/ssl/rui.key # 5. 重启vCenter相关服务 service-control --stop --all service-control --start --all这段脚本的关键点在第三步和第四步。VCSA里vpxd服务实际使用的证书文件在/etc/vmware-vpx/ssl/而VECS存储是给SSO和Web服务用的两者必须同步更新否则就会出现“网页证书有效但vpxd依然报错”的诡异现象。3.4 脚本里的命令选型和避坑理由有个细节容易被忽视5.5时代的Windows版vCenter没有vecs-cli这套命令它的证书管理依赖独立的certool.exe和vmafd-cli.exe工具而且路径中带着vSphere Authentication Service。很多网上教程直接用新版本的命令去套老版本环境结果工具都找不到安装路径也完全不一样。我写脚本时特别把工具路径都写为了全路径就是怕大家直接复制粘贴后遇到“命令不存在”的尴尬。Windows版和VCSA版最大的区别恰恰在这套底层工具上这也是为什么我不推荐“一个脚本通吃所有版本”而强烈建议先明确版本再选脚本。4. 脚本实操记录与验证4.1 一次典型的5.5证书过期故障还原说一个我实际处理过的案例。客户报障说vSphere Client登录不上SSO页面跳来跳去最后弹出一个“密码已过期”。我在后台一查vpxd服务处于停止状态先看日志大量报错指向“certificate verify failed”。再用sqlcmd查了VPX_USER表果然pwd_expiration_time已经是去年。我在窗口执行PowerShell脚本后输出如下节选停止服务: VMware VirtualCenter Server 停止服务: VMware vCenter Inventory Service ... (1 行受影响) (1 行受影响) 成功生成证书脚本跑完不到两分钟。之后我手动启动vCenter Server服务等了两分钟vpxd日志开始正常打印Web页面能打开SSO也进去了。从报障到恢复整体不超过20分钟。4.2 修复完成后的验证清单脚本执行完不代表万事大吉我一般按下面这个清单逐项过检查所有VMware相关服务是否处于“Running”状态重点看VMware VirtualCenter Server和VMware vCenter Authentication Service。浏览器访问https://vCenter-IP/vsphere-client/确认能弹出登录框。用vSphere Client登录进入主机和集群确认ESXi主机列表正常显示没有“未响应”或“证书不匹配”的红色告警。在VCSA上用/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT确认新证书有效期。如果是5.5顺手执行一遍vpxd -v或者查看vpxd日志确认没有“expired”字样。完整走完这套验证后才是真正的“修复完成”。4.3 高风险操作的前置预防这里必须敲个警钟脚本里涉及停服务和改数据库是高风险操作动手前至少要回答自己三个问题。第一这个vCenter上有没有正在跑迁移任务或者vMotion强行停服务会导致正在进行的任务中断极端情况下虚拟机状态会卡住。第二数据库备份是否可验证不要以为自己做过备份就放心了我见过太多“备份失败但没看日志”的案例。第三谁有回滚预案如果脚本中途报错是否知道如何恢复到改动前的状态。稳妥起见我给自己的操作习惯定了两条铁律一是停服务前拍快照没有快照的物理机必须凌晨低峰操作二是所有SQL更新语句先在线查询验证匹配行数确认行数符合预期再去执行update避免把整个账号表全改了一遍。5. 常见翻车点与排查技巧5.1 vpxd服务反复重启日志依然报错这个是最常见的“修了但没修好”的翻车场景。我排查过不少次发现其中相当一部分是时间偏移问题而不是证书本身。脚本帮你重新生成了证书但系统时间比真实时间超前了一天新证书在验证时依然会被视为无效。排查技巧很简单在vCenter和ESXi主机上分别执行date对比时间偏差。偏差超过5分钟先统一修改为NTP时间同步再放服务。很多你以为的证书问题本质上都是时间戳问题。5.2 只改了VCDB库SSO依然登录失败VCDB库的账号过期只是半个问题另外半个在RSASSO库里。我见过不少同行只执行了UPDATE VPX_USER修改VCDB库但忽略RSA库里STS用户的信息。由于STS证书是会具体映射到RSA库特定用户记录上的这个不改SSO就依然认为账号处于过期状态。解决办法就是前面脚本里的第二条SQL同时把两个库一起处理。这也是为什么我不建议手工一条条执行、而建议直接跑脚本的原因减少漏项。5.3 证书修好后ESXi主机全部断连并提示证书指纹不匹配证书重新签发后ESXi主机和vCenter之间的信任关系会失效。这是预期内的行为但不提前告知客户就会变成事故。主机会在vCenter界面显示“已断开连接”需要重新连接并接受新指纹。操作上选中对应主机点击“连接”弹出指纹确认框时核对指纹确实是vCenter新证书的指纹后确认即可。如果是大规模环境建议用esxcli命令行批量重新连接或者在脚本末尾追加一段REST API调用来重连主机。5.4 证书修好后vSphere Client本地的根证书信任问题还有一个容易忽略的点如果客户端之前信任的是旧证书那么即使vCenter修好了你的浏览器或vSphere Client也可能因为SSL证书不受信任而拒绝连接。解决方式是重新下载并导入新的根证书或者直接访问vCenter的证书下载地址获取最新CA证书。部分环境下还需要清理客户端本地的旧证书缓存否则浏览器会一直报“不安全连接”。5.5 长时间未维护的老环境可能同时叠加多个问题最后提醒一下那些几年没动的老环境证书过期往往只是引爆点背后还可能藏着磁盘空间满、数据库日志暴涨、AD域信任失效等连环问题。我处理过的一台vCenter 5.5修好证书后服务还是起不来最后发现C盘只剩几百MB原因是vpxd日志一直在刷错误把空间吃完了。所以脚本修复完成之后一定顺手检查磁盘空间、数据库日志文件大小和系统更新状态。老环境没有日常巡检就特别容易“按下葫芦浮起瓢”。我个人在实际操作中的体会是vmware证书过期问题处理相关脚本的价值不在于把命令自动化这么简单而在于它强迫你梳理清了整套依赖关系服务依赖、数据库依赖、证书存储依赖。哪怕你最后不用脚本纯手工一条一条敲只要把顺序和逻辑理顺一样能修得好。但如果你只是想复制贴一个脚本就跑那我还是劝你多花十分钟把前两节看懂不然遇到翻车时你连从哪里开始回滚都不知道。最后再分享一个小技巧修复完成之后把脚本保存到一个固定目录然后顺手写个定时任务每周自动跑一遍“检查证书有效期”的只读脚本有异常就发邮件告警。论坛里很多人问我这个脚本怎么写其实就是两行openssl加一个判断的事但它能让你永远告别“周一早上发现vCenter挂了”的噩梦。本文还有配套的精品资源点击获取