HOME

NSX-T 3.2.4 新增 Manager 失败：OVF 签名证书过期排查记录

作者：祥积宫 2281字 预计阅读时间：11.4分钟 VMware
文章目录7 节

2026 年 9 月 16 日，我在 NSX-T 3.2.4 中新增第二台 Manager，页面很快显示“安装失败”，原因只有一句 Some error has occurred.。现有节点仍然可用，集群也显示稳定，单看页面无法知道新增任务停在哪一步。

排查后确认，内置部署包的 OVF 签名证书已于 2026 年 1 月 3 日过期。按照 Broadcom KB 424035 调整内部 OVF 校验开关后，重新尝试新增节点，页面进入了“1% 正在安装”。这篇记录保留从失败到恢复安装流程的过程；截至本次截图，新节点尚未完成安装和入群验证。

文中的截图已裁剪并遮盖节点标识，管理地址和集群标识不予展示。

页面提示很少，先确认失败发生在哪一步

本次环境的 NSX 软件版本为 3.2.4.0.0.23653568，产品版本为 3.2.4.0.0.23653566。当时只有一台运行中的 Manager，正在通过 NSX 管理页面新增第二台。

新增 Manager 时提示安装失败，原因仅为 Some error has occurred.

我通过 Termark 连接现有 Manager，先检查节点状态和日志。现有集群的各服务组均为 UP，整体状态为 STABLE，根分区和日志分区也没有写满。真正的线索在 /var/log/proton/nsxapi.log。

风险等级：INFO（只读）

在现有 NSX Manager 的 root Bash 中执行，按错误关键字筛选部署日志。命令只读取文件，输出最后 40 条匹配记录；应结合本次任务的时间和节点名称确认关联性。

grep -nE 'CERTIFICATE_EXPIRED|Primary certificate has expired|CertificateManifestValidationError' \
  /var/log/proton/nsxapi.log | tail -40

当天北京时间 14:42 和 14:44 的两次新增任务都出现了以下错误。下面摘录关键字段，省略任务 UUID 和重复堆栈：

Primary certificate has expired on Sat Jan 03 22:17:41 UTC 2026
errorCode="MP31703"
untrusted_certificate. Error : [VALIDATION_ERROR: CERTIFICATE_EXPIRED; ]
com.vmware.nsx.management.ovfops.exception.CertificateManifestValidationError
phase= 'PreVMDeploy'

PreVMDeploy 表明，这两次任务都停在虚拟机部署前的校验阶段。日志中的 SfdmOvfCertificateValidator 和 CERTIFICATE_EXPIRED，把调查范围缩小到了部署包签名证书。

直接读取部署包证书，核对到期时间

为了确认不是页面误报，我继续读取日志所指向的部署包证书。下面的路径来自本次 3.2.4 环境，其他版本应以自身部署日志中的仓库路径和文件名为准。

风险等级：INFO（只读）

在现有 NSX Manager 的 root Bash 中执行。-noout 避免输出证书正文，-dates 显示有效期，-subject 和 -issuer 显示证书主体与签发者。命令不会修改证书。

openssl x509 \
  -in /repository/3.2.4.0.0.23653566/Manager/ovf/nsx-unified-appliance-3.2.4.0.0.23653568.cert \
  -noout -subject -issuer -dates

实际输出中的有效期为：

notBefore=Feb 26 22:17:41 2010 GMT
notAfter=Jan  3 22:17:41 2026 GMT

主机日期是 2026 年 9 月 16 日，证书已经过期，且证书文件的到期时间与部署日志一致。过期的是安装包的 OVF 签名证书，更换管理页面的 HTTPS 证书无法解决这次错误。

官方知识库与现场现象一致

Broadcom 的 KB 424035：NSX Manager 部署时 OVF 证书校验失败 明确说明：

  • NSX 3.x 和 4.0.x 的 Manager 部署流程受影响，原因是签名证书在 2026 年 1 月 3 日过期。
  • NSX 3.x 页面可能只显示 Some error has occurred，后台才记录具体的 OVF 证书错误。
  • 临时处理方式是在现有 Manager 上关闭内部 OVF 校验，然后重新执行部署。

这些信息与本次的软件版本、界面提示、错误码和证书有效期对应。文章同时提供脚本和手工修改两种方式，我选择了只调整配置文件中的一个开关。

官方要求操作前有可用的 NSX 备份，并掌握备份凭据及加密口令。本次完整的 NSX 备份配置尚未完成，我选择先备份目标配置文件，再进行这项修改。这里的文件备份只能恢复该开关，不能替代 NSX 系统备份。

实际处理：将内部 OVF 校验开关从 0 改为 2

目标文件是 /config/vmware/auth/ovf_validation.properties。修改前读取到：

INTERNAL_OVFS_VALIDATION_FLAG=0

本次在现有 Manager 上执行了以下操作：确认原值、创建带 UTC 时间戳的备份、修改开关，再读回配置。下列命令按这次实际执行过程整理。

风险等级：CAUTION（持久、可恢复的配置修改）

执行对象： 现有 NSX Manager 的 root Bash，须先确认当前节点就是本次部署所在集群的 Manager。官方要求对集群中的每台现有 Manager 应用设置；本次只有一台运行中的节点。

影响： 将内部 OVF 校验开关设为 2，跳过相关证书和清单校验，并不更新过期证书。官方流程不要求重启 Manager 或服务，本次也没有重启。

前置条件与恢复： 官方要求可用的 NSX 备份；脚本另外创建目标文件备份，避免覆盖已有备份。若当前值不是唯一的一行 0，停止修改。需要撤销时，可按后文恢复开关。

完成验证： 读回值应为 2，文件对比应只出现这一项变化；重新部署后还需检查任务结果。

set -eu
config_file=/config/vmware/auth/ovf_validation.properties

if [ "$(grep -c '^INTERNAL_OVFS_VALIDATION_FLAG=0$' "$config_file")" != 1 ]; then
  echo 'Unexpected current flag; no change applied.'
  grep '^INTERNAL_OVFS_VALIDATION_FLAG=' "$config_file"
  exit 1
fi

backup_file="${config_file}.bak.$(date -u +%Y%m%dT%H%M%SZ)"
cp -p "$config_file" "$backup_file"
sed -i 's/^INTERNAL_OVFS_VALIDATION_FLAG=0$/INTERNAL_OVFS_VALIDATION_FLAG=2/' "$config_file"

echo "Backup: $backup_file"
grep -n '^INTERNAL_OVFS_VALIDATION_FLAG=' "$config_file"
stat -c '%A %U:%G %n' "$config_file" "$backup_file"
diff -u "$backup_file" "$config_file" || [ "$?" -eq 1 ]

cp -p 保留备份文件的权限与时间属性；sed 只匹配完整的目标配置行。diff 在发现差异时返回 1，最后一行允许这个预期结果，其他错误仍会使脚本失败。

本次实际创建的备份文件为：

/config/vmware/auth/ovf_validation.properties.bak.20260916T075016Z

读回结果与差异如下：

-INTERNAL_OVFS_VALIDATION_FLAG=0
+INTERNAL_OVFS_VALIDATION_FLAG=2
 THIRD_PARTY_OVFS_VALIDATION_FLAG=0

修改前后，目标文件和备份文件均为 root:root、权限 0644。第三方 OVF 校验开关没有变化。

重新尝试后，页面进入安装流程

配置修改完成后，我在页面重新尝试新增节点。这次没有立即返回原来的安装失败，页面出现进度条，显示“1% 正在安装”。

调整内部 OVF 校验开关后，新增 Manager 进入 1% 正在安装状态

这次测试确认，修改后部署已经能够继续进入安装流程。但截图中的“集群稳定”仍反映现有集群状态，不能据此认定新节点已经完成入群。

官方文档给出的另一项验证依据，是重新部署时日志出现以下内容。这是官方预期日志，并非本次已经采集到的日志：

Skipping ovf certificate/manifest validation for [<Manager-name>].

完整验收还需要等待新节点安装结束，确认节点为 UP，并检查集群整体状态为 STABLE。本文记录截止于安装流程恢复，没有将这一步写成整个扩容完成。

恢复开关与后续升级

这项修改会跨 Manager 重启保留。官方允许保留临时方案以避免重复遇到该问题，也提供了恢复校验的脚本。若希望恢复原来的校验行为，可以将值从 2 改回 0；原版本后续再次新增设备时，仍可能遇到同一证书错误。

风险等级：CAUTION（恢复校验配置，以下未在本次执行）

在需要撤销修改的 NSX Manager root Bash 中执行，先确认当前开关为 2，并保留本次文件备份。命令只恢复内部 OVF 校验开关，读回结果应为 0。不会续期部署包证书；如需再次使用临时方案，应重新核对官方文档及部署任务。

grep '^INTERNAL_OVFS_VALIDATION_FLAG=' /config/vmware/auth/ovf_validation.properties
sed -i 's/^INTERNAL_OVFS_VALIDATION_FLAG=2$/INTERNAL_OVFS_VALIDATION_FLAG=0/' \
  /config/vmware/auth/ovf_validation.properties
grep '^INTERNAL_OVFS_VALIDATION_FLAG=' /config/vmware/auth/ovf_validation.properties

长期处理仍是升级到修复该问题的版本。查询时，KB 424035 列出了 NSX 4.1.x、4.2.3.3 和 VCF NSX 9.0.2。这个列表不等于当前环境可直接跨版本升级，升级路径和 vCenter、ESXi 兼容性仍需单独核对。

同一篇 KB 对升级后的开关行为有两处不同表述：前面称设置在升级后保留，后面又称升级到修复版本时恢复为 0。因此升级后应读回配置确认，不把自动恢复当成已经验证的结果。新安装或重新部署的 Manager 也需要重新核对该设置。

这次排查最有用的证据是同一条部署链上的三处信息：页面的通用错误、后台的 CERTIFICATE_EXPIRED，以及部署包证书中一致的到期时间。找到失败阶段后，只修改一个配置项，就让新增节点从校验失败继续进入了安装流程。

参考资料

官方资料核对日期：2026 年 9 月 16 日。

NSX VMware 故障排查 证书