WilliamLam.com

Automating SSL Certificate Regeneration in VCSA 5.1 & 5.5 (vCenter Server Appliance)

by // 4 Comments

The VCSA (vCenter Server Appliance) provides a very simple way of regenerating the self-signed SSL Certificate by using the VAMI web management interface. This is extremely useful if you change the IP Address or hostname of your VCSA and want a proper SSL certificate with the correct common name, especially important if you are plan on using something like vCenter Orchestrator which validates this. To regenerate the SSL Certificate, you just need to login to the VAMI web interface by pointing your browser to the following address: https://[VC-IP]:5480 and under the Admin tab there is a option to "Toggle certificate setting".

After enabling this option, you will need to reboot your VCSA for the new SSL certificate to be generated. Once the VCSA is booted up, you will need to go back into the VAMI interface and disable this setting, else another SSL certificate will be generated upon the next reboot.

I was recently asked if it was possible to automate the SSL regeneration via the command-line without using the GUI which would be very useful for automated VCSA deployments. In looking into this, it turns out the process is quite simple and the present of a file within the VCSA will determine whether a certificate regeneration is required.

To enable certificate regeneration, run the following command which will "touch" (create) allow_regeneration file under /etc/vmware-vpx/ssl directory:

touch /etc/vmware-vpx/ssl/allow_regeneration

To disable certificate regeneration, you just need to remove the file after the VCSA has rebooted. Behind the scenes, this is what is happening when you are toggling the option in the VAMI interface and now you can automate this from the CLI without using the GUI!

UPDATE (09/04/13)

For the new VCSA 5.5, there is a new option that you can specify which will re-generate the SSL certificate and then delete the file without requiring manual intervention after reboot. You would still need to create the /etc/vmware-vpx/ssl/allow_regeneration file but if the contents of the file contains "only-once", it will delete the file automatically which is nice from an Automation perspective.

To re-generate the SSL certificate and automatically have it clean itself up, run the following command:

echo only-once > /etc/vmware-vpx/ssl/allow_regeneration

How to Update vSphere Infrastructure Navigator (VIN) After Changing vCenter Server IP Address

by // 2 Comments

If vSphere Infrastructure Navigator (VIN) is deployed in your environment and you change the IP Address of the vCenter Server, VIN will no longer function even after a reboot. The reason for this is that when VIN first registers with the vCenter Server, information is generated and stored within VIN such as the IP Address as well as security thumbprint. Since the IP Address of the vCenter Server has changed, we simply just need to re-register VIN with the vCenter Extension vService.

In my lab I have VIN deployed and connected to a vCenter Server (note the IP Address 172.30.0.229):

I then update the vCenter Server's IP Address to 172.30.0.230 which will break communication with VIN. To resolve this, start off by shutting down the VIN appliance. Once it is shutdown, edit the settings and click on "Manage->vServices" and at the bottom click on the Edit button. Next change the Provider drop down to "No Provider" and then click OK.

Now we will reset the Provider back to the vCenter Extension vService by going through the same workflow again but now selecting "vCenter Extension vService" as the provider.

You will also notice at the bottom there is a validation message and you should also see the new IP Address of your vCenter Server. Once you are done, click OK to save the settings and then power back on your VIN appliance. Once VIN is up, connect to the vSphere Web Client and you should be able to see your VIN data again!

Automate vCenter Orchestrator Configuration Backups

by // Leave a Comment

Last year I wrote an article on how to quickly configure a new vCenter Orchestrator 5.1 appliance which automatically goes through the necessary steps of configuring your vCO appliance and enabling the vCenter Server plugin and associating it with your vCenter Server. These steps are usually performed manually, but when you are looking at deploying multiple vCO instances or even quickly spinning up vCO appliance for testing, this will definitely help speed up your deployment.
Something that I did not consider after completing the vCO setup was backups. Fortunately, this was something that was shared with me recently from a customer who had this exact workflow on backing up their vCO configuration after their initial deployment. This may not be a very well known feature, but vCO provides a very simple mechanism to export your vCO configurations and allows you to restore the configuration in case of a miss-configuration or even deploying a similar configuration to another vCO instance.
Using the same HTTP request trick, to export the vCO configuration you would need to make a request to the following URL:

https://${VCO_IP_ADDRESS}:8283/config_general/ExportConfig_export.action

Similar to the vCO UI, the backup will be stored on the vCO appliance itself and the path will be provided back to you in the message response. To help demonstrate this, I created a simple shell script called backupVCO51.sh which is similar to the setup script in my previous blog article. You can easily take the few lines of code and integrate that with the setup script.

Here is a screenshot of running the backup script:

From the output we can see where the backup configuration is stored on the vCO appliance and you can easily copy the backup to an external system using SCP.

Whether or not you are automating your vCO setup, you should definitely consider performing periodic backups of your vCO configuration, especially before making any changes to your vCO Server.