Issuing certificates for VMware Horizon View 5.2 servers with Microsoft Enterprise Certificate Authority

I’ve recently been asked quite a few times in over the last few months on how to properly request and issue certificates for VMware View servers ever since the later versions of 5.x began throwing warnings when servers are using their default self-signed certificates and not a certificate that is issued by a trusted certificate authority such as an internal Microsoft Enterprise CA or a public CA such as GoDaddy, Verisign, etc.  I’ve always suggested using a public CA simply because mobile devices don’t natively trust certificates issued by an internal CA and because it’s not a domain joined device, there is really no automated way to place the internal CA’s certificate into the trusted store.  With that being said, if you don’t have any mobile or non-domain joined devices in your environment, you can use an internal Microsoft Enterprise CA for your View connection server certificates.  The following demonstrates the process:

Upon successfully deploying your View Connection servers (both internal and external), you will noticed that the dashboard lists all of them with an error:

… and clicking on the server object will display the error:

Name: <serverName>

Version: 5.1.2

Status: Server’s certificate does not match the URL.

SSL Certificate: Invalid

Connections: 0

Before I begin demonstrating using a Microsoft Enterprise Root CA to issue the certificates, note that the official VMware View documentation for obtaining SSL certificates can be found in the following URL:

Obtaining SSL Certificates for VMware Horizon View Servers
http://pubs.vmware.com/view-52/index.jsp?topic=%2Fcom.vmware.view.certificates.doc%2FGUID-358E1A54-DDD7-4A76-B9CB-198E0F7F76D4.html

… another old KB article that is more specific to using a Microsoft CA to obtain a certificate can be found here:

Managing SSL Certificates in VMware View 5.1 using an internal Microsoft Certificate Authority (2020913)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2020913

With the location of the official documentation out of the way, the certificate I intend on issuing will contain the common name:

• vdi.domain.com

… and the following SAN entries:

• vdi.domain.internal
• vdi
• svrvmvc01.domain.internal
• svrvmvc01
• svrvmvc02.domain.internal
• svrvmvc02
• svrvmvce01.domain.internal
• svrvmvce01
• svrvmvce02.domain.internal
• svrvmvce02

By requesting a certificate with all of these names, I can simply use one certificate for all of my servers (2 internal and 2 external View connection servers).  I get asked a lot about why I like putting the NetBIOS name in certificates any reason is that I’m quite lazy when it comes to typing in the URL for servers as I tend not to use the FQDN in most cases unless my laptop is not a part of the domain or if the DHCP servers do not issue the suffix for a domain. While I can’t speak for others, my guess is that there are probably others like me out there and since we don’t pay extra for having additional SAN entries when issuing certificates from an internal private CA, why not put them in?  What’s also important to note is that Certificate Authorities (CAs) have accepted worldwide guideline changes and will no longer issue SAN SSL Certificates that are not in a legitimate FQDN format as of November 2015.  I found out about this a few weeks back when trying to issuing a 3 year GoDaddy certificate with NetBIOS names so keep that in mind when planning your certificate.

Begin by logging onto one of your View Connection server, open the MMC console and add the Local Computer store’s Certificate snap-in:

Right click on the Certificates node under Certificates (Local Computer) –> Personal –> Certificates and select All Tasks –> Request New Certificate:

Click on Next:

Select Active Directory Enrollment Policy and click Next:

Note how I have a Web Server Exportable certificate template in the list which is a duplicate of the Web Server template but with the Private Key is Exportable enabled.  The reason why this is important is because we will need to export this certificate to other servers so proceed with select the certificate and click on the More information is required to enroll for this certificate. Click here to configure settings. link:

The following Certificate Properties window is where we enter the information required for the certificate:

You don’t necessarily have to fill in all of the attributes but the following are the fields that I usually fill in:

E = tluk@domain.com

CN = vdi.domain.com

OU = IT

O = Company

L = Hamilton

S = Hamilton

C = BM

Adding SAN entries is simply selecting the DNS as the Type under the Alternative name section:

With the Subject tab for the Certificate Properties filled out, proceed with clicking on the General tab and type in vdm as the Friendly name.  Note that this field MUST contain vdm or your View connection servers will not use this certificate. 

Clicking OK in the window above will complete issuing of the certificate to the server:

With the certificate now in the local computer store, test the certificate by restarting the VMware View Connection Server service:

Log back into the administration console:

Note how the server with the certificate is now labeled with a green square indicating the error is gone:

Note that if you continue to see a red square complaining about the certificate, check the certificate properties and ensure the friendly name has the string vdm:

Now that we’ve confirmed the certificate works, proceed with exporting the certificate with the private key:

Make sure you export the private key:

Export as a PFX file:

Then copy the PFX file to the other VMware View Connection servers and import it:

Restart the services on the server:

Note that it may also be necessary to restart the other servers as well to update the error:

Hope this helps anyone looking for information on using a Microsoft Enterprise CA to issue certificates for VMware View connection servers.