/vCloud Director v10.3 vs NSX-T error Certificate is already trusted

vCloud Director v10.3 vs NSX-T error Certificate is already trusted

In this blog post about vCloud Director v10.3 vs NSX-T error Certificate is already trusted, I talk about an issue that is new when you install a new vCloud Director v10.3, or you upgrade your existing vCD to v10.3.

In a new vCD install, when you try to add your NSX-T (or V), you will get this error: “Certificate xxxx is already trusted.”

vCloud Director v10.3 vs NSX-T error Certificate is already trusted

You can try to use IP or FQND name, and it is the same. Even this is a new installation and no NSX-T was added, you always get this error.

Suppose you upgrade your vCloud Director to version v10.3 and trying to deploy a new vApp, VM, or Network that uses NSX-T. In that case, you also get the same type of error, but now with a different message: “Certificate for <NSX-IP> doesn’t match any of the subject alternative names.”

vCloud Director v10.3 vs NSX-T error Certificate is already trusted

This happens now in vCloud Director v10.3 because before v10.3 we could disable hostname verification for NSX-T, vCenter, and vSphere. But in the new v10.3 version, this option is only for vCenter and vSphere. So when we have an NSX-T added to our vCloud Director, or tying to add and have the URL:https://FQDN different from the common name that we have in the certificate, we get this type of error.

Because now vCloud Director will verify if the names match. If not, it will not be accepted. From what I read, this is now a security measure in the vCloud Director vs NSX-T(V).

Since the above examples are from production and need to blur the names/IPS, let us see some certificates examples in my homelab.

My certificate is correctly set in the following example since it has the complete FQDN from my NSX-T.

vCloud Director v10.3 vs NSX-T error Certificate is already trusted

But if I have a certificate like the next one, we get the error.

If we add the NSX-T to vCloud Director using the second example, we get the error in the above examples.

It is easy to fix if you have only the NSX-T name in your certificate and not FQDN. Just add only the name of the DNS record to add your NSX-T to vCD, for example, https://NSX-T-vCD. This should fix the issue, and now you can add your NSX-T to vCD v10.3.

If this is not a new install and you already have a vCD that you upgraded, using your NSX-T with networks linked(remove NSX-T and add again is not an option), you need to edit the connection and change the name.

Trying to delete existing NSX-T to add one with a proper name:

Next, edit the existing NSX-T connection and change the name.

Note: You need to click on the NSX-T manager name(option 3) so that you have the option to edit the connection.

Then change the name for the common name you have on your certificate.

In this case, I had an extra issue. The NSX-T FQDN was nsx-manager1.domain.com, but the common name was nsx-manager, which doesn’t exist in the DNS.

If you have a certificate with a different name, I had this example in a vCD that I upgraded to v10.3(second initial error image above), not a new install, and then you cant add the FQDN or DNS name. It will not work. If you have two options here, create new certificates and use proper names, or create an alias in the DNS record for that NSX-T.

You get the following error if you try to add a name that doesn’t exist in the DNS.

 

My option for this error, and the easiest, was to create an alias with that name in the NSX-T DNS record. After NSX-T was updated, and all was working fine.

Important note:

The above examples are for NSX-T, but if you are still using NSX-V, you will get the same “Certificate xxxx is already trusted.” In that case, follow the same steps but in this case for the NSX-V connection.

Also very important to mention that in the vCloud Director v10.3, SSL connections have also changed, so if you are using LDAP for the organizations/tenants, you will get some errors like this:

Found one or more organizations with an LDAP configuration that bypasses SSL certificate verification.
This version of VMware Cloud Director cannot support such configurations. Ensure that each of the above organizations reconfigures
their LDAP settings to import the certificate of their LDAP server, if necessary, and turns off “Accept All SSL Certificates”.

We need to Accept all certificates to disabled the option to verify. This error is discussed here in the VMware KB85199.

We had this issue also in our environment, but I did not save any of the fixes I did by following VMware knowledgebase. To fix this, we need to do a lot of steps and changes(particularly in the vCD PostgreSQL DB) I will not include here in this vCloud Director v10.3 vs NSX-T error Certificate is already trusted blog post.

I will try to trigger this in my homelab, save all the steps, and write a blog post when I have the time.

Final Notes:

With the new vCloud Director v10.3, we now need to consider that certificates must have a proper common name that matches our server’s name. In this case, it is only for NSX-T/V, but I am sure this will be a common standard in the future, and certificates common names matching hostnames will be needed for all(vCenter, vSphere, etc.).

I hope this blog post vCloud Director v10.3 vs NSX-T error Certificate is already trusted will help you bypass these errors with NSX/V certificates in your vCloud Director infrastructure when using v10.3.

Share this article if you think it is worth sharing. If you have any questions or comments, comment here, or contact me on Twitter.

©2021 ProVirtualzone. All Rights Reserved
By | 2021-10-02T18:43:12+02:00 October 2nd, 2021|NSX, vCloud Director, VMware Posts|0 Comments

About the Author:

I have over 20 years of experience in the IT industry. I have been working with Virtualization for more than 15 years (mainly VMware). I recently obtained certifications, including VCP DCV 2022, VCAP DCV Design 2023, and VCP Cloud 2023. Additionally, I have VCP6.5-DCV, VMware vSAN Specialist, vExpert vSAN, vExpert NSX, vExpert Cloud Provider for the last two years, and vExpert for the last 7 years and a old MCP. My specialties are Virtualization, Storage, and Virtual Backup. I am a Solutions Architect in the area VMware, Cloud and Backup / Storage. I am employed by ITQ, a VMware partner as a Senior Consultant. I am also a blogger and owner of the blog ProVirtualzone.com and recently book author.

Leave A Comment