RSAT MMC CA “Install CA Certificate” Bug

I plan on releasing a 3 part series blog post on configuring a new CA infrastructure, in an existing one where an Enterprise root CA has already been configured. In my series I decided to utilize core servers, these provide an additional layer of issues as managing them is a little more difficult as it usual requires more cmd based knowledge or better yet PowerShell whenever there are such options available. Turns outs in this case even more so then ever.

I won’t go over too much details here, as I’ll save that for my series. Basically one step requires me to import the signed certificate into the Sub Enterprise CA, being core I have to use the RSAT MMC CA snap-in (funny enough even if you have desktop experience it’s the same tool and snap-in used).

What I discovered is when I’d use the RSAT tool on and remote client system loading my actual CA server when loading the nap-in, it would never actually load the input wizard.

I’d right click my CA, select the option to install a CA certificate:

Then it simply act as if it’s reloading the snap-in…

Then nothing… So I asked about it on Technet. Lucky for me Mark Cooper the Master PKI guy came to my rescue.

The solution: On the Sub CA

certutil -installcert <your certificate file name here>

Spectre Meltdown

If you’re reading this then chances are more than likely you’re looking up information on the two biggest vulnerabilities to be announced since Heartbleed.

Now there is just a ton of people talking about these vulnerabilities, I’m going to try and avoid all the real technical mumbo jumbo.

First things first… are you affected?!

*Shakes 8 ball* Most Likely.

Now you might be wondering, “How can that be?!” Well first let’s talk about Meltdown. Meltdown apparently affects Intel chips only. In short it’s a weakness in memory handling with the CPU. Do you have an Intel chip running your computer? chances are more than likely, running Windows? Well you’re in luck, Microsoft is making sure your OS is safe, but at what cost? Maybe a slower system than ever… no AMD then? well OK you may be safe from Meltdown, but you’re still vulnerable to Spectre, and guess what? Microsoft isn’t able to help you get patched either, well apparently if you happen to be running an old AMD chipset.

Not sure how well Intel will do following this, but the odd shares sales by the CEO def don’t look like good signs…

Alright, now back to Spectre.

Well to start off, to say it simply… never assume, it makes an ass of of you and me. Now you’ve probably heard this saying before, and you probably might be wondering why I’m even saying it. Well this vulnerability revolves around the CPU’s algorithm (Speculative Execution) to assume a result based on repetition of previous outcomes of the same operation.

Crazy how these are totally physical based vulnerabilities (At the CPU chip) which affects them all going back super far.. how far back? Well i had to dig a lil deeper into the interwebs via google. (So they know what I’m all about lol). and discovered that the Pentium Pro was the first. Now I’m simply going on the authors words here, but finding sources from so long ago even today can be rather difficult so I’ll simply take his word for it. The blog is actually a great read and covers the aspect of the vulnerability very well. However he goes on to say it’s all about Meltdown, when it might be about Spectre?

Either way… it’s a Spectre Meltdown.

If anyone’s running a HP Spectre laptop with an Intel chipset, and it starts melting down. That be quiet the coincidence. 😛

Happy hacking! Start writing some javascript based if code to exploit these assuming chips 😉

Renewing expired certificates on vCenter 5.5

Do you follow best practice? Have you setup a VMware HA cluster with vCenter. Do you have your own PKI and certificates? Did you not have active monitoring on said certs? Then chance are you are in the exact same boat as me! This blog post assumes you are well advise in using the SSL Cert Automation Tool as well as creating certificates for use with the tool.

This one begins on a Monday after the weekend. I was getting alerts of failed backup jobs. I managed to configure Veeam at my work place and have been happy with the product and support from day 1. I also configured a cold site for backup retention in the event our primary site, you know…. implodes. Anyway, I was used to getting “failed” alerts when really there was simply a communication hiccup across my IPsec tunnel, which usually the job would complete successfully and just report the error. This time however it was different, the errors were for normal backup jobs and reported “incorrect username and password.” I knew the service account’s password, used by Veeam, never expired or changes. Instantly telling me something else is wrong. I then attempt to login into vSphere connecting to my vCenter server, and sure enough it says the same thing wrong username and password, to which another notice pops up saying all communications are untrusted due to expired certs. Doh!

At this point you’ll probably have done exactly what I did… check your installation documentation right?!?! I mean if you are running custom certs, I’m assuming you follow other best practices such as documenting. :P. But after that you are probably googling once you discover part of the SSL tool are not working!

Chances are you came across VMwares KB on renewing certs on a 5.5 version instance of vCenter only to discover that at step 5 a) that the tool reports the local machine doesn’t have the SSO service installed. This really comes down to what the “tool” really is, and that’s a batch script. Yeah you read that right a BATCH script, so you could imagine how ugly and how painful that must have been to code. Like seriously 5.5 was released in Sept 2013 and they were coding using PowerShell by then… shame on you VMware. Anyway, the most likely problem here is in the way this batch script actually checks for the installed service (I looked at the source code of the “tool” but I didn’t actually locate the part that handles this and I’m strictly making assumptions here) is that it probably has a more direct string to which it looks for, again assuming here a reg key or something of that nature and its probably using a version number to check against, if the version changes the script would reply a “can’t find this”. and thus you get the above error which you know is wrong. So how do you fix this, well you grab the exact version of the tool for the updated instance of vCenter you are on (this requires a valid VMware subscription to grab the version of the tool you need). I managed to update one form post in hopes it helps others at this stage of the game.

At this point I kept following through the tutorial, just an FYI I was going through all this with a VMware tech support, and they had to get another tech who specialized in these cases. I came across other issues as well such as in Step 5 d) I got a error similar to this. Sadly I’m writing this up several days after the event so I can’t remember what exactly we did to recover from this one.
At this point gotta keep pushing through the KB which has a total of 24 steps, so you could imagine how painful all this is to do. At the same time I’m not sure HA is even available, and all my backups couldn’t run and any management of VMs would have to be done manually till vCenter could be back up and running. I’ve talked to others and many people suggest to stick with self signed certs even though we all know its not best practice. Thanks VMware for making best practice really hard to implement and maintain.
Also at the very end steps I didn’t not actually have a listed service ID for web client but only the web logger, although you can have separate service ID instance for these, in my case I had to use the web logger service ID to complete the final step. Then after the Web Client wasn’t working properly which I fixed by reinstalling the service/feature via add/remove programs. The fact there is no repair option on this installer bugs me.

To Paraphrase to solution:

1) Ensure you are using the latest and correct version of the SSL tool *cough BATCH script*.
2) Create all your new certificates and chains.
3) Follow the KB article very carefully, specially when it says to do some steps manually vs using the "tool".
4) Google any errors along the way.
5) Bash your head in for following best practices.

Jan 2018 Updates

This brings back bad memories, It’ll soon be time to update to 6.5. We’ll see how VMware has handled internal PKI this time.

Full Remote Admin in Windows Domain

As an Windows Server administrator, you may find yourself wanting to run some commands or do some tasks on an end users system.
Theres an awesome tool package on MS site called sysinternals, developed by an awesome guy named Mark.
However, I was having issues accessing UNC paths until I provided the options for the admin creds,
even though the cmd prompt that was running the psexec command was already elevated with the same creds.
Then I was having issues accesses local system files until I discovered the -h option.

To have full CMD on remote systems:
“psexec \\remotesystem -u domain/adminaccount -p passowrd -h cmd”

The -h is important as it pushes for an elevated token on Vista+ systems.

XCopy source destination /e /i /h (Copy all hidden and system files for profile use)

/e copy directories and subdirectories, including empty ones

/i assums directory on destination if copy more than one file and does not exist

/h copy hidden and system files

Now you can move all your Firefox settings, IE settings, and more remotely!

Jan 2018 Update

Use Robocopy, or better yet; PowerShell, instead of xcopy.