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

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

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.

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.

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.

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!