SSL : Part 5.3 : vCloud Director 10 CA Signed Certificates

With the release of vCloud Director 10, further advances were made in the Appliance. There are now various types of configurations of the appliance that includes both application cells and DB cells (PostgreSQL). It has become more stable and I would recommend using it for any new deployments. A basic production installation consists of 3 DB cells and 3 app cells. The official VMware documentation does a fairly good job of explaining the deployment and can be found here.

In this post, I will go through the replacement of the self signed certificates on the cells. (In a previous post I explained how to deploy a Microsoft CA for use in a lab if you need one.) In this example, I will produce a single signed certificate that will server both the html 5 interface and the console proxy.

Step 1. First we are going to produce an unsigned certificate and place the, in a new certificate store. (It will be replaced with signed certificate 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 script below to create the certificate. It is 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-dc2-001.local, OU=VCPP Sales, O=VMware, L=Palo Alto, S=California, C=US" \
-ext "san=dns:vcd-dc2-001.local,dns:vcd-dc2-001,ip:192.168.28.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 script below, you should end up with a new file called vcd-dc1-001-http.csr

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

Step 3. From here we need to get the CSR signed by our CA. See Part 2 of this series to find out how. The output of that process will be a .cer file that contain 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 are now going to take the two .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 two scripts to get the files into the store.

/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-dc2-001-http.cer

Step 5. As I mentioned before, we are going to use a single certificate for both the html 5 server and the console proxy. The cell management tool is expecting two certificates with the alias http and consoleproxy. In order to make the tool work, duplicate the certificate with the http alias into and alias called consoleproxy using the scrpt below.

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \
-storetype JCEKS \
-keyclone \
-alias http \
-dest consoleproxy \
-keypass ChangeMe \ 
-new ChangeMe \
-storepass ChangeMe

Step 6. 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 -list

store.png

Step 7. Next, copy the certificate store to the transfer location in preparation for installing them into vCD.

cp certificates.ks /opt/vmware/vcloud-director/data/transfer/certificates.ks

chown vcloud.vcloud /opt/vmware/vcloud-director/data/transfer/certificates.ks

Step 8. We going to use the cell management tool to import the certificates into vCD.

/opt/vmware/vcloud-director/bin/cell-management-tool certificates -j -p \
--keystore /opt/vmware/vcloud-director/data/transfer/certificates.ks \
--keystore-password ChangeMe

Step 9. Finally, restart the vCD service so that the new certificates are loaded and used.

service vmware-vcd restart

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. This will also allow you to connect through the console proxy without any issues.

secure.png

SSL : Part 5.1 : CA Signed Certificates for vCloud Director with a single IP

Update: If you looking for a post on CA signed certificates for vCloud Director 10, go here.

This is a tweaked version of Part 5 and produces certificates for a vCD instance running on a single IP address as opposed to the usual 2, one for http access and one for the console proxy. Tomas Fojta explains the configuration for a single IP in this blog. It must be noted that even though vCD is using a single IP, there still needs to be two certificates in the keystore during configuration.

Step 1. First we are going to produce an unsigned certificate and place it in a new certificate store. (It will be replaced with a signed cert 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 certificate. It is 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-003.local, OU=Sales, O=VMware, L=Pittsford, S=New York, C=US" \
-ext "san=dns:vcd-dc1-003.local,dns:vcd-dc1-003,ip:192.168.20.83"

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 script below you should end up with a new file called vcd-dc1-003.csr.


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

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 contain 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 are now going to take the two .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 two 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-003.cer

Once this is done, list the contents of the certificate store to make sure that the root and http certificate are in there.
/opt/vmware/vcloud-director/jre/bin/keytool -storetype JCEKS -storepass ChangeMe -keystore certificates.ks -list001.png

Step 5. As I mentioned above, the configurator for vCD expects two certificates in the store even if you are using a single IP. Since we want to use the same certificate for both, we care going to copy the http certificate into the consoleproxy certificate. Run the 3 scripts below to create a new file called certs.ks that will contain the three required certificates.


/opt/vmware/vcloud-director/jre/bin/keytool \
-importkeystore \
-srckeystore certificates.ks \
-srcstoretype JCEKS \
-srcstorepass ChangeMe \
-srckeypass ChangeMe \
-srcalias http \
-destkeystore certs.ks \
-deststoretype JCEKS \
-deststorepass ChangeMe \
-destkeypass ChangeMe \
-destalias http


/opt/vmware/vcloud-director/jre/bin/keytool \
-importkeystore \
-srckeystore certificates.ks \
-srcstoretype JCEKS \
-srcstorepass ChangeMe \
-srckeypass ChangeMe \
-srcalias http \
-destkeystore certs.ks \
-deststoretype JCEKS \
-deststorepass ChangeMe \
-destkeypass ChangeMe \
-destalias consoleproxy


/opt/vmware/vcloud-director/jre/bin/keytool \
-importkeystore \
-srckeystore certificates.ks \
-srcstoretype JCEKS \
-srcstorepass ChangeMe \
-srcalias root \
-destkeystore certs.ks \
-deststoretype JCEKS \
-deststorepass ChangeMe \
-destalias root

And once again, list the contents of the certs.ks file to ensure you have three certificates and the thumbprint for the http and consoleproxy are the same.
/opt/vmware/vcloud-director/jre/bin/keytool -storetype JCEKS -storepass ChangeMe -keystore certs.ks -list002.png

Step 6. 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 as 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 \
-cons 192.168.20.83 \
--console-proxy-port-https 8443 \
-ip 192.168.20.83 \
--primary-port-http 80 \
--primary-port-https 443 \
-dbhost vcd-dc1-003.local -dbport 5432 -dbtype postgres -dbname vcloud -dbuser vcloud -dbpassword 'vcloudpass' \
-k /tmp/certs.ks \
-w 'ChangeMe' \
-loghost vrli-dc1.local \
-logport 514 \
-g \
--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.

003.png004.png

SSL : Part 6 : CA Signed Certificates for vCloud Availability 1.5 C2C

Today we are going to work through replacing the self signed certs on the vCAV 1.5 C2C instances. If you are new to vCloud Availability for Cloud to Cloud, head on over to my college Daniel’s blog page here. He has a number of blogs around vCloud Availability.

vCAV C2C is the new generation of vCloud Directory Availability tools and will have DR2C added in the not too distant future. This build of vCAV radically improves the experience for both the provider when deploying and the customer when using the solution. By default, the appliances are deployed with a built in self signed certificate and if you want to expose the environment to the real world, you going to want to have properly signed certificates protecting the communications.

Step 1. First we are going to produce an unsigned certificates and place it 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 vCAV C2C instance and change to the /tmp directory. Execute the script below to create the certificate. It is placed in a certificate store called keystore.jks. You can ignore the warning about the JCEKS keystore using a propriety format. You should then have a file called keystore.jks in the /tmp directory.
NOTE: In the example below, I am using vmware as the password for both the private key and the key store itself. I suggest leaving them as vmware but if you are super security conscious, you will need to update the application.properties file in /opt/vmware/h4/cloud/config. Specifically these lines
keystore.location=./config/keystore.jks
keystore.password=vmware
keystore.alias=cloud
keystore.keypassword=vmware

keytool -keystore keystore.jks \
-alias cloud \
-storepass vmware \
-keypass vmware \
-storetype jks \
-genkeypair \
-keyalg RSA \
-keysize 2048 \
-validity 3650 \
-dname “CN=c2c-dc1-004.local, OU=Sales, O=VMware, L=Pittsford, S=New York, C=US” \
-ext “san=dns:c2c-dc1-004.local,dns:c2c-dc1-004,ip:192.168.21.84”

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 script below you should end up with a new file called c2c-dc1-004.csr.

keytool -keystore keystore.jks \
-storetype jks \
-storepass vmware \
-certreq \
-alias cloud \
-file c2c-dc1-004.csr \
-ext “san=dns:c2c-dc1-004.local,dns:c2c-dc1-004,ip:192.168.21.84”

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 contain 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 are now going to take the two .cer files collected in step 3 (Root + Signed Cert) and load them into the certificate store file keystore.jks. You will need to use a tool like WinSCP to transfer the files to your C2C server. Once you have them there, execute the next two 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 keystore.jks \
-storetype JCEKS \
-storepass ChangeMe \
-import \
-alias root \
-file LabCA.cer


/opt/vmware/vcloud-director/jre/bin/keytool -keystore keystore.jks \
-storetype JCEKS \
-storepass ChangeMe \
-import \
-alias http \
-file c2c-dc1-004.cer

Once this is done, list the contents of the certificate store to make sure you see the root cna cloud certificate. (As well as any intermediate certificates if there are any)
keytool -storetype JCEKS -storepass vmware -keystore keystore.jks -list
001.png

Step 5. Now we are ready to replace the self signed certs. They are in a file called keystore.jks in /opt/vmware/h4/cloud/config.
First lets rename the existing file so we can revert if things don’t work out.
mv /opt/vmware/h4/cloud/config/keystore.jks /opt/vmware/h4/cloud/config/keystore-old.jks
and then copy over the new keystore we just created
cp /tmp/keystore.jks /opt/vmware/h4/cloud/config/keystore.jks
Very important, don’t forget to set ownership of the keystore.
chown h4:root /opt/vmware/h4/cloud/config/keystore.jks

Step 5. Finally, reconfigure the appliance and restart the service
/opt/vmware/h4/bin/sysboot.py
systemctl restart cloud
Give it 2 minutes and check that it is up and running with
systemctl status cloud
002.png

Step 6. Open a browser and go to https://your-c2c-url:8046. Firstly, the browser should indicate that the certificate is valid and after logging in, you should see that the connection to the remote site is broken.
003.png
Click on Cloud Sites and then hit the REPAIR in the failed site. It will ask you to accept the new certificate. Click LOGIN and enter the credentials and it should all be working again.
005.png

 

All in one vCloud Director Appliance for your lab.

Update: With the delivery of vCD 10 came a much improved Appliance experience. I recommend using the appliance with vCD 10 for an lab (or production) deployments.

If you’re like me, you need to build or rebuild your vCD environment fairly often for various POCs. This blog will guide you to a quick and easy single VM vCD build that has PostgreSQL, RabbitMQ and vCD. I am going to use CentOS 7 for the platform as it has all the bits it needs and is fairly simple to wrap your head around if you don’t play too much with Linux.

First up, go and download yourself the CentOS installer ISO from here.

For my build I use 4 vCPUs, 8 GB of RAM and a 16GB HD. Note I have 2 network interfaces. One for HTTP and the other for Console Access.

001.png

I will not go through the CentOS install as there are plenty of resources out there on doing that. Once you have the install done, SSH into the VM using the root user. We will now install PostgreSQL.

I disable the firewalld process in my lab. This is not a recommended action in a production environment!
systemctl disable firewalld
systemctl stop firewalld

Install ntp so your time is synced. (For more details go here)
yum install ntp
systemctl start ntpd
systemctl enable ntpd
Edit the ntp config if you want to use an internal NTP server.
vi /etc/ntp.conf
My internal ntp server is 192.168.20.1 so I removed the centos servers and added
server 192.168.20.1 iburst
And restart ntp
systemctl restart ntpd

Next, make sure everything is up to date by doing 
yum -y update

Install Postgres (We need PostgreSQL 10) (If you doing this on RHEL, Daniel has a great post on installing Postgres10 here)
rpm -Uvh https://yum.postgresql.org/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm
yum install postgresql10-server postgresql10
/usr/pgsql-10/bin/postgresql-10-setup initdb
systemctl start postgresql-10.service
systemctl enable postgresql-10.service
service postgresql-10 start
Set the postgres OS user password
passwd postgres
And the postgres PSQL user password
su – postgres
psql
ALTER USER postgres WITH PASSWORD ‘YourSuperSecretPassword’;
\q
Create the vcloud user and enter a password when prompted.
createuser vcloud –pwprompt
Now create the vcloud DB
psql
create database vcloud owner vcloud;
and set the vcloud password
alter user vcloud password ‘vcloudpass’;
and let the user log in
alter role vcloud with login;
\q

Lastly we need to enable logins to the DB using a user and password from the local machine and optionally from remote machines.
Change to the 10/data directory and edit the  pg_hba.conf file
vi pg_hba.conf
Add the following line at the end of the file.
host all all 0.0.0.0/0 md5
If you want to restrict connections to the local machine only, change the 0.0.0.0/32 to 127.0.0.1/32. For a lab, using 0.0.0.0/0 lets you connect to the DB from anywhere.
Save the file.
Edit the postgresql.conf file
vi postgresql.conf
Find the line containing listen_addresses and ensure there is no # in the front and change ‘localhost’ to ‘*’
Save the file and exit su.
exit
Finally restart postgres.
systemctl restart postgresql-10
You should now be able to connect to the vcloud DB using a tool like pgAdmin (which you can get here) If you have not disabled firewalld above, you will need to poke holes through the firewall to connect from a remote machine.\

Next up is the installation of RabbitMQ as the message bus. (Below are the command required to do this. If you want to see more details, go here)
yum -y install epel-release
yum -y update
yum -y install erlang socat
Install wget if you don’t have it installed
yum -y install wget
Now fetch and install the RabbitMQ rpm
wget https://www.rabbitmq.com/releases/rabbitmq-server/v3.6.10/rabbitmq-server-3.6.10-1.el7.noarch.rpm
rpm –import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc
rpm -Uvh rabbitmq-server-3.6.10-1.el7.noarch.rpm
systemctl start rabbitmq-server
systemctl enable rabbitmq-server
And if all went well you should see it up and running with
systemctl status rabbitmq-server
If you have not disabled the firewall as above, see here for the firewall rules you need to add)
Enable management
rabbitmq-plugins enable rabbitmq_management
rabbitmqctl add_user admin StrongPassword
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p / admin “.*” “.*” “.*”
Now you should be able to connect to the RabbitMQ UI at
http://your.ip.address:15672
vCD can use the admin user for the Q but I generally create a used called vcd in the RabbitMQ UI and give it permissions on /

Let’s install vCloud Director. You should download the rpm installer from the VMware download site. Copy it across to your VM using WinSCP.
First you will need to add a few dependencies
yum install libXdmcp
yum install libXtst
yum install redhat-lsb
Then execute the installer.
chmod u+x vmware-vcloud-director-distribution-9.5.0-11038216.bin
./vmware-vcloud-director-distribution-9.5.0-11038216.bin
When the installer asks if you want to run the configuration script, select n (no). We will execute it later once we have created the certificates.

At this point, if you want to make a template out of the VM, go ahead. That way, you have a nice starting point from which to build new vCD instances. This is done before the config so you can have multiple instances running off the same template.

We now need to produce CA signed certificates. I have a number of other blogs on this that can be found here. Stop after Step 4. We will use the certificates.ks file in the configuration step.

The last step is to run the setup script. Execute
/opt/vmware/vcloud-director/bin/configure
You will first be asked to assign the HTTP and Concole Proxy IPs.
Next is the certificate file you created earlier /tmp/certificates.ks as well as it’s password.
Then a syslog server if you have one.
And lastly the DB information. Select PostgreSQL and enter the FDQN of the VM (or it’s IP if you have it fixed), the port, DBname, User name and finally password.
At this point, the installer creates all the DB tables etc and then asks you to join the Customer Experience program and at last, asks if you want to start vCD.

Wait a few mins after the script completes and you should he able to open your browser to https://your.vcd.instance

Happy vCDing!

 

 

SSL : Part 5 : CA Signed Certificates for vCloud Director

Update: If you looking for a post on CA signed certificates for vCloud Director 10, go here.

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