NSX 4 installation comes with an out-of-the-box self-signed SSL certificate. For security and compliance reasons, most customers want to replace the default self-signed certificates with CA-signed certificates. In this two-part blog post, I’ll explain how to prepare your certificate infrastructure, request the certificate, and finally replace the SSL certificate. There are some very useful guides, like this one from VMware, but I will explain the whole certificate replacement process in the following blog posts.

The whole process can be divided into the following steps:

1. Certificate Preparation
2. Certificate Request
3. Certificate Replacement

In first part, we are going to cover step 1 and 2 which prepare the PKI infrastructure and request the certificate. In second part we are going to Import, verify and replace the CA signed certificate.

So, let’s start with the first step, which is to prepare the certificate. In most of our engagements, customers are using a Microsoft-based Certificate Authority(CA), so we decided to run it with a Microsoft CA. First, we need to prepare a Certificate Template. You can do this by duplicating a default Web Server certificate and making some minor changes to it. On your CA, open the Certification Authority snap-in, right-click on Certificate Template, and choose Manage.

In the Certificate Templates snap-in right, click on Web Server and choose the Duplicate Template option. This will create a specific certificate template for VMware NSX and other related products use case.

First, you need to change the Compatibility Settings for Certificate Authority to Windows Server 2008 R2 and Certificate recipient to Windows 7/ Server 2008 R2. This is necessary because of the Basic Constraints configuration.

Next, go to the extension tab, choose Basic Constraints, click Edit, and make sure to select Enable this extension. If you don’t enable this option, later when you try to verify the imported certificate you will get an error. The error state “Certificate is not compliant as certificate of type SERVER: Basic constraints Extension is not present in the certificate.”

Now go to the General tab, name your certificate, and press OK to save the new template. We named the new template NSX-SSL-Cert.

After all to make the new template available for request and issue, go back to Certification Authority template, right click on Certificate Template, choose New and select Certificate Template to Issue.

In the Enable Certificate Template page, select the template created in the previous step.

Now the certificate template should be listed in the template list and ready to request and issue afterwards.

Before moving on to the next step, just a small verification of your Microsoft CA. Make sure your CA is configured with SHA256 Hash algorithm and not SHA1! If you miss this step, later when you try to verify the imported certificate you will get an error. The error state “Certificate does not use supported signature algorithm.”

If your CA is configured with SHA1 hash algorithm, you can upgrade the algorithm with this instruction. What you should basically do is to run Certutil command and then restart the certificate service.

Now having the certificate template ready, we can go ahead and prepare the CSR for the certificate request. There two options to generate CSR for NSX . First one is to use CSR Generator from NSX Manager WebUI which is the easier option but since it does not support SAN properties will have some issue with Chrome browser. The second option is to create a .cnf file manually and create the CSR with use of OpnSSL. We decided to go with the second option.

Below is the template for creating the .cnf file. Use this template and change the values based on your environment. One thing that is important is to use FQDN for commanName and DNS.1 keys. Because we are using a VIP for NSX Management cluster, we used VIP’s FQDN for this .cnf file. Copy paste below test into a notepad, modify the values and save it with .cnf extension.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
countryName = COUNTRY-INIT
stateOrProvinceName = STATE
localityName = STATE-INIT
organizationName = NSX
commonName = VIP-FQDN
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = VIP-FQDN

To generate a CSR from this .cnf file we should use OpenSSL. Use the following execution command to generate CSR and private key from .cns file. Because we named .cnf file as nsx-vip.cnf , we ran the command as below.

openssl req -nodes -newkey rsa:2048 -keyout nsx-vip.key -config nsx-vip.cnf -out nsx-vip.csr

After running OpenSSL command, two file should be generated. One CSR which will be used to submit the request to CA and corresponding private key(*.key) that we use when importing the certificate into NSX WebUI.

To submit the certificate request, open browser and point to Web Enrollment page of your CA. First Log-in and then choose Request a certificate from the first page.

On the next page choose “advanced certificate request”

On the next page copy paste the content of CSR file and choose the right certificate template that has been created previously.

Submit the request and after it issued, download certificate chain based on Base 64 encoded version.

It is really important to download the whole certificate chain because you need it when importing the certificate in NSX WebUI. After downloading the certificate chain, open the .p7b file and check if all the certificates are in place.

We should export both certificates with Base-64 encoded X.509 now. Select each certificate one-by-one, right click, choose All Tasks and then Export. As it mentioned make sure to select Base-64 encoded X.509(.CER) as export format.

So after all this effort, we are done with certificate preparation and request. In Part 2, we are going to verify, replace and test the generated certificates.