Yes, time to update my vSphere 5.5 Toolkit with a few more features and bug fixes. For those of you that need to replace your vSphere 5.5 SSL certificates, the process can be somewhat cumbersome and time consuming. While VMware has a tool to help you replace the certificates once you create them (SSL certificate automation tool), it has limited functionality in helping you create all the files needed as pre-reqs to running the tool.
Since my vSphere 5.1 installation series was so popular, for vSphere 5.5 I wanted kick it up a few notches. So I wrote the vSphere 5.5 Toolkit script that has a number of features to ease your SSL pain. For a complete list of features, click here. To date it has had over 3,200 downloads. Now live is a minor update, for your deployment pleasure. v1.55 of my Toolkit script is now available for download here.
What’s new since v1.50?
Root Certificate Validation (New)
This version addresses an issue where sometimes the automatic download of a root or subordinate CA certificate would result in HTML code and not a Base64 certificate. The root cause of this issue is how Microsoft implemented the certificate download feature. Because the root certificates can be renewed, there’s a counter called “renewal” in the download URL to specify which certificate to download.
My script does not have logic to download all certificates and pick out the newest one (maybe in future versions). But what it will do is validate the file contents to ensure a certain string is present which indicates the file contains a Base64 encoded certificate. If the file is invalid an error will appear and the script halts. If that happens, search for “renewal” in the script (two locations) and decrement the number to 0. If it downloads an old certificate that expired, increment the number up by one until it gets the most recent version.
The script also checks manually downloaded base64.cer and interm64.cer certificate files for the same string, to validate they are Base64 encoded. It’s easy to use the wrong file type, which will greatly confuse the VMware certificate replacement tool. All of your certificate files should look like the example below, with —–BEGIN CERTIFICATE—–.
If your certificates are invalid, then you will get a red warning as shown below.
Certificate Request Changes (New)
VMware notified me that an upcoming change to a KB article was in the works. According to VMware the Web Client certificate needs the IP address in the SAN field with both DNS and IP extensions (e.g. DNS:10.10.10.10, IP:10.10.10.10). Apparently this is for maximum cross-browser compatibility across IE, Chrome and Firefox. For simplicity all certificate requests have both extensions in this version. If you don’t have any web client issues due to using an IP address vice the FQDN, then you don’t need to re-issue the web client certificate. If you do have issues, then this is probably the reason. You only need to update the web client certificate, not the 250 other vCenter certificates.
ESXi Host Support (If you missed it)
While not new to v1.55, version v1.50 released on December 22, 2013 added fairly robust ESXi host support. I didn’t blog about that version, so some of you may not be aware of it. I did Tweet, so make sure you follow me on Twitter for more timely news. You can manually enter several ESXi hosts to replace the certificates on, or give it an input file of hostnames. SSH is NOT required (uses HTTPS), and should be backwards compatible with vSphere 4.x and later although I have not personally tested it. This supports an Online Microsoft CA, offline CA, or third-party CA.
Given the positive feedback on the tool, it appears to be doing what I intended: Simplify the vCenter 5.5 installation process and make security easier. If you experience any problems or bugs, please leave a comment. I can’t promise to fix everything, but I’ll try to fit it into my schedule. Again, you can download the latest version from here.