Home > Blogs > Support Insider > Tag Archives: SSL

Tag Archives: SSL

View Composer DiskFault: Disk customization failed due to an internal error

There’s a glitch some customers are encountering  whereby a Linked Clone desktop is created on vCenter Ok, but is deleted soon after vCenter complains about either “disposable” or “internal” .vmdk files this desktop. Creating and recomposing linked clone desktops fails on VMware Horizon View 6.1.x and all older releases after you have applied an upgrade patch.

On View Administrator, recomposing of pool fails with the error:

View Composer DiskFault: Disk customization failed due to an internal error

This issue occurs when older versions of Horizon View Composer prior to VMware Horizon 6.2 attempt to communicate with VMware ESXi hosts, but SSL v3 is disabled beginning in VMware ESXi 5.5 Update 3b and 6.0 Update 1 hosts.

We’ve created a KB article to address this scenario here: Linked Clone pool creation and recompositon fails with VMware Horizon View 6.1.x and older releases (2133018)

Note: There is a workaround provided in the KB but it is not advised to use it. The workaround makes the VMware ESXi 5.5/ 6.0 hosts vulnerable to security threats reported for SSL v3

What’s New in vSphere 5.5 Update 3b

noticeSSLv3 Protocol Disabled by Default


Across the industry, enterprise software products and solutions are dropping use of and support for the SSLv3 protocol. The Internet Engineering Task Force (IETF) officially deprecated the SSLv3 protocol in RFC 7568 due to its obsolescence and inherent unfixability. Instead, IETF recommends the latest version of TLS.

VMware is therefore dropping support for SSLv3 on both the server side and the client side in vSphere. The release of vSphere 5.5 Update 3b from VMware disables SSLv3 by default to meet current standards and compliance.

Disabling SSLv3 by default also brings some restrictions with respect to installation, upgrading, and compatibility. This blog summarizes these limitations which are also documented in detail in the respective release notes and KB articles.

Below are some of the key aspects that you should be aware of when you upgrade to vSphere 5.5 Update 3b

  1. Upgrade sequence: As recommended in KB 2057795 you must upgrade vCenter Server to 5.5 Update 3b first and then update the hosts to ESXi 5.5 Update 3b.

Earlier releases of vCenter Server won’t be able to manage ESXi 5.5 Update 3b. As a workaround, you can re-enable SSLv3 protocol on ESXi by following the configuration described in KB 2139396. However, VMware strongly recommends against re-enabling the SSLv3 protocol.

  1. Upgrade both vCenter Server and ESXi to 5.5 Update 3b: In order to disable SSLv3 completely in your vSphere environment, we recommend that you update both vCenter Server and ESXi to vSphere 5.5 Update 3b.
  2. View Composer earlier than version 6.2 will have connection failures with ESXi 5.5 Update 3b. Refer to KB 2121021
  3. SSLv3 can be re-enabled by the configuration described in KB#2139396. Re-enablement of SSLv3 protocol has to be consistent across all ESXi and vCenter Server services and require mandatory service restart. However, VMware strongly recommends against re- enabling the SSLv3 protocol.

Note: Hostprofile will be able to capture SSLv3 protocol enablement configuration changes for all the services except Hostd service in ESXi.

Issuing a 3rd party SSL certificate to vCenter while using vSphere VMCA to issue certificates to ESXi

This is the second video for today which was produced in conjunction with Mike Foley who is a Senior Technical Marketing Manager at VMware. These videos should be of some help to those of you that are faced with SSL certificate creation tasks relating to vSphere 6. This video discusses and demonstrates Issuing a 3rd party SSL certificate to vCenter while using vSphere VMCA to issue certificates to ESXi which should be of special interest to anyone who has ever asked the question “How do I replace the “external” SSL certificate of vCenter but still use VMCA in default mode?”

Mike has provided additional information and context around this exact topic over on his blog here.

How to create a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6

Today we have two new videos that we produced in conjunction with Mike Foley who is a Senior Technical Marketing Manager at VMware. These videos should be of some help to those of you that are faced with SSL certificate creation tasks relating to vSphere 6. This first video is based on VMware knowledge base article Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.0 (2112009) and it discusses and demonstrates how to create a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.

After watching this video tutorial you should be comfortable with configuring Microsoft Certificate Authority (CA) templates for use with custom SSL certificate implementation in vSphere 6.0.

Mike Foley has published additional information around this very topic over on his blog here.

SSL certificate issues in VMware Horizon View

SSL certificate issues in VMware Horizon ViewHorizon View Administrators continue to open support requests with issues surrounding SSL certificates in the product configuration. Nobody really enjoys setting up SSL and all the other security aspects that go along with it – it’s a necessary evil. Maybe that explains why, when running into issues with it, the first reaction is to get VMware on the phone. After all, doing a Google search on the topic returns scads of content on the topic.

Here’s what we’re doing about it. We have a troubleshooting KB article, written by our support engineers, to cover all the common configuration issues: Troubleshooting SSL certificate issues in VMware Horizon View 5.1 and later (2082408)

The same engineer suggested we also share this KB, as it also touches a good majority of cases we see coming in:  Generating and importing a signed SSL certificate into VMware Horizon View 5.1/5.2/5.3/6.0 using Microsoft Certreq (2032400)


KBTV Webinars – SSL certificate handling in VMware vSphere 6

Continuing on with our current series of KBTV Webinars, here we have the tenth webinar titled SSL certificate handling in VMware vSphere 6 and it goes through what has changed since the vSphere 5.5 product release and what is new in vSphere 6.

Generating and Troubleshooting SSL certificates in View

VMware View SecurityNext up in our series of VMware View topics, we’re going to talk about security. I spoke with a couple of our top support engineers about View security and they identified three Knowledgebase articles that solve more support requests than any others in the area of security, namely SSL certificates.  They recommend customers use:

In View 5.1 and later, you configure certificates for View by importing the certificates into the Windows local computer certificate store on the View server host. By default, clients are presented with this certificate when they visit a secure page such as View Administrator. You can use the default certificate for lab environments, and one could even make the argument that it is OK for fire-walled environments, but otherwise you should replace it with your own certificate from a trusted CA (Verisign, GoDaddy, others) as soon as possible. They also told me you should use an SSL certificate from a trusted CA when setting up a Security Server for your environment when the Security Server can be used from outside your firewall (Internet) to access View desktops inside your firewall.

My engineers stressed to me the importance of following each step in these KBs one at a time when you are filling out the forms on those sites to obtain your certificate. It is easy to make a mistake and you might not receive something that will work for you.

Note: The default certificate is not signed by a commercial Certificate Authority (CA). Use of noncertified certificates can allow untrusted parties to intercept traffic by masquerading as your server.


Patching ESXi 5.5 for Heartbleed without installing Update 1

On April 19th, VMware released a series of patches for ESX 5.5 and ESX 5.5 Update 1 to re-mediate the CVE dubbed “Heartbleed” (CVE-2014-0076 and CVE-2014-0160).

VMware also recently announced that there was an issue in the newest version of ESXi 5.5 (Update 1 and later), which can cause difficulties communicating with NFS storage. This NFS issue is still being investigated, and customers are encouraged to subscribe to KB article: Intermittent NFS APDs on ESXi 5.5 U1 (2076392) for updates.

Due to the confluence of these two unrelated issues, you might find yourself trying to patch ESXi to protect yourself from the Heartbleed vulnerability, while at the same time trying to avoid installing ESXi 5.5 Update 1.

Here is the information from the VMware Knowledge Base on the topic:


The note at the bottom is the key. Stated simply, if you are…

  • Using NFS storage
  • Concerned about patching to Update 1 due to change control
  • Not already running ESXi 5.5 Update 1 (build-1623387)

… then you should patch your install for the Heartbleed issue and at the same time stay at ESX 5.5 by applying Patch Release ESXi550-201404020, and not ESXi550-201404001.

An Explanation of Patch Release Codes

To better understand the Patching process in a VMware environment, it is valuable to understand the codes which are used in VMware Patch Releases.

When VMware releases a patch, or a series of patches, they are bundled together in what is known as a Patch Release. A Patch Release will have a coded name which is formed using the following structure. I have added braces to demonstrate the different sections better in each example.


For example, the patch release for ESXi 5.5 that was released in January 2013 would be coded like this (without the explanatory braces):


As part of a Patch Release, there will be at least one Patch. Each Patch is given a Patch (or Bulletin) ID. Patch IDs are similarly structured to Patch Release codes, but also have a two letter suffix. For Security Bulletins, the prefix will be SG. For Bug Fix Bulletins, the prefix will be BG.

For example, the two Patch IDs which were released to patch Heartbleed are:


Note that the only difference in the Patch IDs here is in the three digit release number (401 vs 420).

Patching with VMware Update Manager

There are a number of methods for patching ESXi hosts, and the most commonly used is VMware Update Manager (VUM). VUM will present a pair of Dynamic Baselines which will be automatically updated when patches are available. The danger in this case is that VUM may show you both the Pre-Update 1 patch, as well as the Post-Update 1 patch. If you are not careful as to which patches you apply, you might accidentally end up patching your host to Post-Update 1.

Here are the patches which were released on April 19th, as seen in VUM. The Update 1 patch is highlighted in red, while the Pre-Update 1 patch is marked in green.


Note: VMware also released two other ESXi 5.5 patches on April 19th, as part of Patch Release but these are not related to the Heartbleed vulnerability in any fashion. (ESXi550-201404402-BG, and ESXi550-201404403-BG).

Creating a Fixed Baseline

Patching a host using ESXi550-201404420-SG (Pre-Update 1), while avoiding ESXi550-201404401-SG (Post-Update 1) requires the use of a Fixed Baseline in Update Manager.

  1. Start in the Update Manager Admin view.
  2. Select the Baselines and Groups tab.
  3. Click Create… in the Baselines column.
  4. Give the new Baseline a descriptive Name (and optionally a Description).
  5. Click Next.
  6. For Baseline type, select Fixed.
  7. Use the Search feature to find the only Patch we want to apply. You will need to select the Patch ID option from the dropdown menu to ensure the search scans for the appropriate column.
  8. Enter the Patch ID into the search field: ESXi550-201404420-SG and click Enter to search.
  9. Select the Patch which shows up in the filtered list, and click the Down Arrow to move it into the selected Baselines.
  10. Click Next and confirm that the Patch ESXi550-201404420-SG is the only one selected.
  11. Click Finish.

The Baseline is now created and available for use.

Remediating a Host using the Fixed Baseline

Once the Fixed Baseline has been created, we can use it to Scan and Remediate an ESXi host.

  1. Select the host you wish to patch, and place it into Maintenance Mode.
  2. Click the Update Manager tab.
  3. Make sure that there are no Dynamic Baselines attached to the host you wish to patch. Detach any baselines which are currently attached:
    Critical Host Patches (Predefined)
    Non-Critical Host Patches (Predefined)
    Any other Custom Baselines which you have created
  4. Click the Attach link.
  5. Select the newly created Baseline and click Attach.
  6. Click the Scan link and make sure Patches and Extensions is selected. Click Scan again.
  7. When you are ready to patch the host, select Remediate.
  8. Complete the Remediation wizard.

Once the host is patched, it will reboot automatically.

Patching an ESXi host manually via the command line

Another option to patch an ESXi host is to use the esxcli command line tool. The patch files required are the same. For more information on how to proceed with this route, refer to the vSphere 5.5 Documentation under the heading Update a Host with Individual VIBs.


Author: Andrew Lytle
As a member of the VMware Mission Critical Support Team, Andrew Lytle is a Senior Support Engineer who is specializes in vCenter and ESXi related support.

ALERT: Response to Heartbleed OpenSSL security issue

heartbleedThis week, a new vulnerability was discovered affecting SSL, a protocol most of the Internet uses to encrypt and secure communications. The VMware Security Engineering, Communications, and Response group (vSECR) is investigating the OpenSSL issue dubbed “Heartbleed”. For information on which VMware products may be affected and resolution/remediation steps, refer to the two KB articles at the bottom of this post.

For the curious, we would like to quickly explain why this particular vulnerability could be a risk across the Internet. The bug — dubbed “Heartbleed” — allows anybody to read the memory on a system that is supposed to be protected by SSL.

An anonymous attacker could potentially steal any information from an SSL-secured communication when the issue is not addressed. Best practices dictate that websites and web service providers should always use SSL-encrypted communication when dealing with sensitive information like usernames, passwords, and bank info. Heartbleed could breach that information to anybody who knows how to extract it without leaving a trace.

Upgrading vCenter Server Appliance 5.0.x/5.1 to 5.5

Here is a new vSphere video tutorial which demonstrates how to upgrade the vCenter Server Appliance from versions 5.0.x or 5.1 to that of version 5.5.

Before attempting the upgrade:

For additional information and additional instructions, see VMware Knowledge Base article Upgrading vCenter Server Appliance 5.0.x/5.1 to 5.5 (2058441).