After upgrading my home lab recently to vSphere 6.5, I also updated some of the related utilities such as the various SDKs and CLIs. One of the CLIs that I had updated was the latest version of OVFTool which is now at 4.2. I use OVFTool extensively to automate various Virtual Machine deployments (import/export). While testing out a new OVA that I had been working on, I needed to verify that it also worked with previous release of vSphere like vSphere 6.0 Update 2. I happen to have the vSphere C# Client open and connected to a vCenter Server and when I tried to import the newly created OVA, but it failed with the following error message:
The following manifest file entry(line1) is invalid: SHA256
I was pretty surprised by this since I went through this exact same workflow a couple of days ago without any problems. The only change that had happened was OVFTool and error seems to indicate an issue with the hashing algorithm. I ran OVFTool again using just the --help option to check what the default SHA hashing algorithm was, it was SHA256. I then compared that to an older version of OVFTool and it looks like the default had changed from SHA1 to SHA256.
From a security standpoint, this is a positive change as SHA1 is no longer considered a secure hashing algorithm and a stronger version should be used. It also turns out that the vSphere C# Client can only support SHA1 which is why I received the error after upgrading to the new version of OVFTool. Luckily, this is NOT a problem when using the vSphere Web Client or the vSphere HTML5 Client and only affects the vSphere C# Client. If you do need to use the vSphere C# Client for importing OVF/OVAs exported from the latest version of OVFTool, the workaround is quite simple, just override the default hashing algorithim when exporting by adding the additional CLI option:
--shaAlgorithm=sha1
Ionuţ-Dan Nica says
Oh how I wish export-vapp would have a -shaalgoritm parameter
William Lam says
Thanks for the feedback, I'll be sure to share this with the PowerCLI PM as I agree, that would be a useful feature to include since OVFTool has offered this for some time.
Jon Hemming says
Curious .... is SHA1 completely disabled in the vSphere 6.5 web client (either or)?
From a packaging standpoint, it might be good for vendors to package an OVA/OVF under SHA1 and SHA256 for those who want to use specific clients/interfaces.
Prabhu says
is there any wat to have SHA1 and SAH256 signature value in .mf file?
Jon Hemming says
Not that I'm aware of. The manifest is really just like a checksum file and has a single checksum per file.
mdiehn says
For all us Linux-only admins out here, for whom the WebUI can't have the plugins that allow OVF deployment to work, I offer this, which worked for me:
1. Use tar to unpack the ova.
2. Use sha1sum to calculate the sha1 checksums for the files listed in the .mf file ...
3. ... and replace the lines in the .mf with ones using the sha1sums you calculated.
Saleem says
Thanks for the article.
I have an ova generated with vCenter 5.5
Now I could not deploy it with vCenter web client 6.5 version with Checksum error.
"The checksum from the provided manifest files not match the content of the file(s) my.ovf"
Manish says
Hi William,
Seems like you use ovftool significantly. I have this small problem with the tool.
When I run the ovftool --help config I expect it to print the help contents & along with that the local configuration should be read & printed. But it always says no local configuration found. I have the .ovftool file created in my current directory. Any idea what could be the problem...?
Jeremy says
Thank you, very helpful!
Stuart Bolton says
I ran into this while attempting to transfer an OVF from a 6.5 web-client environment to a 5.5 thick-client environment. All I had to do was rename/delete the old .mf manifest file, and then recreate it by running:
openssl sha1 myvmname-1.vmdk myvmname.ovf > myvmname.mf
Aleks says
Thanks man, it helped me 🙂