SigningVMWareVM

Signing a VMWare Virtual Machine

Yes, you can absolutely sign a VMware VM, and ironically, the exact method you used in your blog post to trick VirtualBox into accepting a signed appliance is actually VMware's official, native standard for signing VMs.

Because the .ova (Open Virtual Appliance) format is inherently a tar archive containing an OVF descriptor (.ovf), disk images (.vmdk), and a manifest file (.mf), the process for VMware relies completely on the same VMware OVF Tool (ovftool.exe) and a PEM-formatted certificate that you previously set up.

Since you already have OpenSSL and your .pem key ready to go, here is how you sign it natively for VMware, along with how to fix the timestamp and manifest warnings you ran into last time:

The Native VMware Signing Command

To sign your exported appliance properly, use the exact syntax from your workflow, but add the --shaAlgorithm flag explicitly set to SHA256. Most modern hypervisors (including VMware Workstation/vSphere) will flag or reject SHA1 as cryptographically broken. [1]

bash

ovftool --privateKey=MyCert.pem --shaAlgorithm=SHA256 source_vm.ova signed_vm.ova

Use code with caution.

1. Fixing the "No supported manifest entry found" Warning

In your VirtualBox blog post, you noted an annoying warning regarding the .vmdk disk file. [1]

text

Warning: No supported manifest(sha1, sha256, sha512) entry found for: 'filename-disk001.vmdk'

Use code with caution.

This happens because VirtualBox's built-in exporter frequently creates a dirty or incomplete manifest (.mf) file that doesn't map hashes in a way the OVF standard expects.

• The Fix: If you export the base VM directly from VMware Workstation (instead of VirtualBox), its OVF/OVA exporter writes a mathematically clean, natively mapped manifest file automatically. Running ovftool against a VMware-exported OVA will completely eliminate this warning.

2. Solving the Cryptographic Timestamp Problem

You correctly identified a major flaw in basic OVF signing: by default, ovftool simply signs the file locally using your key. When your Sectigo certificate expires, the VM will show up as untrusted. [1, 2]

To fix this, you must pass your Sectigo/Comodo RFC 3161-compliant Timestamp Authority (TSA) URL directly into the ovftool command using the --tsa flag. This injects a cryptographically verified time token into the OVF signature, ensuring the VM remains trusted forever as long as it was signed while the certificate was valid.

Add the --tsa parameter to your command:

bash

ovftool --privateKey=MyCert.pem --shaAlgorithm=SHA256 --tsa=http://sectigo.com source_vm.ova signed_vm.ova

Use code with caution.

What Happens Upon Import

When an end-user imports this signed_vm.ova into VMware Workstation or vSphere:

1. The hypervisor intercepts the package and checks the embedded .cert file against the OS trusted root store.
2. It will display a clear "Publisher: Validated/Trusted" banner along with your certificate details.
3. If anyone tampers with a single byte of the underlying BSD disk or OVF configuration file, the manifest hash verification will break instantly, and VMware will refuse to boot or import the machine, protecting your "known good" release.

Are you planning to export the base VM out of VirtualBox again, or are you building the master image directly in VMware/KVM this time? I can help you clean up the export settings based on your choice.