Wednesday, June 20, 2018

vmkping Error: Unknown Interface

In the middle of troubleshooting an issue with vMotion traffic failing, I ran into an annoying issue with vmkping: attempting to specify certain vmkernel interfaces as the traffic source would throw an error like the one below.

What's annoying about this is vmk4 is not unknown. It's tagged for vMotion traffic.

After some googling, I learned that using a poorly-documented argument will allow vmkping to work properly. If you've run into this issue, add ++netstack=vmotion to your vmkping command. You'll get the results you were expecting the first time around.

Incidentally, if you've ever posted screenshots of your ESXi host's ssh session and blurred out the hostname for SECURITY purposes: don't do that. Instead, change the prompt by modifying /etc/profile.local. William Lam has a years-old post here (note that what he suggested years ago has been implemented as default config). Much cleaner presentation this way.

Wednesday, January 24, 2018

UCS Manager: Failed to Split Certificate Chain

So now that we're in the era of turn-everything-into-a-web-app management, you're spending time with the shiny new HTML5 UCS Manager application. We've come so far from the early days of UCS, 1.x and early 2.x releases that felt like .01alphas. If you suffered the indignities of the java-based version, I feel you. Those were dark times.

The HTML5 interface is a sight for sore eyes. And if you're using 3.1(3b) as you should be (I started this post a long time ago, apparently), you've got a stable, responsive environment in which to create and apply policy to your servers. I'd never call managing anything in IT "fun," but managing things in UCS Manager is at least not "not fun." High praise, I know.

But you hate that it's using a self-signed cert. You have a CA (or at least you have access to one) and you'd like to issue a trusted cert to make Chrome and Firefox and modern browsers of all sorts stfu about missing subjectAltNames. So you set about the process of requesting a new certificate, and then you try to import the cert into UCS Manager. You set up a Trusted Point, copy the certificate chain into the too-too-tiny window, and save. So far, so good. But when you paste in your cert and associate it with the Trusted Point, you get an error complaining about not being able to split the certificate chain. It looks like this.
No SSL for you!

Sometimes, this issue is easily solved by making sure that you've included the full certificate chain in your trusted point config. And since it's not obvious what you're supposed to do there, here's a tip: you have to copy and paste your certs into the same window.

But here's the rub: if you are certain you've correctly imported your cert chain and you're still getting errors about splitting the certificate chain, it's because you failed to fill in the Subject: field in your CSR. Trust me.

Historically, subjectAlternativeNames have been optional, or rather, optionally implemented. The notion of a subjectAlternativeName has been around for decades, but it wasn't until last year when browser developers started requiring a sAN to avoid the dreaded SECURITY WARNING message that we've all learned to subconsciously ignore. And by browser developers, I mean Google, makers of Chrome, the browser we fell in love with a decade ago and now hate as much as we hated IE4 when it killed Netscape Navigator.

But back to the point: you're getting this error because you didn't include a subjectAlternativeName in your certificate. So just go back and generate a new CSR from UCSM with the "Subject" field populated with the FQDN of your UCSM, and send that to your certificate authority. Then copy and paste the new cert, bask in the glory of a successful import, and browse to UCSM error-free, even from Chrome.