Changing your certificates in Cloud Director has always been an interesting topic. A lot of people find the process difficult and I am sure support get a lot of calls in regards to this. Over time I hope it becomes easier for people who might not be used to working with different types of certificates. Until then here is the new process for replacing your certificates in Cloud Director 10.3.1

If you have upgraded from earlier versions of Cloud Director and you have an existing certificate in place then it will still work fine on version 10.3.1. The issue may arise when you restore a cell from backup or if your certificate is about to expire and you want to replace it. Then you will need to follow the new process.

In a single cell environment VMware recommend just replacing the certs in the following location,

/opt/vmware/vcloud-director/etc/user.http.pem
/opt/vmware/vcloud-director/etc/user.http.key
/opt/vmware/vcloud-director/etc/user.consoleproxy.pem
/opt/vmware/vcloud-director/etc/user.consoleproxy.key

If you have a multi cell environment and are using wildcards then they recommend placing the new copies of your certificate files into the transfer share,

/opt/vmware/vcloud-director/data/transfer/user.http.pem
/opt/vmware/vcloud-director/data/transfer/user.http.key
/opt/vmware/vcloud-director/data/transfer/user.consoleproxy.pem
/opt/vmware/vcloud-director/data/transfer/user.consoleproxy.key

In my lab I have an existing pfx file which I would like to upload to my Cloud Director environment. To do this we will need to extract the cert files out as pem and key files. You can install openssl on your laptop or management server but it comes built in to Cloud Director so in this example we will use the cloud cell.

Using winscp copy your pfx file to your Cloud Director cell and store it in the /tmp directory.

When I first extracted out the key and pem files it contained the bag attributes before each cert in the chain. This is something that will cause the cert replacement process to fail so it needs to be removed.

Thankfully removing the bag attributes is straight forward and I have included the commands below to export each certificate file you will need without the attributes.

In order to replace the certificates in Cloud Director 10.3.1 we need the following files,

user.http.key
user.http.pem
user.consoleproxy.key
user.consoleproxy.pem

To get started SSH into your Cloud Director cell and browse to the /tmp directory. Then run the following command to extract the user.http.key,

openssl pkcs12 -in /tmp/vcloud.pfx -nocerts -nodes | sed -ne ‘/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p’ > /tmp/user.http.key

Then run the following command to extract the user.http.pem,

openssl pkcs12 -in /tmp/vcloud.pfx -nokeys | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > /tmp/user.http.pem

Then run the following command to extract the user.consoleproxy.key,

openssl pkcs12 -in /tmp/vcloud.pfx -nocerts -nodes | sed -ne ‘/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p’ > /tmp/user.consoleproxy.key

Then run the following command to extract the user.consoleproxy.pem,

openssl pkcs12 -in /tmp/vcloud.pfx -nokeys | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > /tmp/user.consoleproxy.pem

At this stage it is important to check the certificate chain order in your pem files. The order should show the main certificate first, then the intermediate certificate and then the Global Root CA certificate.
If your intermediate and global root certs are around the wrong way use the vi command to edit the pem file and change the order. The command to use will be vi /tmp/user.http.pem and once you have the file open press i to insert.

For example if your global root cert is above your intermediate then highlight the global root from –BEGIN CERTIFICATE– to –END CERTIFICATE– and then paste it below the intermediate. Then go back to the first line of the section you highlighted and press dd to delete each line. Once complete press :wq to save the changes. Your pem file should now be in the correct order. You will need to do this for user.http.pem and user.consoleproxy.pem

My lab only has the one cell but for this example I am going to pretend my cert is a wildcard and put my new certificates on the transfer share. This will simulate the process for what you would be doing in a production environment as the cert would then be available to your other cells. If you wanted to follow this process to replace the certificate on your single cell environment then just change the destination to /opt/vmware/vcloud-director/etc/ instead.

Run the following commands to copy the certificates to the transfer share,

cp /tmp/user.http.pem /opt/vmware/vcloud-director/data/transfer/user.http.pem
cp /tmp/user.http.key /opt/vmware/vcloud-director/data/transfer/user.http.key

cp /tmp/user.consoleproxy.pem /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.pem
cp /tmp/user.consoleproxy.key /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.key

Next we need to check the permissions. As you can see the new cert files need to have the permissions changed to vcloud

Run the following commands to change the permissions of the new certificate files,

chown vcloud:vcloud user.consoleproxy.key
chown vcloud:vcloud user.consoleproxy.pem
chown vcloud:vcloud user.http.pem
chown vcloud:vcloud user.http.key

Next apply the new certificates by running the following commands,

/opt/vmware/vcloud-director/bin/cell-management-tool certificates -j –cert /opt/vmware/vcloud-director/data/transfer/user.http.pem –key /opt/vmware/vcloud-director/data/transfer/user.http.key –key-password root-password

/opt/vmware/vcloud-director/bin/cell-management-tool certificates -p –cert /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.pem –key /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.key –key-password root-password

Once complete run the following command to stop the service,

/opt/vmware/vcloud-director/bin/cell-management-tool cell -i $(service vmware-vcd pid cell) -s

Then run the following command to start the service,

systemctl start vmware-vcd

NOTE – If you want to check the status run – systemctl status vmware-vcd

NOTE – If you have any additional cells then run the following commands to update their certificates,

/opt/vmware/vcloud-director/bin/cell-management-tool certificates -j –cert /opt/vmware/vcloud-director/data/transfer/user.http.pem –key /opt/vmware/vcloud-director/data/transfer/user.http.key –key-password root-password

/opt/vmware/vcloud-director/bin/cell-management-tool certificates -p –cert /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.pem –key /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.key –key-password root-password

Once complete run the following command to stop the service,

/opt/vmware/vcloud-director/bin/cell-management-tool cell -i $(service vmware-vcd pid cell) -s

Then run the following command to start the service,

systemctl start vmware-vcd

Now browse to your Cloud Director url and the certificate should now be updated.

Next you will need to update your public addresses certificate. Since we have already created the pem files use winscp to copy one of the pem files from the /tmp directory back down to your local workstation. The public addresses cert must include the certificate chain, for example the endpoint certificate, intermediate certificates, and a root certificate in the pem format without the private key.

Login to the Cloud Provider portal, select Administration and then click on Public Addresses from the left hand menu. Click on EDIT and then select the Replace Certificate option to browse for your Web Portal replacement certificate file.

Select Next and enable the Use Web Portal Settings option. Click Next and enter your Cloud Director console proxy url followed by port 8443, ie vcloud.domain.com:8443, then click SAVE.

That’s it your Cloud Director 10.3.1 certificates have now been replaced!