My vSphere 6.7 homelab upgrade experience

vSphere 6.7 was released several months ago, and I’ve been meaning to upgrade my homelab for a while now. vSphere 6.5 has been pretty rock-solid, but it’s time for me to keep up with the Joneses. This post covers my upgrade process and experiences.

vCenter Migration

My original vCenter server was built straight on to version 6.5 when that first launched, way back when. In theory there was nothing wrong with it, except for a deployment decision that I was no longer happy with. When I deployed my vCenter previously, I configured it with an external Platform Services Controller (PSC) as I wanted to mess about with load balancing PSCs at the time. The messing around didn’t take long and I moved on to other things. Problem is, you cannot (currently) go from an external PSC to an embedded one and the external PSC was an extra piece of complexity that I just didn’t need anymore.

That pretty much left me with one option: migrate to a new vCenter.

Deploying vCenter is a doddle, and I won’t cover how that works. What I will mention though is how I moved my hosts and VMs across. The first step was to liberate one of my 6.5 ESXi hosts from the original cluster and add it to the new vCenter. At this time, I didn’t upgrade the host itself to 6.7 for reasons that will be apparent in a minute or two.

Secondly, I went through the VMs that I had registered in my original vCenter and weighed up whether or not I still needed them. Things like old distributed vRA deployments to a quick trip to the virtual bin, other things like AD, jumphosts, remote access solutions etc were powered down and removed from the inventory before being re-added to the new vCenter.

Before long, there wasn’t much left and what little is left will probably be left idle for a couple of weeks before I bin it completely.

So far, so good. Continue Reading

2

Root password expired on vCenter VCSA 6.5

I thought I’d update my homelab’s primary vCenter to the latest and greatest (6.5 update 1d), when I encountered an issue with the root password. The update showed up ok in the appliance’s VAMI interface and I selected to install it but an error quickly showed up:

VCSA 6.5 is not ready to be updated

Not ready, huh? When I clicked on the “Show Details” button, I saw a message informing me that the root password had expired or expiring soon:


VCSA 6.5 update is blocked by expired root password

Well ok, I’ll go and reset it and turn off the expiry I thought. (That process is covered in the vCenter documentation.) But noooo, permission denied! The password couldn’t be set and the expiry settings could not be changed. Continue Reading

0

Howto: Creating a CA template for VMware services

Having setup my lab’s PKI infrastructure previously, one of the next steps I needed to complete was to create a template for certificates for VMware’s products to use as they require certain properties to be present in the certificates used.

There is a KB article that covers this but I wanted to run through it and use some of the specifics for my lab.

Template for VMware SSL Certificates

This template will provide certificates for ESXi hosts, vCenter, vRA, vRO etc. To create it, we first need the Certificate Templates Console. This can be opened by running certtmpl.msc.

Per the KB article, I duplicated the “Web Server” template as a starting point. My first task was to give the template a new name and set the validity to 4 years:

20160256_150269-CapturFiles

On the Extensions tab, although it’s possibly not required for vSphere 6 (it is for earlier versions of vSphere), I added “Client Authentication” under the Application Policies option.

20160256_150243-CapturFiles

Again, it may not be universally required but I’ve added the “Signature is proof of origin” option under Key Usage (also on the Extensions tab.

20160256_150215-CapturFiles

Depending on the use case required, it might be useful to be able to export a certificate’s private key. I haven’t worked on View for some years but this option came in handy then. It’s configured under the Request Handling tab.

20160256_150270-CapturFiles

On the Subject Name tab, ensure that “Supply in the request” is checked.

20160256_150296-CapturFiles

That’s it. Just hit OK to save it.

Template for VMware VMCA

If you want to set up the VMCA as a subordinate certificate authority on a vSphere 6 Platform Services Controller, a slightly different type of certificate is required. I don’t think that I deviated from the KB article here except with the validity period.

20160256_150295-CapturFiles

20160256_150278-CapturFiles

“Publishing” the certificate templates

This is a fairly straightforward process accomplished using the Certification Authority Manager. Templates are added one at a time by right clicking on “Certificate Templates” and selecting New > Certificate Template to Issue.

20160256_160296-CapturFiles

Once published, the templates are available via the CA’s web interface for new requests.

20160256_150246-CapturFiles

0

Howto: Configuring a homelab online subordinate CA

A quick recap of where I got to. I have an offline Root CA (well, it’s still online because I’ll need it in a minute) and I’ve created a website on my online subordinate CA server to host the Root CA certificate and CRL files.

The purpose of the subordinate CA is to handle certificate signing and repudiation for all services in my infrastructure that require them. It will be granted the authority to do so by the Root CA. So this post covers the remaining steps of the process, which are:

  • Installing and configuring the subordinate CA
  • Signing the subordinate CA’s certificate using the Root CA
  • Delegating control of the subordinate CA to someone other than Domain Admins

Some elements of this process are very similar to the process of setting up the Root CA in the first place but there are some differences.

Installing the subordinate CA

As with the Root CA, I’ve done a lot of this via the command line. Other methods are available.

Using a powershell prompt on the subordinate CA, create and edit a CAPolicy.inf file using this command:

Insert the following text, taking care to make sure that the URL on line 8 is specific to your environment. It shouldn’t break things if it’s wrong but it’s just the location of the Certificate Practice Statement file.

There are fewer options used than for the Root CA.

To install the CA using these settings (make sure that the file is named “CAPolicy.inf” exactly, no extra file extensions), the following commands were used:

If you’re following this, change the CA’s common name (O11N-IssuingCA-01 in my case) to suit your environment. What you’ll see at the end of it though is a big yellow warning that the installation is incomplete. This is because the CA’s certificate now needs signing and issuing by the Root CA.

Requesting and signing the subordinate CA certificate

The warning text mentioned above tells you where the certificate request has been saved to. In my case, it was saved as C:\ca-01.o11n.lab_O11N-IssuingCA-01.req. This file must be copied to the RootCA to sign and issue the relevant certificate for the subordinate CA.

On the Root CA, the certificate request can be submitted using the command:

If it works, you’ll see that the request is now pending. Take note of the request number. (It was “2” in my case.)

20160256_120241-CapturFiles

To sign and issue the certificate, you need the Certification Authority tool. Find the request and Issue it.

20160256_120255-CapturFiles

The issued certificate can easily be exported using the following command:

The certificate then needs copying back to a temporary location on the subordinate CA. Once there, it can be installed and the certificate authority service started:

As a final step, copy the contents of C:\Windows\System32\certsrv\CertEnroll to C:\pki. It now looks like this:

20160256_120249-CapturFiles

Configuring the subordinate CA CRLs

As with the Root CA, I wanted to set up the distribution points for the CRLs to suit my environment.

The first step is to remove the existing points:

Next, I created three new CRL distribution points.

  • The first point is to a local file on the CA server:

  • The second point is to a web URL that is hosted locally on the subordinate CA:

  • The third and final distribution point is to the “pki” virtual directory:

 

Configuring the subordinate CA AIA settings

As with the Root CA, configuring the AIA settings is necessary.

As before, we’re going to clear out the original settings first:

Next, the “certutil” command is used to config a few default settings:

Finally, we restart the CA service and re-publish the CRLs.

That’s the online subordinate CA configured.

Configuring CA permissions

In a lab environment, particularly mine, it’ll be used be very few people. All the same, it’s a good practise to configure proper delegated security controls. After all, I don’t want to give every account Domain Admin access just so that they can request and issue certificates. To that end, I created a couple of Active Directory security groups that I used to govern access to the CA.

20160256_120242-CapturFiles

To use these groups, all that is required is to open the Certification Authority manager and open the properties for the CA. On the Security tab, I just added the groups and assigned them relevant permissions.

20160256_130298-CapturFiles

Next steps

Now that my lab PKI infrastructure is setup, one of the key tasks is to start using it! This means generating signed and trusted certificates for vSphere and vRA for example. For that, I might need to setup some certificate templates. If the web enrollment is to be used to do this, the Subordinate CA’s IIS website needs configuring with an SSL certificate. The instructions in this Microsoft article describes how that is done.

It’s important not to forget though that there are some remedial tasks to complete. Both the Root CA and the Subordinate CA could do with being hardened. The Root CA in particular needs to be kept safe and taken offline.

0

Howto: Configuring a homelab offline Root CA

Self-signed SSL certificates are all well and good but they’re not meant to be for the real world. The trust issues they cause can be a headache on customer projects and anything that’s going in to production shouldn’t be using them.

For that reason, I thought it’d be better to change my homelab so that it uses a slightly more realistic PKI setup. The first phase of that is creating an offline Root CA as it’s something that a good number of customers use too.

Step 1: DNS

From a DNS perspective, my homelab is split up so that anything physical and fundamental to the lab (e.g. storage / NAS, physical hosts, switches etc) lives in its own DNS domain (home.lab). Everything else from vCenter and AD downwards is in one or more other DNS domains and on separate VLANs etc. Now even though I’m planning to setup my Root CA as a VM, I’m going to keep it in the same DNS domain and the physical stuff because that seems to be a better fit for it.

So before doing anything else, I needed to create DNS entries for my Root CA on my NAS (which doubles as DNS master for the home.lab domain).

201511317_121100-CapturFiles

Of course, the idea of an offline CA is that it’s not connected to a network. For the installation and setup of it though, I want to make sure that it’s patched etc.

Step 2: Deploy a VM

This sort of thing is bread and butter really but it’s just a vanilla Windows 2012 R2 VM that is NOT domain joined but I have set up its network identity (name, DNS name and IP details) and connected it to a portgroup that my other lab infrastructure exists on.

201511317_121103-CapturFilesStep 3: Add the CA Role

Rather than including blow-by-blow screenshots from server manager, my installation was performed through the command line as much as possible. The first step is creating a configuration file.

Using a powershell prompt, create and edit a CAPolicy.inf file using this command:

Insert the following text, taking care to make sure that the URL on line 8 is specific to your environment. It shouldn’t break things if it’s wrong but it’s just the location of the Certificate Practice Statement file.

When the CA is installed using the .inf file above, its certificate will be valid for 20 years and the validity of the CRL will be 26 weeks.

To install the CA using these settings (make sure that the file is named “CAPolicy.inf” exactly, no extra file extensions), the following commands were used:

If you’re following this, change the CA’s common name (O11NRootCA in my case) to suit your environment.

Step 4: Configure CRLs

By default, this CA will publish its Certificate Revocation List (CRL) in locations that aren’t useful as the server will be powered off for most of its life. Therefore the CRL distribution points needed reconfiguring.

The first step is to remove the existing points:

Next, I created two new CRL distribution points. For both, “%3%8” will be substituted by the CA with the CA’s name and the CRL Name Suffix values:

  • The first point is to a local file on the CA server:

  • The second point is to a web URL that I’ll host on another server later:

The second distribution point will be added to the CA’s certificate so that other servers know where to get the CRL from.

Step 5: Configure AIA

Authority Information Access locations are URLs that are added to a certificate in its authority information access extension. These URLs can be used by an application or service to retrieve the issuing CA certificate.

As before, we’re going to clear out the original settings first:

Next, the “certutil” command is used to config a few default settings:

Finally, we restart the CA service and re-publish the CRLs.

That’s the offline Root CA configured. If you look at the C:\Windows\System32\CertSrv\CertEnroll folder, you’ll see the CRL and CA certificate files. It’s a good idea to copy these off the server as they’ll be needed to configure an online subordinate CA. I’ll cover that off in the next post.

20160256_080217-CapturFiles

0

Synology DS1513+ Released

DS1513+The Synology DS1512 has been a popular choice for many home labs in recent years. I hoped that the company’s raft of recent product updates would reach this model eventually. Well my wish was granted as Synology have announced the DS1513+.

There are a few modifications to note. The one that stands out the most at first glance is the doubling of LAN capability.  The DS1513+ boasts no fewer than 4 RJ45 ports. That does seem like quite a lot. It does open up some interesting possibilities though…

The full specifications for the DS1513+ can be found here.

0

Get Your Homelab in the Clouds with AutoLab

screenshot327Since we have a small but significant following of people who run home labs here on vSpecialist, I thought I’d mention a limited offer that may be of interest.

If you’re not familiar with AutoLab, it’s designed to produce a nested vSphere 5.1, 5.0 or 4.1 lab environment with minimum effort. Prebuilt Open Source VMs and the shell of other VMs are used along with automation for the installation of operating systems and applications into these VMs with the end result being a useful home lab that you can stand up from scratch in a short amount of time.

Anyway, it’s possible to get an AutoLab setup and running in the cloud and BareMetalCloud actually offer it as a service. Mike Laverick has some discount codes available (use MAGICMIKE100) to the first 100 people to take up the service. Check out his post on the topic for more details and help on getting started.