- Published on
NSX-T Certificate Replacement Process
- Authors
- Name
- Jackson Chen
OpenSSL
OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is also a general-purpose cryptography library.
Replace NSX-T VIP Certificate
Prerequisites
1. Verify that a certificate is available in the NSX Manager. See Import a Self-signed or CA-signed Certificate.
2. The server certificate must contain the Basic Constraints extension
basicConstraints = cA:FALSE.
.3 Verify that the certificate is valid by making the following API call:
GET https://<nsx-mgr>/api/v1/trust-management/certificates/<certificate-id>?action=validate
Procedure
1. From your browser, log in with admin privileges to an NSX Manager at https://<nsx-manager-ip-address>.
2. Select System > Certificates.
In the ID column, click the ID of the certificate you want to use and copy the certificate ID from the pop-up window.
Not: Make sure that when this certificate was imported,
the option "Service Certificate" was set to "No"
3. To replace the certificate of a manager node, use the API call.
POST /api/v1/node/services/http?action=apply_certificate\
Example:
POST https://<nsx-mgr>/api/v1/node/services/http?action=apply_certificate&certificate_id=e61c7537-3090-4149-b2b6-19915c20504f
Note: The certificate chain must be in the industry standard order of 'certificate - intermediate - root.'
- To replace the certificate of the manager cluster VIP, use the API call.
POST /api/v1/cluster/api-certificate?action=set_cluster_certificate
Example
POST https://<nsx-mgr>/api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=d60c6a07-6e59-4873-8edb-339bf75711ac
Note: The certificate chain must be in the industry standard order of 'certificate - intermediate - root.'
- This step is not necessary if you did not configure VIP. a. (Optional) To replace the Principal Identity certificates for NSX Federation, use the API call:
POST https://<nsx-mgr>/api/v1/trust-management/certificates?action=set_pi_certificate_for_federation.
For example:
POST https://<nsx-mgr>/api/v1/trust-management/certificates?action=set_pi_certificate_for_federation { "cert_id": "<id>", "service_type": "LOCAL_MANAGER" }
b. (Optional) If you currently have an NSX Intelligence appliance deployed with your NSX Manager cluster,
you must update the NSX Manager node IP, certificate, and thumbprint information that is on the NSX Intelligence appliance.
See VMware Knowledge Base article https://kb.vmware.com/s/article/78505 for more information
Reference Material
https://virtualination.com/NSX/replace-ssl-certificate-on-nsx-t-3-0
NSX-T Certificates Type
NSX-T uses multiple self-signed certificate for both External & Internal communication. The NSX Internal certificates are not exposed or replaceable by an user. The NSX-T External certificates are:
- NSX Manager Cluster / VIP certificate - used with the Cluster VIP, therefore it is being installed only once (as we have a single NSX-T Cluster).
- NSX Manager Node certificate - This certificate is used with individual Manager Node, hence it has to be installed on all 3 NSX-T Managers.
- NSX Federation PI (Principal Identity Cert) - This certificate is used between the NSX GM (Global manager) and NSX LM (Local manager).
- NSX APH-AR certificate - This one is used for inter-site communication when federation is enabled.
This post will focust to the replacement of the first two in the list: NSX Manager Cluster and Node certificate. I might write a new one in the future, to cover the Federation PI and APH-AR certs
Detail Process
- Create Certificate Signing Request (CSR) configuration file
NSX-T provides built-in interface to generate CSR, however it lacks the functionallity to add Subject Alternative Name (SAN) into the CSR. And since we want to use a single certificate that covers all the 3 NSX-T Manager nodes and the VIP address,
a. Create a CSR configure file (ssl.cfg) - Sample format
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Berkshire
localityName = Windsor
organizationName = Home Lab
organizationalUnitName = Couch Enterprise
commonName = nsxt.home.lab
[ req_ext ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = nsxt.home.lab
DNS.2 = nsxm01.home.lab
DNS.3 = nsxm02.home.lab
DNS.4 = nsxm03.home.lab
IP.1 = 192.168.1.100
IP.2 = 192.168.1.11
IP.3 = 192.168.1.12
IP.4 = 192.168.1.13
b. Another format of the CRS configure file (ssl.cfg) - Sample format
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:nsx.test.lab,DNS:nsx,DNS:node1.test.lab,DNS:node1,DNS:node2.test.lab,DNS:node2,DNS:node3.test.lab,DNS:node3
[ req_distinguished_name ]
countryName = AU
stateOrProvinceName = ACT
localityName = Canberra
0.organizationName = Testing Lab
organizationalUnitName = VMware
commonName = nsx.test.lab
c. Generate the CSR and the private key
$ openssl req -newkey rsa:2048 -sha256 -nodes -keyout nsxt.key -config ssl.conf -out nsxt.csr
May need to specify file path if files in different location
- Generate the certificate by submitting the CSR to your internal CA server.
The SSL request will need to be submitted to SSL certificate template the supports or defines
The standard "Client Server" templete only supports digital signature
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
Windows supports certreq command
certreq -submit -attrib "CertificateTemplate:VMwareTemplate" nsx.csr nsx.cer
# Certificate download format
Download the signed SSL certificate as "Based 64 encoded"
- Combine the certificate, issuing CA and root CA in a full certificate chain format file.
-----BEGIN CERT-----
Server certificate
-----END CERT------
-----BEGIN CERT-----
Intermediate issuing CA (if any)
-----END CERT------
-----BEGIN CERT-----
Root CA
-----END CERT------
Methods to combine the SSL certificate
a. Open each SSL certificate, and paste one after another in notepad++
b. cat nsx.cer > issuingca.cer > rootca.cer > nsxchain.cer # Linxux
c. copy nsx.cer + issuingca.cer + rootca.cer nsxchain.cer # Windows
- Snapshot the NSX Manager node
# Using PowerCLI
connect-VIServer <vCenter-fqdn> # Connect to vCenter
get-vm <nsx-node-name*>
get-vm <nsx-node-name*> | New-Snapshot -Name "Description, such as Before SSL upgrade"
Get-VM <nsx-node-name*> | Get-Snapshot # Verify backup
- Import the SSL certificate to NSX-T Manager Build up the full chain in notepad++ and once ready navigate to NSX-T UI --> System --> Certificates --> Import
a. Select NSX chain SSL certificate
b. Select the private key (generated in step 1)
c. Does no select or enable "Service Certificate" option
i. Turn Service Certificate on to use the certificate with Policy services such as Load Balancer and VPN
ii. Turn Seervice Certificate off to use teh certificate wiht NSX Manager appliance nodes
- Validate the imported certificate.
You should validate the certificate, to make sure it is ok before to replace the self signed one.
For that purpose we need to copy the certificate ID first.
The next step is to run the validation API call, while we are still logged as root to the first NSX-T Manager we can make the call using curl. Alternatively you can use REST API client of your choice like Insomnia, Postman, etc.
# SSH to NSX manager
curl -k -H 'X-NSX-Username:UC' -H 'X-Nsx-Groups:superusers' -X GET http://localhost:7440/nsxapi/api/v1/trust-management/certificates/cc1378a6-f953-4f69-ac31-d6f809a19938?action=validate
# API call
GET https://<nsx-vip-fqdn>/nsxapi/api/v1/trust-management/certificates/cc1378a6-f953-4f69-ac31-d6f809a19938?action=validate
Note:
Need return status as OK
- Replace the Node and the Cluster certificates.
For this step we am going to use Insomnia REST API client or Postman, to replace the node cert of each of the 3 NSX Managers individually. First we replace the VIP cert by running the bellow API Call:
POST https://nsxm01.home.lab/api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=cc1378a6-f953-4f69-ac31-d6f809a19938
Once done with the VIP, we have to run another 3 API Calls to replace each NSX-T Manager's certificate:
POST https://nsxm01.home.lab/api/v1/node/services/http?action=apply_certificate&certificate_id=cc1378a6-f953-4f69-ac31-d6f809a19938
POST https://nsxm02.home.lab/api/v1/node/services/http?action=apply_certificate&certificate_id=cc1378a6-f953-4f69-ac31-d6f809a19938
POST https://nsxm03.home.lab/api/v1/node/services/http?action=apply_certificate&certificate_id=cc1378a6-f953-4f69-ac31-d6f809a19938
How to access NSX node locally
When NSX login is integrated with IDM, we can only login to NSX manager using the specified entry defined in IDM
https://<vIDM-specified> # Such as https://nsx.test.lab
In order to access individual node, we need to login locally
http://virtualbrigade.com/vmware-identity-manager-is-not-accessible/
https://<node-name-fqdn>/login.jsp?local=true