Knowledge Base

The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
 
Search the VMware Knowledge Base (KB)   View by Article ID
 

Horizon Mobile Manager 1.2 Deployment Guide (2035492)

Details

The VMware® Horizon Mobile Manager™ virtual appliance is designed to control, customize, and manage a corporate workspace on your users' mobile devices. The appliance uses an embedded Apache 2.2 server to provide the server-side management capabilities. You should deploy the virtual appliance so that it can manage workspaces on the devices whether those devices are communicating over a corporate network or over the Internet.

Solution

The typical deployment configurations for Horizon Mobile Manager are described in the following table.

Note: These deployment configurations are also described in the Horizon Mobile Manager 1.2 Installation and Configuration Guide.

ConfigurationDescriptionAdvantages
Disadvantages
Horizon Mobile Manager in a network demilitarized zone (DMZ).In network computing, a network DMZ is a mixed-trust zone between the internal network services and the Internet. In this configuration, Horizon Mobile Manager's IP address is an external public IP address, and is directly accessible on the Internet. The devices communicate with SSL requests to Horizon Mobile Manager's public IP address.
  • Easiest way to get Horizon Mobile Manager up and running.
  • No special network configuration needed other than an external IP address.
  • Unsuitable for production environments, because all of Horizon Mobile Manager services are publicly exposed to the Internet.
  • Prevents connections between Horizon Mobile Manager and enterprise internal services such as Active Directory, LDAP, or corporate database services, unless ports to those services are accessible through the enterprise's firewall.
Horizon Mobile Manager in the enterprise's internal network, and use network address translation (NAT) to translate its internal IP address to an externally available IP address.In this configuration, Horizon Mobile Manager has a private IP address. The devices communicate with SSL requests to an externally available IP address, and those SSL requests are translated to Horizon Mobile Manager's private IP address using NAT.
  • Horizon Mobile Manager services are protected within the enterprise's firewall.
  • Horizon Mobile Manager can connect with internal services such as Active Directory, LDAP, or corporate database services without opening ports through the firewall.
  • NAT is a common network setup used and understood in enterprises.
  • Requires defining NAT rules that translate public IP requests to TCP/IP port 443 on the Horizon Mobile Manager's private IP address.
  • Horizon Mobile Manager's port 433 must be available to receive the requests from NAT.
  • Less than ideal architecture for an environment with clustered Horizon Mobile Manager servers that have one or more external reverse proxy Apache servers.
Horizon Mobile Manager in the enterprise's internal network, and use a reverse proxy server in the DMZ to handle the SSL requests from the devices on the Internet.In this configuration, the reverse proxy server handles the SSL communications with the devices, and then initiates new requests to Horizon Mobile Manager on the internal-facing side within the core network. The reverse proxy server converts requests for Horizon Mobile Manager's login, leasing, and download services to the specific URLs that Horizon Mobile Manager supports.
  • Horizon Mobile Manager services are protected within the enterprise's firewall.
  • Horizon Mobile Manager can connect with internal services such as Active Directory, LDAP, or corporate database services without opening ports through the firewall.
  • More easily leverages existing corporate infrastructure. Many enterprises typically use reverse proxy servers to isolate internal application servers from the Internet, and these existing proxy servers can be extended to work with Horizon Mobile Manager.
  • Requires careful planning to set up the reverse proxy server and the rules for its communication with Horizon Mobile Manager.
  • Requires configuring the reverse proxy server for SSL communications using your own SSL certificate (either self-signed or signed by a trusted commercial certificate authority).
  • Requires involvement by networking teams to ensure that the reverse proxy server has a route to Horizon Mobile Manager on a secondary interface.

See the Horizon Mobile Manager 1.2 Installation and Configuration Guide for the specific choices that correspond to each of the above deployment configurations when you are installing and configuring the Horizon Mobile Manager virtual appliance.

Choosing Your Digital Certificate Approach

Horizon Mobile Manager encrypts session information using standard digital certificates, and communications between Horizon Mobile Manager and the mobile devices are sent over Secure Sockets Layer (SSL) protocol connections. In its default configuration, Horizon Mobile Manager uses automatically generated, self-signed certificates. Deciding whether to continue using the default certificates involves considering which method is appropriate for your chosen deployment configuration and, if using self-signed SSL certificates, notifying your device owners of the steps they need to take when self-signed SSL certificates are used.

Certificates Used In a Horizon Mobile Manager Deployment

The deployment environment must support the ability for Horizon Mobile Manager to present valid certificates to the devices, and also to propagate signed certificates that are used in the workspaces on those devices. The certificates used in communications between Horizon Mobile Manager and the mobile devices are:

SSL certificate – Encrypts the secure session between the server and the client (the mobile device).
Signing certificate – Digitally signs communications between the server and the client.
Root and intermediate certificate authority (CA) certificates – Provide a certificate trust chain for determining whether to trust the particular SSL and signing certificate.

When you initially install and configure Horizon Mobile Manager, a self-signed SSL certificate and a signing certificate are automatically generated using an automatically generated internal root Certificate Authority (CA) and the server URLs that you enter in the configuration user interface (as described in the Horizon Mobile Manager 1.2 Installation and Configuration Guide). The Security page in the Horizon Mobile Manager's administration user interface lists the aliases for the automatically generated certificates.

Required Steps for Device Owners When Horizon Mobile Manager Uses a Self-Signed SSL Certificates

Although the automatically generated certificates are unique and allow for initial or proof-of-concept use of the server, they are not signed by a trusted well-known CA. As a result, before the device owners start the VMware Switch application to install their corporate workspace for the first time, they must clear the Authenticate Server check box in the VMware Switch application settings. That check box is selected by default when the VMware Switch application is installed. When the Authenticate Server check box is selected and the SSL certificate is a self-signed certificate, the device attempts to use the Android trust store of well-known CAs to verify the certificate. Because the certificate is not signed by a well-known CA, the session fails to authenticate and the device refuses to connect to Horizon Mobile Manager.

If your Horizon Mobile Manager deployment is using a self-signed SSL certificate (either the one automatically generated by default or your own self-signed certificate), notify your device owners to ensure that the Authenticate Server check box is cleared before they start the VMware Switch application for the initial installation of the workspace. When that check box is cleared, the device ignores the fact that the SSL certificate is self-signed and allows the connection to Horizon Mobile Manager. To display the Authenticate Server setting for the VMware Switch application on the device, open the device's Application Settings display, touch VMware Switch, and touch Manage Space.

Certificate Approaches By Deployment Configuration

Use a certificate approach that is appropriate for your Horizon Mobile Manager deployment configuration.

ConfigurationCertificate Choices
Horizon Mobile Manager in your network DMZ
Horizon Mobile Manager in the enterprise's internal network, and using NAT
Horizon Mobile Manager in the enterprise's internal network, and using a reverse proxy server in the DMZ
Because using a reverse proxy server requires that server to be configured for SSL communications, you use your own SSL certificate in your reverse proxy server. This certificate can be self-signed or signed by a trusted CA. In this configuration, you must upload to Horizon Mobile Manager the root certificate and any intermediate certificates that are in that SSL certificate's trust chain. Follow the steps in Using Your Own Trusted Signed Certificates When Using the Reverse Proxy Server Deployment Configuration.


Caution: Any changes you make by replacing the default certificates in the embedded Apache server will be lost if you change the leasing server URL used by Horizon Mobile Manager. The leasing server URL is set in the Horizon Mobile Manager configuration user interface. When you click the Save & Restart button in the configuration user interface, the system automatically generates new default certificates using that leasing server URL as the domain and signed by the internal MVP root CA. The new generated certificates replace your previously used ones. Therefore, if you replace the default certificates with your own, and then subsequently change the leasing server URL, you must repeat the certificate replacement process to return to using your own certificates.


Replacing the Default Certificates With Trusted Signed Certificates When Using the DMZ or NAT Deployment Configuration

One of the benefits of replacing the default self-signed SSL certificate with a certificate that is signed by a trusted Certificate Authority (CA) is that it avoids requiring the device owners to clear the Authenticate Server check box in the VMware Switch application. To use your own trusted signed certificates when using Horizon Mobile Manager in your DMZ or in the NAT deployment configuration involves replacing the automatically generated ones with your own certificates. The steps for replacing the SSL certificate are slightly different than the steps for replacing the signing certificate. For both certificates, the general procedure is:
  1. Generate a private key and a Certificate Signing Request (CSR).
  2. Send the CSR to the certificate authority (CA) that you are having sign your certificate.

    The CA sends your signed certificate to you, along with the CA's trusted certificate chain of root and intermediate certificates used by your certificate.

  3. Load your signed certificate and the CA certificates that signed your certificate so they can be used by Horizon Mobile Manager.

    The SSL certificate is loaded into the embedded Apache server from the virtual appliance's console (using the VMware vSphere® Client™). The root and intermediate CA certificates and the signing certificate are loaded using the Horizon Mobile Manager administration user interface.

Note: While the main benefit of replacing the default SSL certificate with one that is signed by a trusted CA is to enable the device users to install their workspaces without altering the VMware Switch settings, there is usually no strong reason to replace the default signing certificate unless you suspect the automatically generated internal-ca-root certificate has been compromised.

To replace the default SSL certificate with your own trusted SSL certificate (in the embedded Apache server used in a DMZ or NAT configuration):

  1. Log in to the vSphere Client.
  2. Power on the Horizon Mobile Manager virtual appliance, and click the Console tab.
  3. Select Login.
  4. Log in to the virtual appliance's Linux operating system as the rootuser. Use the password that you set when you configured the Horizon Mobile Manager virtual appliance. If you didn't change the default password, enter vmwareas the password.
  5. Run the following command to generate a private key and a CSR:

    openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

    The command prompts you for the information required for the CSR. At the prompts, enter the information that is appropriate for your enterprise. For the Common Name, enter the fully qualified domain name that you are providing to the device owners to use in the VMware Switch application to initially set up their workspaces. This common name should be:

    • The fully qualified domain name that is externally resolvable to the public IP address used in this Horizon Mobile Manager deployment
    • The same externally facing URL that was entered for the Login Server URL (without the https:// portion of that URL) when the virtual appliance was configured.

    Generating a 2048 bit RSA private key
    ................................................+++ ............+++
     writing new private key to 'privateKey.key'
    -----
    You are about to be asked to enter information that will be incorporated into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [AU]:US
    State or Province Name (full name) [Some-State]:Massachusetts
    Locality Name (eg, city) [ ]:Cambridge
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:YourCompany
    Organizational Unit Name (eg, section) [ ]:YourUnit
    Common Name (eg, YOUR name) [ ]:your.domainname.com
    Email Address [ ]:yourwebmaster@yourcompany.com
    Please enter the following 'extra' attributes to be sent with your certificate request
    A challenge password [ ]:
    An optional company name [ ]:

    The command generates two files: CSR.csr and privateKey.key.

  6. Send the CSR.csr file to your certificate authority. The certificate authority sends you the signed certificate (such as cert.pem), the root and intermediate CA certificates used by your certificate, and the certificate chain file (such as chain.pem) to use with it.
  7. Log in to the Horizon Mobile Manager administration interface. In your browser go to the Horizon Mobile Manager administration URL, in the format https://ip_address, where ip_address is Horizon Mobile Manager's private IP address. Log in using a Horizon Mobile Manager user that has been assigned the Administrator role. If your deployment is configured to use the embedded naming service and you did not modify the default value for the system administrator name, you can log in to the administration interface with the adminuser name and vmwarepassword.
  8. Click Security to display the Security page.
  9. In the Server Trust Certificate Chain section, upload the root CA certificate and intermediate CA certificates that signed your SSL certificate. Upload each certificate by clicking the Upload New Certificate button.

    This step ensures that when mobile devices are provisioned, the root CA certificate and intermediate CA certificates needed to trust the SSL communications are included in the keystore of the workspace on the device.

    Caution: Do not remove any of the certificates listed in the Server Trust Certificate Chain list, especially a root CA certificate (including the default MVP Internal CA certificate), except under very controlled circumstances. Removing a root CA certificate from the Server Trust Certificate Chain list will remove it from all provisioned devices at the next lease renewal operation. Unless you have provided a replacement root certificate, those provisioned devices must be wiped and reprovisioned. It is extremely rare to have to remove a certificate from the list. The only reason to remove a certificate from this list is if you suspect the certificate has been compromised. In that situation, you must follow a specific sequence of steps to ensure that workspaces already installed on user devices remain operational.

  10. If devices have already been provisioned by this Horizon Mobile Manager instance, wait for the lease renewal time to elapse so that a leasing call is made by all of the devices. When the lease is renewed, the set of root CA certificates and intermediate CA certificates are sent to the workspaces. Waiting for the lease renewal time to elapse ensures that the certificate trust chain is installed in the keystores of the workspaces before the new SSL certificate is used in the embedded Apache server.

    Caution: Any devices that are disconnected and go without network access for longer than the leasing interval are not able to obtain the new certificates in this step. Workspaces on devices that are disconnected for a time period that extends past that leasing interval such that they do not obtain the new certificates will not trust the SSL communication with the server when the devices regain network access. Those workspaces will have to be wiped and reprovisioned to enable communications.

  11. Use the scp command to secure copy the signed SSL certificate to the virtual appliance's file system.
  12. In the virtual appliance's file system, edit the /etc/apache2/vhosts.d/mmp.conf file, and ensure the following lines are present and the paths point to the certificates and your generated private key:

    SSLCertificateFile /path/to/the/signed/cert.pem
    SSLCertificateKeyFile /path/to/your/generated/privateKey.key
    SSLCertificateChainFile /path/to/the/cert/chain.pem

  13. Restart the Apache server using this command:

    /etc/init.d/apache2 graceful

After restarting, the embedded Apache server uses the new SSL certificate.

Using Your Own Trusted Signed Certificates When Using the Reverse Proxy Server Deployment Configuration

Because using a reverse proxy server requires that server to be configured for SSL communications, you use your own SSL certificate in your reverse proxy server. While this certificate can be self-signed or signed by a trusted CA, one of the benefits of replacing the default self-signed SSL certificate with a certificate that is signed by a trusted Certificate Authority (CA) is that it avoids requiring the device owners to clear the Authenticate Server check box in the VMware Switch application. In this configuration, you must upload to Horizon Mobile Manager the root certificate and any intermediate certificates that are in that SSL certificate's trust chain. It is recommended that you perform the trust chain upload before provisioning any devices, so that they will have the correct trust chain when their workspaces are first installed on the devices.

To upload the root and intermediate CA certificates for the SSL certificate used by your reverse proxy server:

  1. Log in to the Horizon Mobile Manager administration interface. In your browser, go to the Horizon Mobile Manager administration URL, in the format https://ip_address, where ip_address is Horizon Mobile Manager's private IP address. Log in using a Horizon Mobile Manager user that has been assigned the Administrator role. (If your deployment is configured to use the embedded naming service and you did not modify the default value for the system administrator name, you can log in to the administration interface with the admin user name and vmware password.) 
  2. Click Security to display the Security page.
  3. In the Server Trust Certificate Chain section, upload the root CA certificate and intermediate CA certificates that signed your SSL certificate. Upload each certificate by clicking the Upload New Certificate button.

    This step ensures that when mobile devices are provisioned, the root CA certificate and intermediate CA certificates needed to trust the SSL communications are included in the keystore of the workspace on the device.

    Caution: Do not remove any of the certificates listed in the Server Trust Certificate Chain list, especially a root CA certificate (including the default MVP Internal CA certificate), except under very controlled circumstances. Removing a root CA certificate from the Server Trust Certificate Chain list will remove it from all provisioned devices at the next lease renewal operation. Unless you have provided a replacement root certificate, those provisioned devices must be wiped and reprovisioned. It is extremely rare to have to remove a certificate from the list. The only reason to remove a certificate from this list is if you suspect the certificate has been compromised. In that situation, you must follow a specific sequence of steps to ensure that workspaces already installed on user devices remain operational.

At this point, devices can be provisioned using the reverse proxy server.

Next Steps After Configuring Horizon Mobile Manager with the Appropriate SSL Certificates

After you have deployed Horizon Mobile Manager using one of the three standard configurations, and have made the appropriate updates for the SSL certificates, it is a best practice to validate the configuration and ensure that you can perform the appropriate administration tasks. For a description of test procedures that you can use to validate proper configuration and operation of Horizon Mobile Manager, see Horizon Mobile Manager 1.2 Manual Verification Tests (2038058).

Replacing the Default Signing Certificate

There is usually no strong reason to replace the default signing certificate unless you suspect the automatically generated internal-ca-root certificate has been compromised.

To replace the default signing certificate and make the new one the active one:

  1. Log in to the Horizon Mobile Manager administration user interface and open the Security page.
  2. Generate the CSR to send to your CA by clicking the Generate Certificate Signing Request button in the Server Signing Certificate section.
  3. Email the CSR to your CA.
  4. When your CA sends back the new signing certificate and the root CA and intermediate CA certificates that signed it, expand the Server Trust Certificate Chain section on the Security page, and upload each root CA and intermediate CA certificate by clicking the Upload New Certificate button.

    Caution: Do not remove any of the certificates listed in the Server Trust Certificate Chain list, especially a root CA certificate (including the default MVP Internal CA certificate) until after step 5, and the lease renewal time has passed.

  5. Wait for the lease renewal time to elapse so that a leasing call is made by all of the devices. When the lease is renewed, the set of root CA certificates and intermediate CA certificates are sent to the workspaces. Waiting for the lease renewal time to elapse ensures that the certificate trust chain for the replacement signing certificate is installed in the keystores of the workspaces before you make the new signing certificate the active one.

    Caution: Any devices that are disconnected and go without network access for longer than the leasing interval are not able to obtain the new certificates in this step. Workspaces on devices that are disconnected for a time period that extends past that leasing interval such that they do not obtain the new certificates will not function properly when the devices regain network access. Those workspaces will have to be wiped and reprovisioned.

  6. Open the Server Signing Certificates section and upload the new signing certificate sent by your CA by clicking the Upload New Certificate button.
  7. Use the Signing Certificate drop-down list to select the new signing certificate and make it the active one.

    Caution: Do not remove the previously used signing certificate from the Server Signing Certificate list until after step 8, and a second lease renewal time has passed.

  8. Wait for the lease renewal time to elapse so that another leasing call is made by all of the devices. When the lease is renewed, the new signing certificate is sent to the workspaces as the active signing certificate. Waiting for the lease renewal time to elapse ensures that the workspaces are using the new certificate to sign messages before you remove the old signing certificate from the list.

    Caution: Any devices that are disconnected and go without network access for longer than the leasing interval are not updated to use the new active signing certificate in this step. Workspaces on devices that are disconnected for a time period that extends past that leasing interval will not function properly when the devices regain network access. Those workspaces will have to be wiped and reprovisioned.

  9. On the Security page, expand the Server Signing Certificates list and remove the older (compromised) signing certificate. At this point, you can also remove the root CA and intermediate CA certificates that are associated with the older signing certificate, unless they are also used for the new signing certificate.

Changing root CA and intermediate CA certificates when workspaces are already provisioned to devices

To verify the identities of the SSL certificate and signing certificate used by Horizon Mobile Manager on the server side, the provisioned workspaces use the certificate trust chain that is specified by the root CA and intermediate CA certificates in the Server Trust Certificate Chain section of the administration user interface. This certificate trust chain is deployed to the workspace when the workspace is provisioned to the device.

If you suspect that a root CA certificate or intermediate CA certificate in that certificate trust chain has been compromised and you want to use another certificate in its place, this sequence of steps must be followed to ensure the new certificate trust chain is deployed to the provisioned workspaces before removing the existing one. If these steps are not following and the certificate chain of trust provisioned to the workspace on the devices becomes broken (for example, by removal of a root CA certificate before the workspaces are able to obtain the replacement root CA certificate), the workspaces on the devices will cease to work properly, and the workspaces must be wiped and reprovisioned. 

To replace a compromised root CA certificate or intermediate CA certificate:

  1. Add the new root CA certificate and any intermediate CA certificates to the Server Trust Certificate Chain section on the Security form in the Horizon Mobile Manager administration user interface. Click Upload New Certificate to add each certificate.
  2. Wait for a lease renewal time period to pass so that all of the provisioned workspaces make a leasing call to the server. When the lease is renewed, the specified set of root CA certificates and intermediate CA certificates (including both the old and the new ones) are deployed to the workspaces.
  3. After the lease renewal time has passed, you can click the Remove button next to the compromised certificate in the Server Trust Certificate Chain section.
At the next lease renewal, the certificate trust chain is again deployed to the provisioned workspaces, not including the removed compromised certificate. From that point on, the workspaces use the updated certificate trust chain.

Caution: Any devices that are disconnected and go without network access for longer than the leasing interval will not obtain the new certificates in step 2. Workspaces on devices that are disconnected for a time period that extends past that leasing interval such that they do not obtain the new certificates will not function properly when the devices regain network access. Those workspaces will have to be wiped and reprovisioned.

Recovery Procedure If a Root Certificate is Accidentally Removed from the Server Trust Certificate Chain

If a Horizon Mobile Manager user that has the Administrator role accidentally clicks Remove next to a root certificate in the Server Trust Certificate Chain list, the system displays a warning that deleting the root certificate could result in a catastrophic failure, because already provisioned workspaces could lose the ability to trust communications with the server when the root certificate is deleted.

If the administrator selects to proceed with deleting the root certificate without following the procedures for replacing it with another root certificate, and then needs to restore the earlier configuration, you can use the following procedure to restore the removed root certificate to the certificate trust chain:
  1. Log in to the virtual appliance's Linux operating system as the root user. Use the password that you set when you configured the Horizon Mobile Manager virtual appliance. If you didn't change the default password, enter vmware as the password.
  2. Run the following commands:

    su tcserver
    mkdir /opt/vmware-mmp/repo/security/certs-for-devices/internal-ca-root
    cp /opt/vmware-mmp/repo/security/root/cert.pem /opt/vmware-mmp/repo/security/certs-for-devices/internal-ca-root/

  3. In the Horizon Mobile Manager administrative interface, refresh the Security page. The root CA certificate is restored to the Server Trust Certificate Chain list.
After the deleted root CA certificate is restored, you must wipe and reprovision the workspaces so that the restored certificate trust chain is deployed to the devices.

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

  • 0 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.
What can we do to improve this information? (4000 or fewer characters)
  • 0 Ratings
Actions
KB: