SSL : Part 5 : CA Signed Certificates for vCloud Director

Is this part of the series we will be creating CA signed certificates for vCloud Director. vCD requires two certificates, one for the HTTP service and one for the console proxy service. vCD has some specific requirements and one of them is to use Java version 7 runtime environment to produce the keys, certificates and certificate signing requests. We will still be using the Microsoft Certificate authority to sign the CSRs. See Part 1 for details on setting that up. vCD has the required tools already installed so we will be doing the main grunt work by SSHing to vCD.

There are a few things to note before we begin. This process works either during a deployment of vCD or after you have already deployed vCD. In the latter case, you will need to call the configure script for vCD in unattended mode in order to redefine the certificate store. I will go through how to do that too. You must also be sure to name the aliases in the certificate store exactly as I have them. There is no way to define the aliases in the configure script and the values I have used are the ones the script looks for when reading the certificate store. Lastly, I am using two IPs for my vCD. You can do it with one but 2 simplifies things and allows you to use port 443 for both services.

So without further ado, lets build some certificates.

Step 1. First we are going to produce two unsigned certificates and place the, in a new certificate store. (They will be replaced with signed certs later but we need the keys for the signing) Open a SSH session to your vCD instance and change to the /tmp directory. Execute the two scripts below to create the two certificates. They are placed in a certificate store called certificates.ks. You can ignore the warning about the JCEKS keystore using a propriety format. You should then have a file called certificates.ks in the /tmp directory.

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-alias http \
-storepass ChangeMe \
-keypass ChangeMe \
-storetype JCEKS \
-genkeypair \
-keyalg RSA \
-keysize 2048 \
-validity 3650 \
-dname “CN=vcd-dc1-001.local, OU=Sales, O=VMware, L=Pittsford, S=New York, C=US” \
-ext “san=dns:vcd-dc1-001.local,dns:vcd-dc1-001,ip:192.168.20.81”

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-alias consoleproxy \
-storepass ChangeMe \
-keypass ChangeMe \
-storetype JCEKS \
-genkeypair \
-keyalg RSA \
-keysize 2048 \
-validity 3650 \
-dname “CN=vcdconsole-dc1-001.local, OU=Sales, O=VMware, L=Pittsford, S=New York, C=US” \
-ext “san=dns:vcdconsole-dc1-001.local,dns:vcdconsole-dc1-001,ip:192.168.22.81”

Step 2. Next we going to produce a certificate signing request (CSR) that we will send on to our Certificate Authority (CA). Once you execute the two scripts below you should end up with two new files called vcd-dc1-001.csr and vcdconsole-dc1-001.csr.

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-storetype JCEKS \
-storepass ChangeMe \
-certreq \
-alias http \
-file vcd-dc1-001.csr \
-ext “san=dns:vcd-dc1-001.local,dns:vcd-dc1-001,ip:192.168.20.81”

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-storetype JCEKS \
-storepass ChangeMe \
-certreq \
-alias consoleproxy \
-file vcdconsole-dc1-001.csr \
-ext “san=dns:vcdconsole-dc1-001.local,dns:vcdconsole-dc1-001,ip:192.168.22.81”

Step 3. From here we need to get the CSRs signed by our lab CA. See Part 2 of this series to find out how. The output of that process will be two .cer files that contain the signed certificates. 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 are now going to take the three .cer files collected in step 3 and load them into the certificate store file certificates.ks. You will need to use a tool like WinSCP to transfer the files to your vCD server. Once you have them there, execute the next three scripts to get the files into the store. Again, note that you must use the same alias names as in the script.

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-storetype JCEKS \
-storepass ChangeMe \
-import \
-alias root \
-file LabCA.cer

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-storetype JCEKS \
-storepass ChangeMe \
-import \
-alias http \
-file vcd-dc1-001.cer

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-storetype JCEKS \
-storepass ChangeMe \
-import \
-alias consoleproxy \
-file vcdconsole-dc1-001.cer

Once this is done, list the contents of the certificate store to make sure all the bits are in there.

/opt/vmware/vcloud-director/jre/bin/keytool -storetype JCEKS -storepass ChangeMe -keystore certificates.ks -list01.png

I suggest moving this file to a more permanent location. I put mine in /opt/keystore.

Step 5. We are now ready to reconfigure (in my case) vCD. In order to get the new certificate store into vCD, we need to run the configure script in unattended mode. The script I use is as follows but you may need to change it depending on your lab setup. I have installed Postgres on my vCD server so you may have to adjust if you using Oracle or MSSQL. (If you are, you should consider switching to Postgres and support for Oracle is already depreciated in 9.1 and MSSQL will be depreciated in the next release! This is good news as VMware moves to making vCD available as an appliance.)

Stop vCD:

service vmware-vcd stop

Update the configuration:

/opt/vmware/vcloud-director/bin/configure \
-ip 192.168.20.81 –primary-port-https 443 \
-cons 192.168.22.81 –console-proxy-port-https 443 \
-dbtype postgres -dbhost vcd-dc1-001.local -dbname vcloud -dbuser vcloud -dbpassword vcloudpass \
-k /opt/keystore/certificates.ks -w ChangeMe \
-loghost vrli-dc1.local \
–enable-ceip true \
-unattended

Start vCD:

service vmware-vcd start

And that’s it. Give vCD a minute or two to get going and then open a new browser session to your instance. It should be nice and secure now.

02.png

SSL : Part 4 : CA Signed Certificate for vRealize Operations Manager

vRealize Operations Manager has a similar process to installing certificates that we went through with vRealize Log Insight with one minor tweak. When creating the PEM file to be loaded into the appliance, you need to make sure you have the order of the certificates correct in the file. If they are not correct, the PEM file will not be validated and you will be unable to proceed. The file also needs to have a .PEM extension.

Again 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 vrops-dc1.cfg file looks like this:

[ req ]
default_bits = 2048
default_keyfile = vrops-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:vrops-dc1, DNS:vrops-dc1.local, DNS:vrops-dc1-001, DNS:vrops-dc1-001.local, DNS:vrops-dc1-002, DNS:vrops-dc1-002.local, IP:192.168.20.30, IP:192.168.20.31, IP:192.168.20.32

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = NY
localityName = Pittsford
0.organizationName = VMWare
organizationalUnitName = VCPP Sales
commonName = vrops-dc1.local

In my lab I have 2 Operations Manager servers behind a OPNsense 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 vrops-dc1.csr and is what must be shipped to your Certificate Authority.

openssl req -new -key vrops-dc1.key -out vrops-dc1.csr -config vrops-dc1.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. As I mentioned in the intro, it is important to put the pieces into a .PEM file in the correct order. Make sure to save it with a .PEM extension. Use a text editor to create a new file and place the contents of the signed certificate (from Step 3) into it. Next open key file (from Step 1) and put it after the certificate. Lastly, put the CA certificate (and any intermediate CA certificates) into the file and save it. It should look something like this:

—–BEGIN CERTIFICATE—–
MIIFlTCCA32gAwIBAgITdgAAABZtfJXdkMVXVAAAAAAAFjANBgkqhkiG9w0BAQsF
ADAQMQ4wDAYDVQQDEwVMYWJDQTAeFw0xODA1MDMxMjE3MTdaFw0xOTA1MDMxMjI3
MTdaMG4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJOWTESMBAGA1UEBxMJUGl0dHNm
b3JkMQ8wDQYDVQQKEwZWTVdhcmUxEzARBgNVBAsTClZDUFAgU2FsZXMxGDAWBgNV
….
….
k1qa8JtHuZoL1ABjoMt2Wt4617SPwSKx/7ISp18Okvs49GL5OpDWJd2qhTsxtCmG
MRRlUbaxq3ldP55lGhAWVMLHbw/DOS3Ja6dCQbSjF8z97AT0vaipgl3vElkwqThd
2+TvTMZzRWVoA5UGftPaqRILh4C65OqGYND4hpK28MA26GgB3rETef7Vf9oksRZv
BgCB7S+ZwuVlYyJIfadUHInpStcOSLpsz7/sNNEdGKPUr4BidQUkKSk=
—–END CERTIFICATE—–
—–BEGIN RSA PRIVATE KEY—–
MIIEogIBAAKCAQEAnSUgrV6MpS39uvtz2/VNpY+BmdI9CZaShD+94tbvI1V4QreP
XaC1jZy6AReB2libopO4kFVTGfP3kLpIfoarvZlqtkwmNraJ/tm5pt4R3L/ESLk7
A6Hs0Qv4uHe0oTDY+cu6VTeuP6GaowlPpTKYx1gmg49srxk4U6W9xYRvaIPw4iW3
dE9OHqB05MD5mYwFOPPH8YhpihxWX4bG6+fdj2ZzJme1dlY9o1qmEbolCluAGjnh
….
….
z0k17KSa/ruNv2nnnY15ntKu2hPWBn9Jf9m8zYK1gfW+e0H8NaCHqOBAE+8YrrcD
UUoFAoGAJ17yakk7R6LcCEVX6hjnBUHyNR6mueDh/ItLIQoP3/sQ5mkCF/LMdyZO
x38Ys+FPzdf065dUCdKfGBfDxH6ZeQChyQSPQK2IGXwDP5QTOe/khCzHMh4Z/38G
JHUO9AAWsiAu8iY3bD+ZBwNrNE2CbnkbcSie4EbsISX6AJ6c3FY=
—–END RSA PRIVATE KEY—–
—–BEGIN CERTIFICATE—–
MIIE+zCCAuOgAwIBAgIQawsxF90J0r5JtCHLqV7awjANBgkqhkiG9w0BAQsFADAQ
MQ4wDAYDVQQDEwVMYWJDQTAeFw0xNzEwMjYyMDM1NTBaFw0yNzEwMjYyMDQ1NDZa
MBAxDjAMBgNVBAMTBUxhYkNBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC
AgEAv/PKRLqtgtWSS5fofsV4Bvniwzkiky8lPP7XCCG9ifdRy0eYpkM1y3Lnf0s6
….
….
eTrYP+eDerb910j0cvl9EpwkfizxKHznE/MBDXCseF1EqbIfAlokJyEyGRQp7Izf
vzMcx3oE5+BULe3kXMGUZppKDR2tmTG8E8v2I8liSKqjvkq3W5OBLHKRt+6O7Dx1
25YeFp7xN7dn6jjA9klYCCxYwKvLZg2dxWrfiw1+BuDJhzistLx1uVIAp1An0KGs
HGFxhql0/9jVqXyOmOMneU7lG5Spawik2NXCE3C0ow==
—–END CERTIFICATE—–

Step 5. Finally we are going to load the certificate into the vROps server. The great thing about vROps is there is a method to do this directly in the UI and all instances in the cluster 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_VROPS_URL_OR_IP>/admin. Click the certificate icon in the top right of the UI.

01.png

This opens a dialog to replace the existing certificate. Click Install New Certificate

02.png

Click Browse and select the .PEM file you created.

04.png

Ensure the Certificate Information contains the details of the certificate you created earlier in Step 3. Click Install. Wait for the install to complete.

Step 6. Open a new browser session and point to the vROps instance. The browser should now show the site as secure.

05.png

In Part 5 in the series we will add certificates to vCloud Director.

 

 

SSL : Part 3 : CA Signed Certificate for vRealize Log Insight

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.

01.png

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.

02.png

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.

03.png

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

 

 

SSL : Part 2 : Signing a CSR with your Microsoft Certificate Authority

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…

Screenshot.jpg

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

Screenshot_001.jpg

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

Screenshot_002.jpg

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

Screenshot_003.jpg

The certificate is now placed in the Issued Certificates folder.

Screenshot_004.jpg

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.

Screenshot_005.jpg

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.

Screenshot_006.jpg

Step 6. Click Next

Screenshot_007.jpg

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

Screenshot_008.jpg

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

 Screenshot_010.jpg
Step 9. Finally click Finish.
Screenshot_011.jpg
You now have the certificate in a .cer Base-64 encoded file ready for upload to the server.
In Part 3 of this series we will look at creating a CSR for vRealize Log Insight, get it signed by our CA and deploying the signed certificate to the server.

 

SSL : Part 1 : Building a Microsoft Certificate Authority for your lab

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.

I wonder.jpg

Step 2. Click Next on the information page.

I wonder_001.jpg

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

I wonder_002.jpg

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

I wonder_003.jpg

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.

I wonder_004.jpg

Once this pops up, click Add Features.

I wonder_005.jpg

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

I wonder_006.jpg

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

I wonder_007.jpg

Step 8. Click Next on the ADCS information page.

I wonder_008.jpg

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

I wonder_009.jpg

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

I wonder_010.jpg

Step 11. The installation of the ADCS will start.

I wonder_011.jpg

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.)

I wonder_012.jpg

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.

I wonder_013.jpg

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

I wonder_014.jpg

Step 15. Keep the default credentials and click Next.

I wonder_020.jpg

Step 16. Tick Certification Authority and click Next.

I wonder_016.jpg

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.

I wonder_017.jpg

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.

I wonder_018.jpg

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

I wonder_019.jpg

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

I wonder_020.jpg

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

I wonder_023.jpg

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

I wonder_024.jpg

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

I wonder_025.jpg

Step 24. Click Configure on the summary page.

I wonder_026.jpg

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

I wonder_027.jpg

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

I wonder_028.jpg

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

I wonder_029.jpg

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.

I wonder_030.jpg

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

I wonder_031.jpg

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.

I wonder_032.jpg

Step 31. Now click Copy to File and click Next.I wonder_033.jpg

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.

I wonder_034.jpg

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

I wonder_035.jpg

Step 34. Click Finished on the summary page.

I wonder_036.jpg

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

I wonder_037.jpg

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.

 

What is the vROps Tenant App for vCD …… and how to get it up and running.

This is my first VMware blog and is going to be all about the recently released vRealize Operations Manager Tenant App for vCloud Director. This is a great way to expose vROps performance metrics to tenants in a vCD environment and allow them to only see metrics relevant to their organization. vCD 9.x has been a revolution in the way vCD is evolving and before you say vCD is dead, go to this great blog by Daniel Paluszek and read all about how it is not! This is an awesome way for providers to give their tenants more visibility into the performance of their environments and will help the tenants to do more of the first line maintenance themselves. They will also feel comfortable being able to see first hand what is and isn’t performing in their cloud.

So onto the setup of the Tenant App. There are three main parts to getting this done, installing an AMQP broker, installing the App and configuring vCD and vROps.

Before we get into the nitty gritty, we need to download the Management Pack and the Appliance. You can find both of them here. You get the management pack by clicking the green ‘Try’ button to the right of the screen, and the appliance .ova by clicking ‘Appliance: vRealize Operations Tenant App for vCloud Director’ in the list of resources.

 

Installing an AMQP Broker

For this part I wanted to use something simple and pretty much out the box and bitnami have a great pre-built VM in .ova format that is just that. It is an install of the tried and trusted RabbitMQ and you can go here to get it. Deploy the .ova and start it up. Once it is done with it’s setup during boot, you will get a screen something like this in the console:

pics_006.png

Log into the console using ‘bitnami’ and ‘bitnami’. You will be required to set a new password during the login process.

We are going to configure the firewall first to allow access to the Management Portal and the application itself. Execute the following at the prompt
sudo ufw allow 15672/tcp
sudo ufw allow 5672
15672 is the port for the RabbitMQ Management Panel and 5672 is the default RabbitMQ Application port.

Print out the fire wall rules and they should look something like this:
pics_002.png

Next we need to allow connections to RabbitMQ. By default, RabbitMQ only accepts connections from the local host.
Stop the RabbitMQ service
sudo /opt/bitnami/ctlscript.sh stop
and edit the configuration file
sudo vi /opt/bitnami/rabbitmq/etc/rabbitmq/rabbitmq.config
You need to change the tcp listener to accept connections from all or certain IPs depending on your environment. I setup my instance to accept connections from any IP. Change 127.0.0.1 to 0.0.0.0 to allow any IP to connect. Below are the before and after edits.
pics.png

pics_001.png

Finally, restart the RabbitMQ service
sudo /opt/bitnami/ctlscript.sh start

Next we need to configure the RabbitMQ server. We are going to do this from the Management Panel. Connect to http://<YourServerIP&gt;:15672 and use the username and password from the console splash screen.
pics_014.png
In my case it is ‘user’ and ‘jpoDZzvsrOQ2’

Once into the Management Panel, click the ‘Admin’ Tab and then click ‘Add a user’. I created a user called ‘vcd’ and entered a password and clicked ‘Add user’.
pics_007.png
The ‘vcd’ user is now in the list. Click it to configure the permissions. I used the defaults and just clicked ‘Set permission’ and ‘Set topic permission’ to allow the user to access the Virtual Host and AMQP default exchange.
pics_008.png

With that, you are all set with the RabbitMQ configuration.

Let’s get vCD connected up. Connect to the flex client (you cannot do this in the HTML5 client just yet) and go to Administration -> Extensibility and configure the AMQP Broker Settings. Below is what I configured in mine : (Remember to click the Test AMQP to ensure all is good)
pics_009.png

And now vCD is wired up to the AMQP Broker.

 

Installing the vROps Management Pack

Log into vROps as the admin and go to the Administration -> Solutions page. Click the green plus to add a solution and select the .pak file you downloaded earlier. Once the install is completed, click the Configure gears icon and enter your vCD instance details. Mine looks something like this:
pics_011.png
Make sure to test the connection to confirm all is working.

And that is it for the installation of the Management Pack.

 

Deploy the Appliance

The final step is to deploy the appliance and register the plugin with vCD. Deploy the Appliance .ova file you downloaded earlier and be sure to configure all the settings correctly during the deployment process. These settings are difficult to change after deployment and if you need to change anything, you are pretty much better off just redeploying. (As of writing this blog, deploying the appliance from the vCenter HTML5 client does not work so you need to use the flex client.)
pics_010.png

Once the deployment is done and you start the VM, you should see the URL to connect to in the console.

The final piece of the puzzle is to register the plugin with vCD. You do this from the console of the Tenant App you just installed. Connect as root and run

cd /opt/vmware/plugin

python publish.py -H vcd-dc1-001.local -u administrator@system -p <YourAdminPassword>

Note that you must use administrator@system as the username and not administrator@vsphere.local.

And that’s it! You should now be able to log into the HTML 5 vCD portal and open the Operations Manager screen. Mine looks like this:
pics_012.png