With the new version of VMware View 5, the vendor has changed the way the virtual desktop infrastructure (VDI) product handles Secure Sockets Layer certificates that are commonly used to verify the identity of the View Connection Server to which the user connects.
Tightening security in VMware View 5
In previous releases of View, IT pros would just use the built-in certificates generated by the product installation, but VMware View 5 introduces a more rigorous check on the validity of the certificate. Like most modern Web browsers do, it warns the user if there is a problem (see in Figure 1 below where end users receive connection warning). This new check is implemented across all the clients including the new Apple Mac OSX client that was released in December 2011.
IT administrators use the SSL certificates to secure network traffic. By using fully trusted certificates, IT professionals can reduce the amount of pop-ups and warnings that end users get when they log on, which makes the process of accessing desktops and applications smoother and simpler.
By replacing the built-in certificate with one that matches the name of the Connection Servers, the connection process is simplified. It involves generating a certificate request file for submitting to an online certificate authority. The request is submitted with the OpenSSL keytool utility that is available on any Connection Server.
Before you run the utility, here is some information you’ll need before you begin:
- the fully qualified domain name (FQDN) of the URL used by the end users to connect. I’ve been using view.corp.com. Confusingly, keytool suggests using your first and last name when, actually, you should type the URL of your VMware View 5 VDI environment.
- your department and organisation;
- your location, including your town or city, county and country. The “country” column must be in the form of a two-letter country code that corresponds to ISO standards. For example, in the United Kingdom, instead of UK, you would use GB for Great Britain. If you are in the US, double-check your state name is in the correct format.
Steps for creating the request
To create the request, open a command-prompt on the Security Server and then use the Java-based keytool command to generate a certificate request file.
- Open a command prompt on the View Server and use cd\ to locate yourself at the root of C:
- Type the command as seen in Figure 2 below:
keytool -genkey -keyalg "RSA" -keystore keys.p12 -storetype pkcs12 -validity 360
- In the next step, users can create the certificate request file. Users can safely send to a root certificate authority (CA) and request that their private key can be trusted by the root CA. This means that users must at no stage transfer the private key to anyone external to the organisation. The certificate signing request (CSR) file is a helper file that assists in the process of having a private key stamped for approval.
keytool -certreq -keyalg "RSA" -file mycertrequest.csr -keystore keys.p12 -storetype pkcs12 -storepass vmware
Now, two files have been created in this process: one called keys.p12 that is protected and not human readable and the mycertrequest.csr file, which is text-based and is viewable using a Microsoft type command.
Submitting the request
The next step is to submit the request to a certificate authority; you can upload this certificate request using HTTP forms or copy the text from Begin New Certificate Request toEnd New Certificate Request (as shown in Figure 3) and then paste the string into an edit box on a form.
Many commercial certificate authorities allow you to generate a temporary test certificate that expires within a couple of days in the hope that you will later buy their services. Sadly, these certificates are often untrusted because they are merely for demonstration purposes (or, from the vendors’ perspective, marketing purposes which gives them a chance to spam your inbox with sales information). However, some commercial certificate authorities do allow a “test” root CA certificate to be installed.
- In the cmd prompt, use the Microsoft type command to output the contents of the CSR file.
- Select all the text, including the words Begin New Certificate Request -- and -- End New Certificate Request.
- Right-click and choose Copy.
- Go to the Thawte website and click the link that says “Free SSL Certificates”.
- Next fill in the Technical Contact page and click Continue.
- From the Select Server Platform list (see Figure 4), select the option “Server not listed”, and in its edit box type the string “VMware View 5”.
- Finally, in the Paste Certificate Signing Request (CSR), follow the regular Ctrl+V process for pasting.
- Accept the terms of the agreement and click “Submit”.
- Thawte will then generate your certificate and send it to the email address provided earlier (see Figure 5).
Important: When the email arrives it will contain two certificates. One identifies your FQDN for your View deployment (in my case view.corp.com), and the other will be a test root CA certificate and “Intermediary” CA certificate so your certificate will function properly during the 21-day evaluation period. Under normal operations, you would not need these test root certificates because they are pre-installed to most Web browsers and stored on the client computers certificate store.
- Next, create a new p7 file with Notepad at: c:\testcertificate.p7, and copy the contents of the field to this file, including the -- Begin certificate -- and -- End certificate – parts.
- Next create a new test file with Notepad at c:\intermediaryca.txt. From the email, copy the contents of the field to this file, including the Begin Certificate and End Certificate parts that cover the Intermediary CA thumbprint (see Figure 6).
- Create a new text file with Notepad at: C:\trustedcaroot.txt. From the email, copy the contents of the field to this file, including the Begin Certificate and End Certificate parts (as shown in Figure 7).
- Save the file and close Notepad. Next, we will import our test root CA certificate and Intermediary CA certificate, and the view.corp.com certificate with keytool, and then configure our Security Servers to use it.
- Copy the files you have created to the first Security Server. To import the test root CA certificate type:
keytool -import -trustcacerts -keystore "C:\Program Files\VMware\VMware View\Server\jre\lib\security\cacerts" -storepass changeit -alias rootCA -import -file c:\trustedcaroot.txt
Note: When the prompt finally shows, type yes to accept the certificate being imported into the trusted root certificates store (shown in Figure 8).
- Next, import the Intermediary CA certificate with the same command, but specifying a different .txt file and alias value:
keytool -import -trustcacerts -keystore "C:\Program Files\VMware\VMware View\Server\jre\lib\security\cacerts" -storepass changeit -alias intermediaryCA -import -file c:\intermediaryca.txt
- Type the keytool command:
keytool -import -keystore keys.p12 -storetype pkcs12 -storepass vmware -keyalg "RSA" -trustcacerts -file c:\testcertificate.p7
This instructs keytool to import the private key held in keys.p12, once it is verified as being correct by the testcertificate.p7 file from the authority. Despite the appearance of trustcacerts in the string, frequently these “test only” certificate authorities are not live root CAs, which is done to prevent fraud and misuse of trial certificates. When the import takes place, you may see the message “... is not trusted. Install anyway? [no]: yes”. This message should not appear if you are carrying out the enrollment process with a proper commercial root CA or if you have already imported the test root CA certificate as I have done in this example.
- Next edit the config.properties file on the first Security Server:
Notepad C:\Program Files\VMware\VMware View \Server\sslgateway\conf\config.properties
- Add these two lines to configure the Security Server for the Private Key together with the password to access the file correctly:
- Save the config.properties file.
IMPORTANT: Copy the keys.p12 file to the C:\Program Files \VMware\VMware View\Server\sslgateway\conf directory.
- Restart the View Security Service with either the Services MMC or using net stop wsbroker and net start wsbroker from the command prompt.
- Next copy the keys.p12, testcertificate.p7 and config.properties file to the companion Security Server. Remember to copy the locked.properties file to the C:\Program Files\VMware\VMwareView\Server\sslgateway\conf. Repeat steps where the certificates were imported. Then, optionally install the test root CA certificate on one of your clients. On the client, use Notepad to create a .CER file to hold the certificate data with Notepad at:c:\testrootca.cer.
- Then copy the text Begin Certificate and End Certificate into the testrootca.cer file and save.
- Next right-click the testrootca.cer file and select Install Certificate (see Figure 9). From this point, simply follow the dialog boxes accepting the defaults.
- From the client where you just imported the test root CA certificate, open a Web browser to your external URL (in my case, https://view.corp.com as seen in Figure10. Your Web browser should allow you to see the certificate to verify its content. Most browsers support viewing the certificate by double-clicking the padlock icon in the status bar. Use this dialog box to confirm that the Security Server is no longer using its own internally generated certificate:
Every connection counts
There’s really no excuse for using the built-in certificates, but it would be nice to see VMware simplify the process of requesting certificates for View 5. Like any command-line process, it’s easy once you know how, but compared to other certificate enrollment processes – such as setting up Microsoft’s Internet Information Services (IIS) to use SSL certificates -- this one feels much harder and time-consuming.
Mike Laverick is a former VMware instructor with 17 years of experience in technologies such as Novell, Windows, Citrix and VMware. Since 2003, he has been involved with the VMware community. Laverick is a VMware forum moderator and member of the London VMware User Group. He is also the man behind the virtualisation website and blog RTFM Education, where he publishes free guides and utilities for VMware customers. Laverick received the VMware vExpert award in 2009, 2010 and 2011.
Since joining TechTarget as a contributor, Laverick has also found the time to run a weekly podcast called the Chinwag and the Vendorwag. He helped found the Irish and Scottish VMware user groups and now speaks regularly at larger regional events organised by the global VMware user group in North America, EMEA and APAC. Laverick published books on VMware Virtual Infrastructure 3, vSphere4, Site Recovery Manager and View.