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 VMware NSX

Issue/Introduction

  • 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

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***

Follow the steps to build the above config file
  • Create a file using the Linux command: touch ssl.conf (the file name can be anything; for example  ssl.conf).
  • Use the vi editor and copy the the above details in the ssl.conf.
  • Hit the "Esc" and "wq!" to save the file and exit the vi editor.
  • Validate the content in the ssl.conf file: cat ssl.conf.
 
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

Powered by Wolken Software