I was attempting to delete a certificate in NSX Manager that I’m sure I had already replaced with a new one and not used at all. The strange thing was that the certificate was showing used by “2”, so I started investigating.
The first thing to do is to double check the state of this certificate via Postman and API calls with this:
GET https://nsx-fqdn.com/api/v1/trust-management/certificates/<cert-id>
You can find the cert id on the UI on the certificate entry.
The important information to look on the api respose are the following:
“used_by”: [
{
“node_id”: “97361e42-fdca-503e-1208-fe9ae5fc201f”,
“service_types”: [
“API”
]
},
{
“node_id”: “03192973-4ec6-4c07-a6ca-4155ec4c8be1”,
“service_types”: [
“API”
]
So I double checked the node id just to be extremely sure this certificate is not used by anyone in NSX with:
GET https://nsx-fqdn.internal.unicreditgroup.eu/api/v1/cluster/nodes/node-id
The result for both ids was:
“httpStatus”: “NOT_FOUND”,
“error_code”: 600,
“module_name”: “common-services”,
“error_message”: “The requested object : ClusterNodeConfigModel is null for 97361e42-fdca-503e-1208-fe9ae5fc201f. could not be found. Object identifiers are case sensitive.”
I got then into a call with the Support and I found that seems the only way to remove it is to log in via root account to one of the NSX manager and launch locally the api command:
curl -k -X POST -H "Content-Type: application/json" -H 'X-NSX-Username:admin' -H 'X-NSX-Groups:superuser' -d '{"service_type":"API","node_id":"c1862a42-f52e-af01-f090-ed6482cad394"}' "http://localhost:7440/nsxapi/api/v1/trust-management/certificates/21fd7e8a-3a2e-4938-9dc7-5f3eccd791e7?action=release"On the API call above remember to change the node_id and the certificate id that you got from the first api call response.
If you done correctly you will se the that usage of the certificate will be remove, of course if you have multiple entries just check the node ids present on the UI or in the result of the first call. (GET https://nsx-fqdn/api/v1/trust-management/certificates/<cert-id>)
Thanks to the Broadcom / VMware support that helped me finding this solution via dedicated zoom call. The KB related to this issue is the following one: https://knowledge.broadcom.com/external/article?legacyId=75277
