An OVF/OVA can be digitally signed by a vendor to ensure its authenticity and when importing it into vCenter Server, the vSphere UI will either display that it contains a valid certificate or the certificate is not trusted as demonstrated in the example below:
If you are using a self-signed TLS certificate to sign an OVF/OVA, then it is expected that it would not be trusted by the Root Certificate Authority (CA) stored within the vCenter Server Appliance (VCSA).
However, if you have a valid TLS certificate that has been issued from a trusted certificate authority to sign an OVF/OVA, would you still see the error message? The answer actually surprised me.
It turns out that you may still see this error message even with a valid TLS certificate. The reason for this is that unlike a web browser, which trusts a large number of Root CAs including free and community solutions, the VCSA contains a more restrictive list of Root CAs that it automatically trusts by default.
With this updated information, I was able to confirm this behavior myself by requesting a certificate for a DNS domain that I owned (virtuallyGhetto.com) which was issued by ZeroSSL.
Note: I actually had attempted to use LetsEncrypt, but the certificate it issued was not compatible with OVF/OVA signing and I ran into other issues that I was not able to figure out.
Per the OVTool documentation for signing an OVF/OVA, I concatenated the private/public key and then successfully signed an OVA and attempted to import that into vCenter Server and per the screenshot above, it displayed The certificate is not trusted warning.
To debug this issue, the easiest way is to download the hyperlinked certificate from the vSphere UI and transfer that to the VCSA. In my example, the certificate is called ZeroSSL RSA Domain Secure Site CA.cer and we can then use openssl utility to perform a verification of the certificate to see if it is trusted by running the following command:
openssl verify 'ZeroSSL RSA Domain Secure Site CA.cer'
As expected, this certificate failed to validate against the default Root CA that is stored within the VCSA.
We can also confirm that if we provided the trusted Root CA for the issued certificate, it should now pass verification by running the following openssl command and passing in the Root CA file (which ZeroSSL also provides as part of the download):
openssl verify -CAfile zerossl_root_ca.crt 'ZeroSSL RSA Domain Secure Site CA.cer'
Now that we understand the issue, to fix this problem, we simply need to import this additional Root CA certificate into the VCSA which can be done using the vSphere UI by navigating to Administration->Certificates->Certificate Management and click on the Add button in the Trusted Root Certificate section.
Note: If you wish to remove an imported Root CA, you will need to use the vSphere (REST) Certificate Management API which can easily be performed by using the built-in Developer Center API Explorer within the vSphere UI.
If we now attempt to import our signed OVF/OVA, we can see that the certificate is now trusted using the additional Root CA certificate and we no longer see the error message as we did earlier.
For most 3rd party OVF/OVA which are signed by larger Enterprise CAs, you will likely never see this problem but if you are using a CA that is not trusted by default, then this additional step maybe required to import a specific OVF/OVA from your vendor.
As of vCenter Server 8.0 Update 1, there is ~148 CA that is trusted by default within VCSA, you can find this by simply running the following command within VCSA:
grep 'Issuer:' /etc/pki/tls/certs/ca-bundle.crt
It's great to see you posting recently, William