In a previous post called Managing VMware NSX Edge and Manager Certificates, we looked into NSX Edge self-signed certificates, certificates signed by a Certification Authority (CA), and certificates generated and signed by a CA and how to use them in NSX. We briefly mentioned a functionality called Global certificates as well.

NSX Global Certificate basically is a certificate signed by your Certificate Authority (CA) and this certificate is imported at a NSX “global level”. By being at a global level, it is available to all NSX Edges in your inventory. Unfortunately, neither the NSX Manager User interface (UI) nor the NSX tab of the vSphere Web client UI expose options to administer these global certificates. In order to create global certificate, import it into NSX Manager, and use it in SSL VPN or an Application Profile, you must create it via API call.

In this article, we will look how to create and use VMware NSX Manager Global Certificates.


What does this mean?


Go into your NSX Manager and navigate to Edges > <any_edge> > Manage > SSL VPN Plus > Server Settings  and click Edit.



On every new edge you will see exactly the same certificates.



These are all global certificates and available by default on every edge.

Note: You do not have an option to import or create your own global certificate.

So let’s assume you have your own, company signed certificate that you want to import in the list.

You can do this by navigating to Settings > Certificates



Use Case


Let’s look into an use case where importing the certificate manually is not possible/desired and we have to find another way by using global certificates.

The company has the following use:

  • The company is using vRealize Automation (vRA) to deploy applications via multi-machine blueprints (MBP).
  • As part of your MPB blueprint the company has an NSX ON-Demand Load Balancer being created with every blueprint instance/deployment.
  • The company wants to have NSX SSL VPN Plus configured on all Load Balancer Edges .
  • The company wants to use its own company signed certificate for the NSX SSL VPN on each edge.

This would basically mean that if 100 instances of your vRA application get deployed, 100 edges will need manual NSX SSL VPN Certificate configuration.

Let’s see what we can do to find a solution to the company’s problem.




To resolve the company’s problem we will do the following:

  • Use NSX Global Certificates.
  • Import our company signed SSL Certificate into NSX and mark it as global certificate. Afterwards all edges have that certificate available for selection during NSX SSL VPN Plus configuration
  • Automate the configuration of the NSX SSL VPN Plus so that its configured during VPN provisioning time.

Let’s first take a look again at the NSX SSL VPN Plus configuration.

If we select Use Default Certificate, the edge will use the default NSX Edge appliance certificate. This means during or after our VM provisioning, when we enable the NSX SSL VPN Plus, we will need to change the default certificate.  




For this example, the company has created a wildcard certificate that will be imported in NSX as a global certificate and used for NSX SSL VPN Plus configuration. We are using wildcard one as during blueprint provisioning time so edges will get randomly generated names and IPs form our DHCP system.



First we need to combine in a file our primary certificate and all certificates in the certificate chain. I’m using a 2-Tier CA : RootCA and SubCA (issuing CA)

Your chain will generally look like this:

(Your Primary SSL certificate: your_domain_name.crt)
(Your Issuing certificate: IssuingCA.crt)
(Your Intermediate certificate: IntermediateCA.crt)
(Your Root certificate: Root.crt)

In another file, save the certificate private key:

(Your Primary SSL certificate private key: rui.key)

We will be using the following REST call to import the certificate as Global Certificate in NSX:

URI Parameters:

Scope ID: scopeId (required)

Description: Create a single certificate

Body: application/xml

We need to modify the body to fit the primary certificate, the primary certificate private key and a pass phrase.

For {scopeId} we will use globalroot-0 which means Global Certificate.

So let’s run the REST command to import the certificate.



Your response should look similar to the following:

Note the objectID as we will need this shortly.

Let’s go back into the NSX Edge configuration and check again the NSX SSL VPN Plus server settings:



Notice that this time you can immediately see our company certificate. From now on, as this is now a NSX Global Certificate, it will be available to all edges by default.

So we are half there. All edges deployed via vRA blueprint will have the certificate available.


Now let’s look into a REST call to configure NSX SSL VPN Plus:

For this example, we will be using one existing edge.



We need to get the edge-id of that edge via the following REST call.



Please note the edge <id> as we will need this. In this example the edge Id is edge-4. 


Now let’s again use REST to enable NSX SSL VPN configuration and select the appropriate certificate we want to use.

We will be using the following REST command:

URI Parameters:

Specify the ID of the edge in edgeId edgeId (required)

Description: Apply server settings

Body: application/xml

You will need the edge id, the IP of the edge, the certificate ID which you noted before and the algorithm you want to use, e.g:


Now let’s run the call:


You can validate the change by doing a REST like this:

Or go to the manager and validate that the NSX SSL VPN Plus is now configured and using the company approved certificate and algorithm.



Now you can easily take those rest calls and hook to the vRA Blueprint deployment using vRA Event Broker. Then use vRO to run the REST calls and make the appropriate changes to all newly deployed NSX On-Demand Load Balancers (edges).


Spas Kaloferov is an acting Staff Solutions Architect member of Livefire Solutions & Services (LSS) for the Software-Defined Datacenter (SDDC) – a part of the Global Field & Partner Readiness (GFPR) team. Prior to VMware, Spas focused on cloud computing solutions.