Managing NSX Manager Global Certificates (SKKB1040)

It's only fair to share...Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Digg thisPin on PinterestShare on TumblrPrint this pageEmail this to someone

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

 

Update Log:

Lab Environment

The full lab logical design can be seen HERE.

Introduction

 

In a previous post called Managing NSX Edge and Manager Certificates (SKKB1012) 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) or 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, use it in SSL VPN or an Application Profile you must create it via API call.

What does this mean ?

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

On every newly 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 lets’ assume you have your onw, company signed certificate that you want to import in the list.
You can do this my navigating to Settings > Certificates

Use Case

Lets 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 Kaloferov.com 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.
  • Company wants to have NSX SSL VPN Plus configured on all Load Balancer Edge .
  • Company wants to use it’s own company signed certificate for the NSX SSL VPN on each edge.

This would basically mean that if a 100 instances of your vRA application gets deployed, a 100 edges will  need manual NSX SSL VPN Certificate configuration.
Lets see what we can do to find a solution to the company’s problem.

Solution

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
-Will automate the configuration of the NSX SSL VPN Plus so that its configured during VPN provisioning time.

Lets’ first take a look again at the NSX SSL VPN Plus configuration.
If we select Use Default Certificate, the edge will sue 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 Kaloferov.com company has created a wildcard certificate that will be imported in NSX as global certificate and sued for NSX SSL VPN Plus configuration. We are suing wildcard one as during blueprint provisioning time edges will get randomly generated names and IP’s 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
—–BEGIN CERTIFICATE—–
(Your Primary SSL certificate: your_domain_name.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Your Issuing certificate: IssuingCA.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Your Intermediate certificate: IntermediateCA.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Your Root certificate: Root.crt)
—–END CERTIFICATE—–

In another file save the certificate private key

—–BEGIN RSA PRIVATE KEY—–
(Your Primary SSL certificate private key: rui.key)
—–BEGIN RSA PRIVATE KEY—–

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

POST /2.0/services/truststore/certificate/{scopeId}
URI Parameters:
Scope ID: scopeId (required)
Description: Create a single certificate
Body: application/xml
<trustObject>
<pemEncoding></pemEncoding>
<privateKey></privateKey>
<passphrase></passphrase>
</trustObject>

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 lets run the REST command to import the certificate

<trustObject>
<pemEncoding>—–BEGIN CERTIFICATE—–
MIIFqzCCBJOgAwIBAgITTgAAABYPfrdeqI59IQAAAAAAFjANBgkqhkiG9w0BAQ0F

—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIIFHDCCBASgAwIBAgITOQAAAANJ4ceGS2aFAQAAAAAAAzANBgkqhkiG9w0BAQ0F

—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIIDbzCCAlegAwIBAgIQfAU1N8UTV7FFx7c4idTeeDANBgkqhkiG9w0BAQ0FADA+

/Kk2GYfG8A8OlNOsPt0PIXTXXw==
—–END CERTIFICATE—–
</pemEncoding>
<privateKey>—–BEGIN RSA PRIVATE KEY—–
MIIEpQIBAAKCAQEA8RLznOMYo+MAz1FPVoak6vgDhBeWL9v0Q1mFkPjsGNTgOQzh

—–END RSA PRIVATE KEY—–
</privateKey>
<passphrase>VMware1!</passphrase>
</trustObject>

Your response should look similar to the following

    <certificate>
<objectId>certificate-15</objectId>
<objectTypeName>Certificate</objectTypeName>
<vsmUuid>564D3BEB-645D-739A-3FE6-9664773E87F4</vsmUuid>
<nodeId>ac991e3f-2a44-4f48-8e54-073ffdaeb301</nodeId>
<revision>0</revision>
<type>
<typeName>Certificate</typeName>
</type>
<name>vmware.com</name>
<scope>
<id>globalroot-0</id>
<objectTypeName>GlobalRoot</objectTypeName>
<name>Global</name>
</scope>
<clientHandle></clientHandle>
<extendedAttributes/>
<isUniversal>false</isUniversal>
<universalRevision>0</universalRevision>
<subjectCn>vmware.com</subjectCn>
<issuerCn>SubCA</issuerCn>
<pemEncoding>

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 vmware.com 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
GET /4.0/edges


<edgeSummary>
<objectId>edge-4</objectId>
<objectTypeName>Edge</objectTypeName>
<vsmUuid>564D3BEB-645D-739A-3FE6-9664773E87F4</vsmUuid>
<nodeId>ac991e3f-2a44-4f48-8e54-073ffdaeb301</nodeId>
<revision>25</revision>
<type>
<typeName>Edge</typeName>
</type>
<name>Perimeter-Gateway</name>
<clientHandle></clientHandle>
<extendedAttributes/>
<isUniversal>false</isUniversal>
<universalRevision>0</universalRevision>
<id>edge-4</id>
<state>deployed</state>
<edgeType>gatewayServices</edgeType>
<datacenterMoid>datacenter-21</datacenterMoid>
<datacenterName>DatacenterA</datacenterName>
<tenantId>default</tenantId>
<apiVersion>4.0</apiVersion>
<recentJobInfo>

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:

PUT /4.0/edges/{edgeId}/sslvpn/config/server
URI Parameters:
Specify the ID of the edge in edgeId edgeId (required)
Description: Apply server settings
Body: application/xml
<serverSettings>
<serverAddresses>
<ipAddress></ipAddress>
</serverAddresses>
<port></port>
<certificateId></certificateId>
<sslVersionList>
<version></version>
</sslVersionList>
</serverSettings>

 

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

<serverSettings>
<serverAddresses>
<ipAddress>192.168.1.10</ipAddress>
</serverAddresses>
<port>443</port>
<certificateId>certificate-15</certificateId>
<cipherList>
<cipher>AES256-SHA</cipher>
</cipherList>
<sslVersionList/>
</serverSettings>

Now lest run the call

You can validate the change by doing a REST like this:
GET /4.0/edges/edge-4/sslvpn/config/server

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)

 

Final Step

If all went well, go grab a beer.

It's only fair to share...Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Digg thisPin on PinterestShare on TumblrPrint this pageEmail this to someone

Leave a Reply

Your email address will not be published. Required fields are marked *