PowerCLI Virtualization Vmware

Getting past Certificate issue in Power CLI

So I recently started working more with PowerCLI. After my time at VMWorld 2019 (which I will cover in another post) I realized how powerful that PowerCLI actually is (pun not intended). In starting to work with PowerCLI I came across the following message whil: trying to connect to my vCenter

Connect-vIServer : xx-x-xxxx xx:xx:xx Connect-VIServer Error: Invalid server certificate. Use Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you’d like to connect once or to add a permanent exception for this server.

I did some googling and I found this article,so shout out to Ivo Beerens for his article.

In his article he goes on to share this command

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

After putting that into PowerShell and pressing enter you will no longer get the Invalid Certificate message.

I hope you found this post helpful, I will be posting about some of the scripts that I have been posting on my Github. Please share with your friends if you found this helpful. 

I didn’t know this was even possible…. SSL Certificate weirdness

 So I was working on the post about how to resolve the SSL Certificate error message that you get if you do not have the Root certificate for the ESXi host installed on your machine. Well in the process of taking screen shots for that post I discovered something that I have never seen before.  Rather than starting from the beginning, lets pick up at the end of the last post.

So right after you finish installing the Root CA on your machine, you have closed out of your web browser and reopened it and go to the URL and you get this message.

On first glance it looks like the certificate install failed, but it didn’t, Upon closer inspection of the message you will see that there is an issue with the CN is invalid. 
For those who do not know CN means Common Name which is usually the FQDN or Host name of the server. So I went back to check the CN of the Certificate of the ESXi host and I found what you see below.  This is where things get crazy….

So according to the image above, the SAN or Subject Alternate Name (AKA a list of CN’s, usually up to 5 on one Certificate) is an IP Address!!! How the heck is it an IP address? 
So what I tried next was typing in in my web browser and I was immediately presented with the image below. 

So wait, it worked like it should using the IP address instead of the name. How did that certificate get issues at all.

WELL….. It would appear that one of my co-workers added this host to vCenter with the IP address instead of the name.

Needless to say I am very disappointed in my Co-Worker for not following our naming convention.  But if I had to guess it looks like VMCA (VMWare Certificate Authority) which is included in the PSC (Platform Services Controller) and issues Certificate to hosts when they are added to vCenter must have issues the certificate to the IP address because he added it using the IP. Having dealt with several different Certificate Authorities in my time, this is crazy to see. 
Anyway this is just a heads up just encase you run into something like this in your travels. 

SSL Certificate Template not showing up on Active Directory Certificate Services web page

In a previous Post I mentioned an issue that I had with a Certificate template on my Internal Enterprise CA not showing up when I tried to request a certificate.

After doing some digging I discovered that I had it set the template to “Build from this Active Directory information” when it should have been “Supply in the request” to make it show up in the list. 
So what you need to do is open the Certificate Template Console on your CA, and double click on the template that you need to have show up. Go to the “Subject Name” tab you will see this

Select Supply in the request and click OK.
If the template is already being served on your CA you will need to Delete it from the Certificate Template folder and re-add it in the same folder.