NSX Issues After Replacing VMware Self-Signed Certs

NSX Issues After Replacing VMware Self-Signed Certs

Recently, I’ve been going through and updating my lab so that I’m all up to date with the latest technology. As part of this process, I’ve updated my certificates so that all of my URLs have the nice trusted green logo on them. Oh yeah, and because it’s more secure.

I updated my vSphere lab to version 6.5 and moved to the vCenter Server Appliance (VCSA) as part of my updates. However, after I replaced the default self-signed certificates I had a few new problems. Specifically, after the update, NSX wouldn’t connect to the lookup service. This is particularly annoying because as I found out later, if I’d have just left my self-signed certificates in tact, I would never have had to deal with this. I thought that I was doing the right thing for security, but VMware made it more painful for me to do the right thing. I’m hoping this gets more focus soon from VMware.

When I tried to connect my NSX Manager to my vCenter I’d get an error stating that the certificate change was not verified, like the following:

It turns out that NSX won’t connect because it’s getting the wrong fingerprint back from vCenter. The following KB article covers how to fix this. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2132645

My steps to fix it

While the KB article does an adequate job of describing the fix, hopefully my screenshots will help add some additional color if you’re trying to go through the same thing. The first thing you want to do is go to your PSC’s managed object browser to find the old fingerprint. To do this go to https://PSCADDRESS/lookupservice/mob?moid=ServiceRegistration&method=List in a web browser.

Once you’ve logged in, you’ll want to modify the information in the “Value” box so that it only contains the filterCriteria tags like the screenshot below. When you’ve removed the other tag information in that window click “Invoke Method”


After you’ve done this, to a find on that page for “sts/STS”. You’ll find this string in a URL down on the page. When you find this, copy the sslTrust value from the line preceding this sts/STS string you searched for. It’ll look like a long string of garbled text. Copy this text.

Open up a text editor and paste this string into the file and save it as sts.cer someplace safe.

Now open the sts.cer file with certmgr.exe on a windows machine or similar program. Find the fingerprint by going to the details tab and looking for the “Thumbprint” attributes. Copy the thumbprint value into your clipboard.

Open a new txt file and paste the string into the text editor. Remove all of the spaces that may be present so that it’s a single string with no spaces in it. Save the file as old.fprint.txt.

Now, ssh into your PSC and change the directory and create a new directory named “certs” in the root folder. After that we need to run the command:

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert –store MACHINE_SSL_CERT –alias __MACHINE_CERT –output /certs/new_sts.crt

Now we can update our thumbprints on the existing certificates. Run the command:

pythong /usr/lib/vmidentity/tools/scripts/ls_update_certs.py –url VCENTERLOOKUPURL –fingerprint FINGERPRINTFROM_OLD.FPRINT.TXT –certfile /certs/new_sts.crt –user [email protected] –password YOURPASSWORD

When you execute this command, it may take a bit but it will run for a while returning data. When complete you can try to connect your NSX manager again.


Once I ran through the steps, I was able to successfully connect NSX to my lookup service again.


I hope that if you’ve reached this page, you’ll be able to find the answer to your question about connecting NSX to vCenter. And more importantly, hopefully VMware will fix this issue so that replacing your certificates won’t cause further issues in your environment.



One Response to NSX Issues After Replacing VMware Self-Signed Certs

  1. Ahhh … the custom-signed certificates in Vsphere environments <3

    With my experience it looks like for each next release the process and complexity of replacing those Self signed ones gets harder and harder… and theres literally no documentation for that. Vmware covers VMCA stuff mostly, which in some scenarios are no options so you are left with going to replace all of the trusted roots, machine, and solution users on your own.

    It might be easy if ones using embedded deplyoment … but what about complex infrastructures ? several VCSA … several PSC?

    It really annoys me as playing with certs and trusts might cripple your environment and its best to do before any logical configuration taking place on the Vsphere itself … I`m feeling sorry for the poor admins which have to do it on production as small mistake may test the quality and validity of your backup … Which is another thing for embedded VCSA DB 😉

Leave a reply