You still got time

28/06/2015

As you may have heard, on 30 June 2015, the last minute of the day 23:59 UTC will last 61 seconds instead of 60 seconds. The reason for this leap second is to sync time with the rotation of our Earth. The previous leap second was added in 2012, websites like LinkedIn, Mozilla and Reddit went down due to this leap second.

20150628_01Figure 1

Because a progressive number of computer systems rely on time synchronization, this means extra work for System Administrators (that will take much longer than 1 second). On the other hand there is also a lot of discussion; are leap seconds really useful in a world that relies on computer systems?

That brought me to the question; “Are VMware products affected and what can we do to prevent misery?”

Read the rest of this entry »


About update levels and build numbers (VMware)

31/05/2015

You are working on a project, e.g. installing the latest VMware Horizon View on a vSphere 5.5 Platform. The VMware Product Interoperability Matrixes can help you determine which versions of ESXi are compatible with View.

20150531-01

This is not the best example, as this version of View runs on almost all version of ESXi, you might see the issue, as ESXi presents no update levels, just build numbers. So how do you match Update levels to Build numbers?

Read the rest of this entry »


Implementing CA signed SSL certificates with vSphere 5.x – Part 5– ESXi and Automation

25/05/2015

In the previous posts, we discussed the need for certificates, how to obtain certificates, implementing certificates on a vCenter Server Appliance, vCenter Update Manager server and finally a vCenter Orchestrator Appliance. Although there are more vSphere components, we conclude with the implementation of certificates for ESXi hosts.

ESXi hosts

The configuration of CA certificates is explained in KB “Configuring CA signed certificates for ESXi 5.x hosts (2015499)”. Most important remark in this KB; “Each server must be unique to the component as it ties to the fully qualified domain name of the server. As such you cannot just take a single certificate and apply it to all hosts. Wildcard certificates are currently not supported, but even if they were, it is much more secure to have a proper certificate for each host.”

To create a certificate request for multiple ESXi servers, you can follow the procedure as describes in KB “Configuring OpenSSL for installation and configuration of CA signed certificates in the vSphere environment (2015387)”.

Read the rest of this entry »


Implementing CA signed SSL certificates with vSphere 5.x – Part 4 – VUM and vCO/vRO

19/04/2015

In the previous post, we discussed the replacement of SSL certificates in the vCenter Server Appliance. Following our planning, next on the list is the vSphere Update Manager and the vCenter Orchestrator Appliance.

vSphere Update Manager

Our guide is “Configuring CA signed SSL certificates for vSphere Update Manager in vCenter Server 5.1 and 5.5 (2037581)”.

One important note from this KB: “You can replace only the SSL certificates that Update Manager uses for communication between the Update Manager server and client components.
You cannot replace the SSL certificates that Update Manager uses on port 9087 when importing offline bundles or upgrade release files.

KB 2037581 resumes at the point where we ended in Part 2, and created the required SSL certificates.

Steps:

  • Assuming the VUM is a VM, create a snapshot before you start working.
  • If you haven’t already done this, import the root certificate Root64.cer into the “Trusted Root Certification Authorities” Windows certificate store. This ensures that the certificate server is trusted from now on.
    SSL-04-01
    Figure 1
  • Backup the current certificates, location: C:\Program Files (x86)\VMware\Infrastructure\Update Manager\SSL directory.
    SSL-04-02
    Figure 2
  • Copy the new certificate files to this directory replacing the current ones. If you are following my blog posts, the certificates are located in C:\certs\UpdateManager.
  • Stop the vSphere Update Manager Service and the vSphere Update Manager UFA services from the services control manager.
  • Launch the exe application, located in C:\Program Files (x86)\VMware\Infrastructure\Update Manager.
    While using the VCSA, the VUM is always separated, so use the IP address or hostname of the vCSA. Use the credentials Update Manager uses to connect to the VCSA.
    SSL-04-03
    Figure 3
  • Click the SSL Certificate Link.
  • Select the Followed and verified the steps.
  • Click Apply.
    SSL-04-04
    Figure 4
  • Click OK when prompted with message “Restart the VMware vSphere Update Manager service to apply the setting”.
  • Restart the vSphere Update Manager Service and the vSphere Update Manager UFA services.

Read the rest of this entry »


Implementing CA signed SSL certificates with vSphere 5.x – Part 3 – vCenter Server Appliance

11/03/2015

In the previous post, we highlighted the default template needed, in case of an Organizational CA, and ended with the creation of the certificates needed for the vCenter Server components.

According to our compass KB “Implementing CA signed SSL certificates with vSphere 5.x (2034833)”, the next step is to replace the vCenter Single Sign-On certificate and it points us to KB “Configuring CA signed SSL certificates for vCenter Single Sign-On in vSphere 5.5 (2058519)”.

Unfortunately, we are in trouble now, as KB 2034833 refers to the Windows vCenter Server components, with no reference to the vCenter Server Appliance. We will return to this KB later, for the vSphere Update Manager.

Luckily, KB “Configuring Certificate Authority (CA) signed certificates for vCenter Server Appliance 5.5 (2057223)” is available for the vCenter Server Appliance. In fact this KB contains all steps for setting up OpenSSL, generating certificate requests, getting and implementing certificates.

The Script

In fact, we have reached the section “Installation and configuration of the certificates for all the components”. This 40 step long section contains a lot of commands. To overcome the differences and make the installation process easier, I have created a script which can be found in this post. Copy and paste the content in a notepad and save as vcsa_certs.sh.

Read the rest of this entry »


Implementing CA signed SSL certificates with vSphere 5.x – Part 2 – Obtaining Certificates

11/03/2015

Implementing CA signed SSL certificates with vSphere 5.x – Part 2

This is the second post in a series about implementing CA signed SSL certificates. The previous post provided some background and a few important questions to consider before taking off.

Until now, KB “Implementing CA signed SSL certificates with vSphere 5.x (2034833)” is our compass.

Creating a new default template

If you are using certificates from an organizational CA, like I am, the first step is to create a correct SSL certificate template for the Certificate Authority. Follow the directions in KB “Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 5.x (2062108)”.

The steps in this KB are straightforward. After creating a new default template, the new template needs to be added to the Root CA or Subordinate CA server. This new template should be used in place of the Web Server template.

There are a few important steps:

  • Create a duplicate of the Web Server
  • On the Extensions tab, Key Usage, make sure you select the Signature is proof of origin (nonrepudiation) option and the Allow encryption of user data
    SSL-02-01
    figure 1
  • On the Extensions tab, Application Policies, make sure you Add Client Authentication.
    SSL-02-02
    figure 2

Read the rest of this entry »


Implementing CA signed SSL certificates with vSphere 5.x – Part 1- Introduction

09/03/2015

Why certificates?

Almost all vSphere components, like ESXi, vCenter Server, vSphere Update Manager make use of SSL certificates. However, the certificates installed during the installation process are signed by VMware and are not verifiable and are not signed by a trusted certificate authority (CA).

SSL-01-01Figure 1

Also the vSphere Hardening Guide (for all components) recommends not using the default self-signed certificates for ESXi communication for all three profiles, because;
Using the default self-signed certificates leaves the SSL connection open to Man-in-The-Middle (MiTM) attacks. Replace default self-signed certificates with those from a trusted CA, either commercial or organizational.

The vSphere Hardening Guides recommends the following assessment procedure and if you need to replace SSL certificates points to a useful KB.

Connect to each ESX/ESXi host with an internet browser,
https:// <hostname>/. View the details of the SSL certificate; determine if it is issued by a trusted CA, either commercial or organizational. To change SSL certificates refer to KB “
Implementing CA signed SSL certificates with vSphere 5.x (2034833)”.

See figure 1, for a result.

The vSphere Hardening Guide points to the very useful KB 2034833, but it also becomes clear that it’s one of many KB s on implementing SSL certificates, and there are even more KB s not mentioned.
So, I was very curious how this would work out in a common vSphere Cluster.

Read the rest of this entry »


Follow

Get every new post delivered to your Inbox.

Join 383 other followers