Certificates

Originating Authors

Mike Laverick

Barry Coombs

Introduction to Certificates

Version: Horizon View 5.1

Now we’re getting very close to a completed solution – all that is left to consider are those pesky things called certificates. In previous releases it was possible to make a connection to the View Server using untrusted certificates and the user would not see any alerts, alarms or warnings. Since the release of View 5.0 this is no longer the case. Without a valid certificate the end-user is going to be nagged about the certificate being untrusted. That’s even more true with the release of View 5.1 where now the dashboard shows which Security and Connection Servers have valid certificates or not. The recommendation now is even if you have internally facing clients that are not coming via the Internet you should really spend time generating and assigning trusted certificates.

This affects not just Windows View Clients, but other clients such as the iPAD.

For the moment the clients are configurable in such away that untrusted certificates that don’t match the FQDN of the service will still work. However, that is not guaranteed in the future. As regulatory bodies increasing tighter this aspect of end-user computing we may well see the day arrive that if a web-browser or client touches an untrusted or invalid certificate then communication will be stopped until it is resolved. For the moment it is up to the administrator to set the appropriate defaults, and for the end-user to decide if they wish to enforce strict policies about whether unverifiable connections should be rejected, merely create a warning or allowed.

Note: The View 5.1 client introduces the “Configure SSL” option exposed when the user client the “Options” button. The subsequent dialog box allows for a reject, warn or blindly accept. The default as you can see - if you do not change the configuration is to “Warn if the connection maybe insecure”.

Additionally, you should know that the View Server has a secured web-server that allows for the download of the View client to the user’s computer. We feel its only right and proper that users should expect a valid certificate for these services – and even more so now that users are seeing certificate warnings. The tipping point is when your View Infrastructure becomes public and Internet facing.

We have been dealing with certificate technology for some years, and while they have come down in price since the days that Verisign and Thawte charged the earth for them, the generation and enrolment process is still fraught with administration, not least because each software vendor seems to prefer their own tools. There seems to be a bewildering array of certificate types, and in some cases the documentation seems to be decidedly lacking, precisely because there are so many different ways of managing the process. For this reason we are going to assume you only have a passing understanding of certificates, and we hope we don’t patronize too many people along the way.

In the main, certificates are used to prove or validate the identity of the server or service you’re connecting to, with the intention of reassuring the user or customer that they have connected to a genuine website. The lynchpin of certificates is the concept of trust. You trust the certificate offered up by https://www.hotmail.com because you trust the “Certificate Authority” that created it. Specifically, your web browser has a list of trusted “root” certificate authorities (the people who issue certificates) built-in, including companies like VeriSign and Thawte.

These authorities are meant to check out certificate applicants and revoke certificates that have been abused by rogue operators. The trouble is, they charge fees for their services, and there have been occasions in recent memory where the checking hasn’t been as rigorous as it should be. The sad reality is that you can still go to a secured website that takes a payment, and then promptly shuts up shop the day after. Despite the rise and rise of e-commerce and a global financial system (are those terms sounding a bit hollow in Q4 of 2011?) consumer protection law seems to vary greatly, even from one part of the United States or the European Union to another.

The process of applying for certificates could be considered analogous to the way the passport system is generally managed. The root CA authority is like the national government, this body allows for the existence of the passport office (the Certificate Issuing Authority or subordinate). The authority receives applications for passports from individuals who need to prove their identity to others (the certificate for the website). An application process is made by the individual, and then the authority (the passport office) decides whether to allow or deny the application. The application process creates a private key that is used for encryption purposes. This private key is like a passport application together with all the other supporting documents required to validate the request (like your birth certificate and driving license). Until it is stamped or trusted by a recognized authority, it remains just a fancy piece of paper. These components need to be secured because if they were intercepted it would undermine the whole application procedure.

Occasionally, a certificate can be revoked if this relationship breaks down. The certificate authority can publish what are called revocation lists denying the authority of the certificate in question. You can liken this to when an individual commits a crime, and their freedom to travel is deliberately limited.

Alongside confirming the identity of the web server in question, the certificate also allows for encryption of data packets to and from the client and the server using the Secure Sockets Layer (SSL) originally developed by Netscape. SSL is the S you see in https://. Many web browsers now check the authority and validity of certificates which you will have seen countless times in kilo/DRAC/RAC boards and indeed in VMware products, which use internally self-signed certificates for Web Access and the vSphere Client. Indeed, nowadays the most common reason to generate certificates that are valid, is to prevent users over-reacting to various warnings and error messages generated when a certificate is not trusted. In the main, this is caused by lack of knowledge of what a certificate is, and the general paranoia about the security of all web servers and sites – even Intranet portals. Anyway, that’s the end of the Sesame Street view of certificates, we are now putting our bright yellow chicken suits to one side.

As you have seen, the process begins with a request for a certificate. In VDM 3.x and View 4.x and 5.0, VMware used a Java utility called keytool to make the initial request file. Despite the Connection Server and Security Servers being Windows-based, VMware did chose to use Microsoft utilities for the certificate enrolment process itself. All that changed in View 5.1 released in May, 2012. With this release VMware abandoned the use of Java based Keystone, and opted to use the Microsoft repositories. This makes the enrolment process much easier especially if you are running your own Microsoft Certificate Authority.

In this chapter we will be using the Microsoft Certificate Authority service to self-issue certificates rather than using an external authority. If your main usage of View is for the Connection Server in a LAN environment we think its perfect lee acceptable to issue your own certificates. However, when it comes to externally accessible systems from the Internet and many different device types, we would recommend using a commercial certificate authority such as Thawte or Verisign. The whole process is much simpler and generates less hassle when you have little or no control over the client endpoint.

Working with an Internal Microsoft Enterprise Certificate Authority

You may wish to manage your own certificate authority and issue certificates that are trusted within the business. Additionally, because vendors of certificates charge for their services – you might perceive costs savings to be possible by managing the certificate request, enrolment and issuing process yourself. This is especially true if your running VMware View from your home lab and want a secured View infrastructure but don’t want the hassle of dealing with an external authority. If this is the case this section is for you!

Creating a Certificate Request for Connection Server using the MMC)

There are two different ways of requesting a certificate. You can do it via the certificates snap-in using the Microsoft Management Console, or you can do this via the web-pages enrolment. We have chosen to document both methods – one with Connection Server, and the other with the Security Server. Of course if you environment resolves to single load-balanced address of say – view.corp.com. Then you only need one certificate with that name, that can then be exported from one server and imported to all the rest.

As a Connection Server is part of the Active Directory Domain, you can easily use the Microsoft Management Console to make a certificate request. If you are logged in as the administrator of the CA then you make the request, and have the certificate issued in one fell swoop. To do this your CA must be installed as an “Enterprise” CA rather than Standalone CA. There are some special requirements to be full-filled in the enrolment process for this to work that you will see in the instructions below. The certificate must include:

• The FQDN of the View Connection Server

• The Friendly Name of “VDM”

• The private key marked as exportable

1. Log in to the Connection Server with the same credentials used to manage Microsoft Enterprise Certificate Authority

2. Open a new MMC Console with Start, Run and mmc.exe

3. Next add in the Certificates snap-in by selecting File in the menu, and Add/Remove Snap-in

4. From the list of available snap-ins select “Certificates” from the list, and click the Add> button

5. Select from the list of management source the radio button marked “Computer Account”

6. Select the snap-in to use the Local Computer store.

7. Next expand the nodes of +Certificates, +Personal and +Certificates

In the list you should find you already have a certificate there – this was generated by the installation, and although it may have the right FQDN, it comes from an untrusted source. It is safe to delete this certificate, but you may wish to back it up first – in case something goes wrong during the certificate replacement process. If you open the certificate and select the “Details” tab the “Copy to File…” option will allow you to export this old certificate into format that can be protected with a password.

8. Next we will make our certificate request to our recently install Microsoft CA. Right-click the Certificates node, and select the “All Tasks” option and select “Request New Certificates” from the menu.

9. Click next to the obligatory “Welcome Page” and in the next step select the option for an “Active Directory Enrolment Policy”

10. In the list of Request Certificates, you should see “Web Server” is listed. If its not listed its because the Connection Server doesn’t have the rights to access the certificate template. If that is the case you will see a red X next the templates when you enable “Show all templates”.

If this is the case you will need to use Certificate Template Console (certtmpl.msc) at the Microsoft CA to change the permissions on the Web Server template. In our case we put the Connection Servers into group called “View Connection Servers” and then granted this group rights to the template.

If the permissions are correct you should see this in the Request Certificates dialog wizard:

'11. Click the blue highlighted text, to complete the certificate request that opens the “Certificate Properties” dialog box. In the “Subject” tab select Type: to be “Common Name”, and in the Value: field type in the FQDN of the Connection Server – in our case view.corp.com. Then click the “Add>” button

IMPORANT:

Notice here that the common name we using matches the “External URL” configured for the Connection Servers relationship with the Security Server. If you weren’t using the Security Server, and just the connection server then ideally you would have some load-balancing appliance in front of them with FQDN that resolved to the load-balance IP address rather than using the FQDN of the Connection Server. Either way its likely once your are using some type of load-balancing technology that you will want to establish some sort of universal FQDN that your users will remember whether they are working at the office or on the road. In our case we decide on using “view.corp.com” as our common URL.

12. In the same “Certificate Properties” dialog box select the “General” Tab and in the Friendly Name: field type the string “vdm” like so:

Note: VDM refers to Virtual Desktop Manager – the old name for VMware View. The View Services are configured to look for this string in the friendly name when they start.

13. Finally, under the “Private Key” tab, expand the “Key Options” and enable the “Make private key exportable” feature.

14. Once you have configured the certificate properties, you can click OK – and you should find the warning has been cleared – and you can enable the option for a “Web Server” certificate requests.

Click the Enroll button, and your certificate request will be processed.

15. Once completed you can close the MMC. You will need to restart the View Connection Service in order for the service to listen on port 443 using the new certificate.

Once the Connection Server service has restarted you should see in the “Dashboard” area the once “red” alarms indicating an untrusted certificate are subsequently cleared to show that the certificate is correct.

This status of the SSL certificate on a Connection Server was introduced in View 5.1, and did not exist with View 5.0. If you want to validate your external name matches the certificate on the client – then the best way is to use the View client or open a web-browser to the name to ensure it doesn’t produce any warnings or pop-ups.

Creating a Certificate Request for Security Server Using Web-pages (Optional)

If you prefer to carry out the certificate request from the Security Server the request process for a Security Server differs from a Connection Server in a number of critical ways. Firstly, the CA is more likely to be an external commercial supplier of SSL certificates. Secondly, even if you are using your own Microsoft CA, the Security Servers are not normally made part of the Active Directory Domain, so that means some of the automation that comes from that integration is not there. You are likely to find yourself using methods other than the MMC to make certificate requests – and you will also need import both the certificate and the Microsoft Root CA certificate in order for your certificate to be trusted. It’s tempting to work around this problem by merely adding the Security Server to your AD domain. However, we consider this a really bad practice, and would undermine the hardening that you could do to the Security Server.

Remember, the “common name” or FQDN will not necessarily match the hostname of the Security Server – it’s more likely to correspond to some externally resolve DNS name such as view.corp.com or mydesktop.corp.com. The certificate request should only need to be done once – once you have the certificate it can be exported and imported to each of your Security Servers. This means if you are using a TCP/IP load-balancer in front of the View infrastructure the Security Servers all present the same identity. You could take this approach for your Connection Servers as well if you so wished. As we stated earlier, these certificates will most likely be required by any load-balancing technology you adopt – so when inbound connections come into the load-balancer it can establish a trusted and valid SSL connection from it – on to the Security Server and from it to its paired Connection Server. Without this you would receive mismatches between the various parts of the infrastructure that would in most cases stop or inhibit all communications.

Create and Publish a new Certificate Template

In this section we wanted to show you how certificates can be requested using web-pages rather than the MMC. If you’re working with a Windows 2008 R2 Certificate Authority, although the system has the ability to carry out enrolments using web-pages, the default “Web Server” template does not allow the export of the private key required by VMware View 5.1. This feature was disabled in the “Web Server” template with the introduction of Windows 2008.

Sadly, the default “Web Server” template is marked as read-only by Microsoft CA, so it isn’t possible just re-enable the option. The only way to proceed is to take a duplicate of the “Web Server” template, then enable the feature and then publish it to make available through its web-pages. It sounds convoluted but it is actually quite an easy process – once you have found out how to do it!

1. Login to the Microsoft Enterprise CA and open the Certificate Templates Console (certtmpl.msc)

2. In the list right-click “Web Server” and choose “Duplicate Template”

3. Use the Windows 2003 option for the version of the template

4. In the Properties of New Template dialog box – change the Template Display Name and Template Name to be more meaningful such as “VMware View”

5. Next select the “Request Handling” tab, and enable the option to “Allow private key to be exported”

6. Once finished – click OK.

7. Next we need to enable this template to be published and available in the Microsoft CA web-pages. To carry out this task open the Certificate Authority MMC, and right-click “Certificate Template” node. Select from the menu the option “New certificate to Issue”

8. In the “Enable Certificate Templates” dialog box select the copy of the “Web Server” certificate we created a moment ago. In our case we called this “VMware View”.

This should update the list of available templates, and if you use the web-page method of enrolling certificates, you would see your certificate template in the pull-down list, and because we enabled the option to “Mark keys as exportable” would be available also.

Request an new certificate for a View Security Server

As our Security Servers are not part of any AD domain, we must find another method of carrying out a certificate request. Fortunately, Microsoft provides a web-page method of making the request to the Certificate Authority.

1. Open IE on the Security Server desktop

2. Browse to your CA with https://fqdn/certsrv for example in our case this would be https://dc01nyc.corp.com/certsrv

3. Login with your administrative credentials to the Enterprise CA

4. Under “Select a task:” click the hyperlink called “Request a certificate”

5. In the following page select “Advanced Certificate Request” followed with “Create and Submit a request to this CA”

6. In the Advanced Certificate Request page, select from the pull-down list the custom certificate template we created earlier. Fill out the form with meaningful information pertaining to your organization – note that the “Name:” field should contain your FQDN alias that end-users will use to connect to the View Infrastructure – in our case view.corp.com. At the end of the form (you will nearly always need to scroll down to see it) is a field for the friendly name – ensure you set this to be the string “vdm”.

7. Double-check the form details, and then click the Submit button

8. If you are logged in as the administrator for the Microsoft CA, the certificate should be issued to you immediately and presented to you in the web-page like so:

Important:

This “installs” the certificate into Internet Explorer. However, it does need to be “imported” into the Security Server computer store. Additionally, you may be carrying out your certificate requests from a management PC, and you will need to import the certificate into the stores of the servers that make up your View infrastructure.

Importing the Certificate into the Security Server computer store

Once the certificate request has been completed you will need to either importing into the “computer” certificate store – or transfer it from your management PC to the Security Servers itself. To do this follow these simple steps.

1. In Internet Explorer open the Internet Options dialog box, select the “Content” tab and click the “Certificates” button

2. Select the certificate from the Personal tab, and click the “Export” button.

3. In the export wizard make sure you select the option to “Yes, export the private key” and make sure you select the Personal Information Exchange format in the next dialog box

4. Set a password to protect the private key, and finally set a location on where to save the file.

5. Next we can use the MMC console with the Certificates snap-in focused on the local computer to carry out the import.

6. Start by right-clicking the “Personal” node in the MMC, and selecting “All Tasks” and “Import”

7. In the Certificate Import Wizard, use the browse button to locate the exported certificate – note that you will need to change the file type to the “Personal Information Exchange” format:

8. In the next dialog box – type the password you used to protect the private key and click Next

9. Once imported the certificate should be viewable within the Certificate MMC like so.

If you find that the certificate is not trusted it will be because the Microsoft Root CA certificate is not installed. A quick way to install the root CA certificate can be via the Microsoft CA Web based Certsrv service.

Open up a web-browser to https://fqdn/certsrv

Select the link “Download a CA certificate, certificate chain or CRL”

Select the link “Download CA certificate”

Save the file, giving it a friendly name – like CorpHA-CA-Certificate

Locate the file, right-click and select “Install Certificate”

When you Install the root CA certificate make sure you add it into the “Trusted Root Certification Authorities”. Once done it should appear in the certificate store for the local computer.

Installing the Certificates on to your Security & Connection Servers

Once you have created a valid certificate either on your Security Server or Connection Server – it then needs importing to all your other View infrastructure servers in the environment. That’s a relatively easy process if you already have the certificate in the .pfx format we saw just a moment ago. If not you will have to first export it (including the private key), and then import into your other servers certificate store. To do this carry out the following steps:

1. Locate the certificate in the requesting system, and in +Personal and +Certificate right-click the certificate in question, and select from the menu the All Tasks and Export option like so:

2. In the wizard select the option to “Yes, export the private key”.

3. Accept the default .PKCS #12 format

4. Next set a password to protect the private key from being accessed by untrusted party

5. Finally browse to a location to save the .PFX file

6. Next copy the .PFX file to the other servers or save the .PFX file in a shared location they can all access, and using the .MMC snap-in for certificates focused on the computer store carry out the import process.

7. Next browse for the .PFX file

8. Next supply the password used to protect the private key during the import/export process

9. Once all your Security Servers and Connection Servers have shared certificate – containing a valid FQDN for your alias (in our case view.corp.com) then you can restart the VMware View Security Server service and the Connection Service. Once you have successfully imported the certificate to all your Security Servers and Connection Servers you should find that the “dashboard” status turn from red to green.

As you might gather the process we have outlined here for the Security Servers could have equally applied to the Connection Servers. So we are essentially demonstrating two different ways of doing essentially the same job. Personally, we feel using the MMC method with the Connection Servers makes sense because it involves far less steps.

Working with External Certificate Authority Vendors

Prior to the advent of View 5.1 the only way to make a certificate request was using command-line tool included with the Security and Connection Server – called “keytool”. You may still want or need to use this utility if you are using an external certificate authority such as Thwate or Verisign.

Add Java Keytool to the System Path

The Java Keytool is available on both the Connection and Security Server. It doesn’t really matter where you run it, we decided to use the Connection Server as it is on our internal network and trusted. Once the certificate request has been approved and the certificate downloaded, we will manually take it to each of our Security Servers and make sure it is installed and trusted. Unfortunately, the install of neither the Connection Server nor the Security Server sets up the necessary Path statements to the Java binaries to make them work:

1. Open the Windows System Properties dialog box

2. Under the Advanced tab, click on Environment Variables button.

3. In the System variables group, select Path and then click the Edit button.

4. In the Variable value field add the path to the JRE installation directory

;C:\Program Files\VMware\VMware View\Server\jre\bin

The semi-colon merely allows you to add one path after another

5. Click OK multiple times to confirm your changes and exit the dialog boxes

Generate a Certificate Request File

Next we need to use the keytool command to create a private key that is used in the identification and encryption process. This file on its own does not have authority from the higher body - it would be like printing your own passport. It is never transmitted across the network and is secured by encryption and password. If the private key were compromised then the whole chain of trust and authority would be compromised.

The private key is generated by using the keytool command together with some parameters. The keytool command will also run a wizard to ask you to identify information such as:

• The FQDN of the URL used by the end users to connect, in our case we have been using view.corp.com. Confusingly, keytool suggests using your “first and last name” when actually you should type the URL of your View virtual desktops environment

• Your department and organization

• Location (such as your town or city), State, and Country. The latter must be in the form of a two-letter country code that corresponds to the ISO standards. For example in the United Kingdom you would not use UK, but actually GB for Great Britain. Our country has many names, and we still haven’t really decided what to call ourselves. If you’re in the US, double-check your state name is in the correct format – we screwed up by initially typing New York State, rather than New York. We guess we should have remembered “New York, New York - so good, they named it twice!”

1. Open a command prompt on the View Server and use cd\ to locate yourself at the root of C:

2. Type the command:

keytool -genkey -keyalg "RSA" -keystore keys.p12 -storetype pkcs12 -validity 360

This command generates a private key using the RSA algorithm using the format of PKCS12. It is recommended that you secure and backup this file in case you ever wish to recreate the certificate files again. After hitting the enter key you will be asked for your identifying information – notice how the key file is itself encrypted and password-protected to prevent it being intercepted.

3. Next we will create the certificate request file. This is a file we can safely send to a root CA to request that our private key can be trusted by the root CA authority. This means that we must at no stage transfer the private key to anyone external to the organization. See the CSR file as a helper file that assists in the process of having our private key stamped for approval.

keytool -certreq -keyalg "RSA" -file mycertrequest.csr -keystore keys.p12 -storetype pkcs12 -storepass vmware

This command basically states you are creating a certificate request file (-certreq) using the RSA algorithm (-keyalg “RSA”) calling the request file mycertrequest.csr, and using the private key created earlier, which is used to prove the identity of the server or services held in the keystore file called keys.p12. The –storetype indicates we used the PKCS12 format, and the password used to access the private key data is vmware.

We should now have two files created in this process – one called keys.p12 which is protected and not human readable, and the mycertrequest.csr file which is text based and is viewable using a Microsoft type command

Submit the Request to the Certificate Authority

There are a number of places where you could submit this certificate request – either externally to a commercially available certificate authority which will be highly trusted by nearly every web browser and internet café on the planet, or alternatively, you could submit it to a certificate authority internal to your organization, which effectively limits your certificate to internal end users only. The request file can often be uploaded using HTTP forms, or you can frequently copy the text from ----- BEGIN NEW CERTIFICATE REQUEST ----- to ----- END NEW CERTIFICATE REQUEST ----- and then paste the string into an edit box on a form. Personally, we feel a file upload process is neater, but we have used both; it depends what the certificate authority supports. Many of the 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 and a chance to spam your inbox with sales information!). However, some commercial certificate authorities do allow a “test” root CA certificate to be installed. Typical certificate providers include:

Thawte: http://www.thawte.com

VeriSign: http://verisign.com

GlobalSign: http://globalsign.com

In this example, we used Thawte to generate a certificate

1. In the cmd prompt, use the Microsoft type command to output the contents of the CSR file

2. Select all the text from including the words -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----

3. Right-click and Choose Copy

4. Open your web browser at:

http://www.thawte.com

5. In the Thawte website, click the link that says “Free SSL Certificates”

6. Next fill in the Technical Contact page and click Continue

7. From the Select Server Platform list, select the option “Server not listed”, and in its edit box type the string “VMware View 5”

8. Finally in the Paste Certificate Signing Request (CSR)… erm, press ctrl+v on your keyboard.

We don’t intend to be funny here, but if you can’t cut and paste a string into a web page then, Houston, we have a problem!

9. Accept the Terms of the Agreement and click Submit

10. Thawte will then generate your certificate and send it to the email address provided earlier.

Important:

When the email arrives it will contain two certificates – one identifying your FQDN for your View deployment (in our 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 as this would be pre-installed to most web-browsers and stored on the client computer’s certificate store.

Once these certificates arrive they can be imported into the computer certificate store using the same process we saw earlier.

Conclusion

Certificates remain the cornerstone of cryptography - as wonderful as public key and private key encryption is – it means nothing if the user cannot be sure they are connected with to a trusted server. Of course, the weakest link in security remains the end-users and how they secure their usernames and passwords. Ideally, they should not be storing these on yellow Post-IT notes stuck their monitors! To this effect many organizations now feel it is imperative to implement some type of two-factor authentication where the user must provide their username and password, together with a pin code or smart card. Smart cards have been in use in government sectors for some time where they often double as identity cards to enter the physical environment. In the commercial world systems like RSA’s “SecureID” and Safenet’s “SafeWord” have proved more popular mainly because they are more portable, and don’t require a special “reader” to function. Again, this is not an endorsement by the authors, but merely a demonstration of how a typical two-factor authentication system might function, and how adding them adds another layer of protection. Virtual desktops reside in your datacenter or in your server room – would you like a hacker to have remote access to super-rich desktops in those locations? In this addition were unable to add coverage of two-factor authentication. However, we do intend to cycle back to the topic in future additions.

We now have in our environment four View Servers – two Connection Servers (CS01 and CS02) and two Security Servers (SS01 and SS02), to offer the minimum requirements for availability. Our next topic concerns load-balancing the client inbound access to the Security Servers – to ensure that the load is balanced between the systems, and to offer a degree of resilience should one of the Security Servers be unavailable.