Skip to main content

During my NSX-T 3.0 lab build from scratch I wanted to understand how to use a custom certificate for the NSX-T Manager Nodes and also for the VIP of the Managers.
So I searching around in order to understand which step is needed to configure it as I wanted.
I found a great blog that explains everything I needed to understand the process and also some common errors you can face during this procedure.
If you are interested in the detailed procedures you can go directly to the raccoon blog here
GUI install:

If you get some error I suggest you to look also the interesting article also from the vraccoon blog:

The article above will help you to understand if you have some configuration you need to change in order to apply your custom certificates without any problems

In my case, my home lab is just a single node configuration, enough for a home lab purpose but for sure not recommended for Production Environment. I basically did the standard installation with via OVF deploy in my vCenter.

Then in order to apply a new custom certificate, I will need first to login to the NSX-Manager UI and create the CSR in the Certificates utility available on the System section. After that I will be able to download the CSR and use it to have a new certificate signed by my enterprise CA.
After that, I’ll use the import certificate option in the CSRs section of the NSX Manager, remember that the certificate you should import must have the full certification chain, for example:

NSX Certificate
CA Certificate

If you have a subordinate CA:

NSX Certificate
Subordinate CA Certificate
CA Certificate

After that, I can submit the API command via the Postman app in order to change the certificate to my NSX-T Manager Node:


“https://<nsx-mgr or vip>/api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=”

As you can see there is an ERROR above that basically block my API request. The issue is the validation of my certificate, as stated on the following KB:
In my case, my choice is to disable the CRL check on the manager via a specific API command:

GET    https://nsx-manager-fwdn/api/v1/global-configs/SecurityGlobalConfig

with it you will get something similar to this:

  “crl_checking_enabled”: true,
  “ca_signed_only”: false,
  “resource_type”: “SecurityGlobalConfig”,
  “id”: “b978f747-cbbc-4cc7-ae21-b1dd894d84a8”,
  “display_name”: “b978f747-cbbc-4cc7-ae21-b1dd894d84a8”,
  “_create_user”: “system”,
  “_create_time”: 1592323067507,
  “_last_modified_user”: “system”,
  “_last_modified_time”: 1592323067528,
  “_system_owned”: false,
  “_protection”: “NOT_PROTECTED”,
  “_revision”: 2

You will the previous output for disabling the “crl_checking_enabled” parameter using the previous command but with some additional configuration on postman:

PUT    https://nsx-manager-fwdn/api/v1/global-configs/SecurityGlobalConfig
copy on the Body section of your API call the output you get with the previous command and change only the first line from:
“crl_cheking_enabled”: true,
“crl_cheking_enabled”: false,

As you can see I still get an error because the API Call is not able to recognize the Content of my call.
In order to let the command going ahead I need to configure on the Headers section of postman with the following parameter:

Key = Content-Type   Value = application/json 

You can see this configuration on the image below

After that I can re-run the previous command and disable the crl_checking, you can verifying it also with the GET command I used at the beginning to get the SecurityGlobalConfing output.

Then I try again to apply the certificate to the manager and voilà! no error, check the following image

I can now reload the NSX-Manager UI and see the new certificate is in place.

That’s all, I hope this will be informative, if you have any question just drop a comment.

Leave a Reply

Giovanni Dominoni's Tech Blog