Using OpenSSL to update NSX-V Certificates to accommodate hostname verification
search cancel

Using OpenSSL to update NSX-V Certificates to accommodate hostname verification

book

Article ID: 312306

calendar_today

Updated On:

Products

VMware Cloud Director

Issue/Introduction

Symptoms:
  • Performing actions against NSXv will fail after upgrading to Cloud Director 10.3 or later
  • Errors populate anytime a user tries to provision NSX-V resources in the VCD environment
  • The errors are similar to the following:
  • Error: I/O error on GET request for "vcdexample01.com:443/policy/api/v1/infra/tier-0s/vcd-provider-t0": Certificate for <nsx.example.com> doesn't match any of the subject alternative names: [nsxt-manager-01]; nested exception is javax.net.ssl.SSLPeerUnverifiedException: Certificate for <<nsx.example.com>> doesn't match any of the subject alternative names: [nsxt-manager-01] - Certificate for <<nsx.example.com>> doesn't match any of the subject alternative names: [nsxt-manager-01]
 
  • Error: Deployment of edge gateway Edge-Example failed. - I/O error on GET request for "https://<IP>:443/api/4.0/edges": Certificate for <IP> doesn't match any of the subject alternative names: []; nested exception is javax.net.ssl.SSLPeerUnverifiedException: Certificate for <IP> doesn't match any of the subject alternative names: [] - Certificate for <IP> doesn't match any of the subject alternative names: []


Environment

VMware Cloud Director 10.x
VMware Cloud Director for Service Provider 10.x

Cause

  • This issue occurs post upgrading to Cloud Director 10.3 or later because of the enhanced SSL validation mechanism used to verify the hostname on the NSX manager.
  • The certificate for the NSX-V instance needs to include the “Subject Alternative Name” field in order to properly  function. The self-generated .csr files from the NSX-V manager do not include this field by default.

Resolution

1. Build a config file with the following information:
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = country
ST = State
L = city
O = Organization
OU = MyDivision
CN = example.com
[v3_req]
keyUsage = keyEncipherment, dataEncipherment, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
IP.1 = <IP>
DNS.1 = example.net
DNS.2 = example.com
DNS.3 = example.net


***Replace commonName (CN) and [alt_names] with the DNS names***

NOTE:
  • The keyUsage field in the above configuration may not meet the requirement if only "keyEncipherment, dataEncipherment" is used when connecting to other products.
  • Please check in advance which keyUsage is used in the NSX-V SSL certificate with web browser.

2. Generate cert.pem and key.pem files based on the previous configuration file (in this case named ssl.cnf):
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out cert.pem -config ssl.cnf -extensions 'v3_req' -keyout key.pem

3. View the certificate and verify that the SAN is populated on the certificate:
openssl x509 -in cert.pem -noout -text

4. Convert the NSX Manager Certificate File to PKCS12 Format
openssl pkcs12 -export -in cert.pem -inkey key.pem -out nsx-manager.p12

5. Import the certificate into the NSX manager
6. Edit the NSX-V Manager Info page in VCD to reflect the hostname instead of the IP
7. Verify that NSX-V resources can now be provisioned



Additional Information

https://kb.vmware.com/s/article/78885

Impact/Risks:
  • This issue prevents the provisioning of NSX-V resources in a VCD environment