This article discusses the creation of of NSX Manager SSL certificate, which contains extended attributes such as Subject Alternative Name (SAN).
I’ve always found it challenging working with SSL certificates, because of variety of the TLS protocol enforcement by software vendors. Last week I was working on upgrading our NSX Advanced Implementation class lab with the latest VMware software versions. When I say upgrade I actually mean rip-out and fresh install of almost everything: vSphere, vCenter, NSX and vSphere Replication.
At some point I reached the place to change the NSX manager self-generated certificate with one from the lab certificate authority (CA): for people familiar with VMware HOL this is the ControlCenter server.
Having sufficient experience in this procedure, I quickly generated new certificate signing request (CSR) using the NSX Manager UI; requested the certificate from the ControlCenter CA and uploaded it to the NSX Manager.
Unfortunately my impetus and enthusiasm was quickly flushed, after NSX Manager was reloaded and I tried to open the UI. Google Chrome was still complaining. This time not with the normal “normal self-signed error message“, but with slightly different one: ERR_CERT_COMMON_NAME_INVALID.
How the Common Name (CN) could be invalid? I’ve just generated this certificate?
I clicked on the “Hide Advanced” hyperlink, at the error screen, and I noticed that Chrome was complaining about Subject Alternative Name (SAN) not being specified. Of course I had to read about this creature. Apparently Google had enforced this into Chrome since version 58 (https://support.google.com/chrome/a/answer/7391219?hl=en), to comply with the 18 year old RFC 2818 (https://www.chromestatus.com/features/4981025180483584).
So Google Chrome no longer matches CN, but SAN. You can imagine the joy for the security administrators, who will have to regenerate hundreds of thousands of new certificates.
Fair enough, our particular task is how to generate CSR that includes Subject Alternative Name, without using NSX Manager UI. Quick check with VMware documentation, confirms that NSX Managed’s built-in CSR generator cannot contain extended attributes such SAN (https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/com.vmware.nsx.admin.doc/GUID-75E20224-AE0D-433E-934C-7632949C3562.html).
So after the problem was demystified, let see how we can solve it by using OpenSSL to generate the CSR.
First step is to create OpenSSL input configuration file, like the one below. The important information is in the last line, in which we specify that for SAN we will use DNS record matching our domain name. You can define more than one DNS record and you can also include NSX Manager IP address using “IP.1″ and attribute.
[ req ] default_bits = 2048 distinguished_name = req_distinguished_name req_extensions = req_ext [ req_distinguished_name ] countryName = Country Name (US) stateOrProvinceName = State or Province Name (CA) localityName = Locality Name (Palo Alto) organizationName = Organization Name (VMware) organizationalUnitName = Organization Unit (LiveFire) commonName = Common Name (e.g. server FQDN) [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = *.corp.local
Then we have to generate the CSR and the private key, using the OpenSSL CLI.
After we have the CSR we can open it with a text editor, copy the signing request and then by using Windows Certification Web UI we can generate and download the certificate. When downloading the certificate we have to use “Base 64 encoded” format.
We also need the CA certificate that we can download using again the Windows Certification Web UI.
Next step will be to generate a PKCS12 file using again OpenSSL CLI. During the process, we will be asked for a password, which will be attached with the certificate chain.
After we have the PKCS12 certificate chain, we can upload it using the NSX Manager UI. The password is the one that we have defined in the previous step.
Then we have to reboot the NSX Manager appliance for the certificate to take effect and-viola-this time Chrome doesn’t complain and the certificate is recognized as valid.
We can also verify that there is a new field for the certificate attributes, which defines the Subject Alternative Name.
Finally, if you are not Chrome addicted (not that I am) and this is not a production environment, which has to comply with different security regulation, security protocols and penetration testing, you can simply use IE Explorer (no public information) or Mozilla Firefox (currently opposed: https://bugzilla.mozilla.org/show_bug.cgi?id=1245280).