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.
DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.