In this part of the series we will produce CA signed certificates for vRLI. In my environment, I have 3 vRLI instances sitting behind a load balancer. This means I have 4 possible URLs / IP address that need to be considered, the 1 for the load balancer and the one each for the 3 instances. This is important since we want to be able to connect to the VIP or the actual instances and need to define the subject alternate names to cover all possibilities.

You will need to have openssl installed to produce the keys and CSRs for this process. If you don’t have it, go here to get it. In the examples below, when I execute openssl commands from the command prompt, I am not showing paths. Depending on your installation of openssl and where you are executing from, you may need to add paths before the openssl command and file names in the command.

Step 1. First we going to generate a 2048 bit key. The key is placed into a file called vrli-dc1.key. This file will be used to generate the CSR as well as being loaded onto the Log Insight instances later in the process.

openssl genrsa -out vrli-dc1.key 2048
Generating RSA private key, 2048 bit long modulus
……………………………………………………………………………+++
…..+++
e is 65537 (0x10001)

Step 2. Next we are going to prepare a csr (Certificate Signing Request) This file is submitted to the Certificate Authority and used to create a signed certificate.
The openssl.cfg file looks like this:

[ req ]
default_bits = 2048
default_keyfile = vrli-dc1.key
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:vrli-dc1, IP:192.168.1.40, DNS:vrli-dc1.local, IP:192.168.1.40, DNS:vrli-dc1-001, IP:192.168.1.41, DNS:vrli-dc1-001.local, IP:192.168.1.41, DNS:vrli-dc1-002, IP:192.168.1.42, DNS:vrli-dc1-002.local, IP:192.168.1.42, DNS:vrli-dc1-003, IP:192.168.1.43, DNS:vrli-dc1-003.local, IP:192.168.1.43

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = NY
localityName = Pittsford
0.organizationName = VMWare
organizationalUnitName = vCenterInventoryService
commonName = vrli-dc1.local

In my lab I have 3 Log Insight servers behind the integrated load balancer. In order to be able to connect to the instance using the VIP as well as directly to each of the instances without a certificate error, I have added the VIP and the IPs of each instance as well as the short and long names.

Execute the following. The CSR file will be called vrli-dc1.csr and is what must be shipped to your Certificate Authority.

openssl req -new -key vrli-dc1.key -out vrli-dc1.csr -config openssl.cfg

Step 3. From here we need to get the CSR signed by our lab CA. See Part 2 of this series to find out how. The output of that process will be a .cer file that has the signed certificate. Make sure you also get a copy of the CA’s root certificate as you will need it in Step 4. See Part 1 of this series to get the CA Root certificate if you don’t already have it.

Step 4. We now need to combine the Key generated in Step 1 and the CA Root Certificate and the .cer file produced in step 3. Use a text editor to create a new file and place the contents of the Key file into it. Next open the CA Root Certificate and copy the contents of the file directly under the Key. Lastly, take the contents of the .cer file produced when you signed the CSR and put it under the CA Root Certificate. You should end up with something that looks like this. Don’t forget to save the file.

—–BEGIN RSA PRIVATE KEY—–
MIIEogIBAAKCAQEAmPl04SiVt+tAAwkxQz6inV1D6cSBXbk4rlholKTLOTr8VVxe
pKtlPJENeBJ150JaYyQ+RST7cjQtGkqNyqrBS0vJDaK6/5TzkQ+P5hcC5H3x9GJv
QEeUMkpLw2Ku45wvSQCn/M0nRDJYHBLfF4rUsWMRRzARbM/RZZbiqp0hyxF44vXG
aP/R8hbnxvOg3pquGhwCMuFBGsylgm0fm2f3HxkwMjpVVqoLrk4MSveL7iB9ngfa
…
bBxZwsC+LDPjZAPa/A/xMyq4CVbYCg5XDJ1yrBry5w7u8XB44VtdJEfih4TIYn8s
Y+NHAoGAWGF+DLzcoHSs5bJafmebgB3HlxBRQDiJvpQyHIXxiB66t9JtukH83zSd
6xFiEfwLmOja4TdFmK72MToTOnfJ4DPvAAs0fifGiuY3E7h68M4WDSjHyqUo/2xW
l0vMYdufHA5xBQREjljs2copeeAIE5SdkJq0fF6/VmcjfvOBIVc=
—–END RSA PRIVATE KEY—–
—–BEGIN CERTIFICATE—–
MIIE+zCCAuOgAwIBAgIQawsxF90J0r5JtCHLqV7awjANBgkqhkiG9w0BAQsFADAQ
MQ4wDAYDVQQDEwVMYWJDQTAeFw0xNzEwMjYyMDM1NTBaFw0yNzEwMjYyMDQ1NDZa
MBAxDjAMBgNVBAMTBUxhYkNBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC
AgEAv/PKRLqtgtWSS5fofsV4Bvniwzkiky8lPP7XCCG9ifdRy0eYpkM1y3Lnf0s6
…
eTrYP+eDerb910j0cvl9EpwkfizxKHznE/MBDXCseF1EqbIfAlokJyEyGRQp7Izf
vzMcx3oE5+BULe3kXMGUZppKDR2tmTG8E8v2I8liSKqjvkq3W5OBLHKRt+6O7Dx1
25YeFp7xN7dn6jjA9klYCCxYwKvLZg2dxWrfiw1+BuDJhzistLx1uVIAp1An0KGs
HGFxhql0/9jVqXyOmOMneU7lG5Spawik2NXCE3C0ow==
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIIF3jCCA8agAwIBAgITdgAAABIPjZJfI43OzQAAAAAAEjANBgkqhkiG9w0BAQsF
ADAQMQ4wDAYDVQQDEwVMYWJDQTAeFw0xODA0MjcxMzEyMzFaFw0xOTA0MjcxMzIy
MzFaMHoxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJOWTESMBAGA1UEBxMJUGl0dHNm
b3JkMQ8wDQYDVQQKEwZWTVdhcmUxIDAeBgNVBAsTF3ZDZW50ZXJJbnZlbnRvcnlT
…
FGZarCPg117mREaYzB3i2PSMc/ZKNoWKSLP6kNkuleCMJojlCExL7ytrF8bi/1ye
5P0QmJhUPBT4bYherVV2duWs7JxA5pom3YypaOqWzy84kqqQcj92MWboqHTN8SWR
7ekAFg1hr+kKywJ+wvtBbUAgIsYV8fORyVMrPO+q9ehhPVjapVfTUvJ6ceSANR3Z
X8gDJ/UH0QwgxYPVPFYkOCIk
—–END CERTIFICATE—–

(NOTE The … replaces a bunch of lines to reduce the size of the example above.)

Step 5. Finally we are going to load the certificate into the vRLI server. The great thing about vRLI is there is a method to do this directly in the UI and all instances automatically get the certificate so there is only one place that this needs to be done.

Connect to the admin UI by going to https://<YOUR_VRLI_URL_OR_IP>/admin. Under Configuration, click SSL and then click Choose File. Select the file saved in Step 4.

vRLI will now validate that the file contains the chain to the Root CA, and intermediate CAs (if applicable), the Private Key and the signed Certificate. If all goes well, the SAVE button will be enabled. Click it and you should see the following.

This process will take a few minutes to complete.

Step 6. And that is all you need to do. You will need to close any open browsers you have pointing to your instance and reopen them. When you do you should see a Green URL in your browser indicating that the certificate is valid and trusted.

In Part 4 in the series we will add certificates to vRealize Operations Manager.

In Part 1 of this series, we looked at setting up a Certificate Authority. You will need a CA in order to complete Part 2 and the subsequent parts in this series.

In order to trust certificates, a CSR needs to be signed by a CA that is trusted on the devices you will connect from. In Part 3 we will look at creating a CSR for vRLI but this walk through will be relevant for all the future parts in this series that require a CSR to be signed.

Step 1. Copy the CSR file you have to the server running the CA and then open the Certification Authority configuration app. Right click the CA, click All Tasks and then click Submit new request…

Step 2. A file selector will pop up and ask you for the .CSR file. Select it and click Open.

The CSR is loaded into the CA and if everything is good, it will put the request into the Pending Requests folder.

Step 3. Right click the request and select All Tasks and then Issue.

The certificate is now placed in the Issued Certificates folder.

Step 4. Double click the issued certificate and a viewer window opens. Here you can see that the certificate is used to ensure the identity of a and proving the identity of a remote computer.

Step 5. Click the Details tab. Here you can see all the specifics of the certificate. Click the Copy to File button. This is going to allow us to save the certificate file for installation on the server.

Step 6. Click Next

Step 7. Ensure that you select Base-64 encoded for the output format and click Next.

Step 8. Enter a file name for the file and click Next.

 

In the first part in this series, I am going to walk you through setting up a simple Certificate Authority on Windows 2016 Server for a lab environment. If you want to get rid of those annoying warnings every time you open a web session for vCenter, or ESXi or pretty much any VMware product, you have to have a signed and trusted certificate on the web server. Without it, you are required to acknowledge the risk of connecting to the site and then clicking to continuing on to that site. This is particularly painful when you are trying to demo a product like the vROps Tenant App for vCD that has a iFrame that connects to the App. Unless you go and do the acceptances before you start the demo, you are stuck getting rid of these warnings which interrupt proceedings. In my lab environment, I setup a Microsoft Certificate Authority to sign certificates for the various tools I am running allowing me to get rid of that warning and have all green URLs in my browser.

First things first, you need to have a VM running Windows Server 2016. I will not go into the details of setting up a Windows Server here.

Step 1. We need to add the Certificate Authority Role to the server. Open the Server Manager and then select Add Roles and Features.

Step 2. Click Next on the information page.

Step 3. Keep role-based or feature-based installation selected and click Next.

Step 4. There should only be one destination server and it should be the one you are working on. Click Next.

Step 5. Next in the Server Roles selection, tick the Active Directory Certificate Services and wait for the popup for the additional features that are required for ADCS.

Once this pops up, click Add Features.

Step 6. You should now have a tick against Active Directory Certificate Services. Click Next.

Step 7. On the select features page, leave it as is and click Next.

Step 8. Click Next on the ADCS information page.

Step 9. Select Certification Services in the Role Services and click Next.

Step 10. Select Restart the desination server automatically if required and click Yes in the popup. Finally click Install.

Step 11. The installation of the ADCS will start.

Step 12. If all goes well, the installation should complete and you can click close. (On a fresh 2016 install a restart is not usually required.)

Step 13. Go back to your Server Manager Dashboard and you should see a yellow exclamation. This indicates you need to complete the ADCS configuration.

Step 14. Click the flag and then click Configure Active Directory Certificate Services on th…. in the Post-deployment Configuration item.

Step 15. Keep the default credentials and click Next.

Step 16. Tick Certification Authority and click Next.

Step 17. Keep Standalone CA selected and click Next. For an Enterprise CA you need to be connected to a domain and that is not needed for our purposes.

Step 18. You want to deploy a Root CA unless you have a Root CA that this CA can be a subordinate of. Click Next.

Step 19. Leave create new private key selected and click next.

Step 20. The default Key Length and algorithm should be sufficient for lab needs. Click Next

Step 21. Give the CA a name and click Next.

Step 22. The default validity is 5 years. I normally make it 10. Once you have set it, click Next.

Step 23. Leave the default database locations unless you specifically want to change them and click Next.

Step 24. Click Configure on the summary page.

Step 25. And you should now have a configured Certificate Authority.

Step 26. On the Server Manager Dashboard, click the Tools Menu and then Certification Authority.

Step 27. And here you should see your newly minted CA.

Step 28. Right click lab-ca and click Properties. You will see Certificate #0 in the list which is the public certificate for the CA itself. Click View Certificate.

Step 29. You will see the summary page for the certificate that indicate the Validity period. (10 years in this case)

Step 30. In order for devices you use to trust certificates signed by this Certificate Authority, you will need to install the public certificate of the CA into the Trusted CAs list on each device.
Click the Details tab.

Step 31. Now click Copy to File and click Next.

Step 32. You need to export the certificate in Base-64 Encoded format as you will use the contents for various VMware solutions. Select Base-64 and click Next.

Step 33. Select a location and name for the file and click Next.

Step 34. Click Finished on the summary page.

Step 35. If you now open the file you just saved with Notepad, it will look something similar to this.

And that’s it. You are now ready to mint certificates for your lab servers. Don’t forget to save the public certificate into the Trusted Root Certificates of your devices that you use to manage the lab environment.

In part 2 we will look at signing a CSR (Certificate Signing Request) with our new CA.