WilliamLam.com

Using PowerCLI to automate the retrieval of VCSA Password Policies

by // Leave a Comment

I hope that every vSphere administrator or operator by now is familiar with the extremely powerful vSphere Guest Operations API functionality (details here and here), which can easily be consumed using PowerCLI's Invoke-VMScript cmdlet. If not, highly recommend you check out the links referenced. I know the GuestOps API is certainly my top favorite with sending VM keystrokes capability a very close second!

Not only does the GuestOps API unlock functionality that simply may not be possible (e.g. there's no API or automation interface) but it also enables automation within a VM without requiring any type of remote management services enabled (e.g. SSH or WinRM) or even networking to the VM for that matter!

The reason I am bringing all this up is that although there is not an API for managing and retrieving vCenter Single Sign-On (SSO) configurations which includes password policies, there is a way in which customers can still automate and retrieve this and other information by leveraging the GuestOps API. In fact, back in 2015 I demonstrated on how you can retrieve VCSA SSO password policy and configurations and we can simply apply the GuestOps API to help us automate this task. In addition, most customers do not enable SSH by default and we can still apply the GuestOps API technique and perform automation tasks to VSCSA without requiring SSH as described in this blog post back in 2016.

[Read more...]

Is vCenter Server & ESXi hosts using VMware Certificate Authority (VMCA) or custom CA certificates?

by // 3 Comments

Customers have two primary methods of managing TLS certificates for their ESXi hosts, they can either use the built-in VMware Certificate Authority (VMCA) which is part of vCenter Server or Custom CA Certificates. I will not go into the gory details, but you can read more about the options here in our documentation.

A question that I had received recently was whether you can determine the type of certificate an ESXi host was provisioned with and whether this could be programmatically retrieved using the vSphere API? The answer is yes. In vSphere 6.0, we introduced a CertificateInfo property which contains a number of fields including status, issuer, expiry and subject details and by inspecting either the issuer or subject property, you can determine the type of certificate on the ESXi host.

Here is a screenshot of the data using the vSphere MOB for an ESXi host that has VMCA-based certificate:


Here is a screenshot of the data using the vSphere MOB for an ESXi host that has custom CA certificate:


As you can see, for VMCA-based certificate the issuer's OU will have value of "VMware Engineering" and subject's emailAddress will have value of "*protected email*".

[Read more...]

Automating SSL Certificate Expiry Validation for vCenter Server + ESX(i) Hosts

by // 3 Comments

As many of you know, it is a best practice to replace VMware's self-signed SSL certificates that are included in the vCenter Server (Windows & VCSA) and ESX(i) hosts to prevent or help reduce MiTM (Man in The Middle) attacks. If you are looking for more details on how to replace the default SSL certificates, you should take a look at the fantastic articles written by Michael Webster who details the process, provides some troubleshooting steps and best practices for SSL certificate replacement.

Replacing the default self-signed SSL certificate is just one part of the process, but you also need to check to ensure the certificates are still valid and have not expired. If you already have a process in place or a system that automatically does this for you, that is great. If you do not, you should definitely validate that your SSL certificates are valid on a regular basis.

I recently stumbled onto a nifty open source tool called ssl-cert-check that can help with validating expiration of SSL certificates found on vCenter Server(s) and ESX(i) hosts or any other SSL enabled host for that matter. This utility is just a shell script (specifically bournce shell) wrapping the common openssl utility found on most UNIX/Linux systems and does not require any login credentials to the remote hosts to validate the SSL certificate.

To use the script, you can visit the website here and download it to a system that has openssl installed (in my home lab, I used vMA).

It took me awhile to find the script, but it's located on the right side of the screen where it says "Website". You can also download it from the command-line using wget if you have direct/proxy access to the internet:

wget http://freecode.com/urls/353b752faa208fca12bc0091c742f764 -O ssl-cert-check

Note: Don't forget to set the execute permission on the script (chmod +x ssl-cert-check) else you will get permission denied when trying to run the script.

The script can be executed interactively by specifying the -s option for server and -p for the port. You can also specify the issuer of the certificate by using the -i option. Below is a screenshot of running the ssl-cert-check against a vCenter Server:

You can also run the script in batch mode by specifying -f option which accepts a list of servers in FQDN along with the port number. Using this feature of the script, you can easily run this script against all your vCenter Server(s) and ESX(i) hosts to ensure that their SSL certificates are still valid.

If you already have a list of hosts you want to check, then you can easily create a new file with the hostname and port. Though if you do not have one handy, I wrote a quick vSphere SDK for Perl script called generateESXiHostsList.pl that helps automate the creation of the output file containing all ESX(i) hosts when connecting to a vCenter Server. To use the script, you just need to have vCLI installed on a system or use vMA.

The script accepts one options which is --output which specifies the name of the output file to be created:

If we "cat" the file out, we can see it looks like the following:

vesxi50-1.primp-industries.com 443
vesxi50-2.primp-industries.com 443
vesxi50-3.primp-industries.com 443
vesxi50-4.primp-industries.com 443

Let's now run the ssl-cert-check against the list of ESX(i) hosts using the -f option and see if we have any hosts with expired certificates:

Uh oh, it looks like we have two hosts with some problems. We can see one host that already has an expired SSL certificate and another one that will be expiring in 10 days. We better take a look at these and get them replaced soon!

There are additional options in the ssl-cert-check script including the ability to email the results or run as a nagios check. You can easily schedule a cron job to automate this script to run every week and grepping for the keyword "Expiring" to alert you of any hosts that have expiring SSL certificates. As you can see, it is not only important to replace the default self-signed SSL certificates in your environment, but you need to validate on a routinely basis your your certificates are still valid.