Installing SSL Certificates on VM Access Proxies

When you install a Commander VM Access Proxy, a Secure Sockets Layer (SSL) certificate is installed to its Tomcat web server that confirms the identity of that server when Commander connects remote control sessions. This default certificate is self-signed; that is, no certificate authority (CA) has validated the identity with a CA certificate.

If you use the default self-signed certificate, when users attempt to connect to VMs, their browsers will warn them that the connection is untrusted, and they have to decide whether or not to trust it when they initiate their session. However, you can purchase and install a CA signed certificate that will be automatically trusted by users' browsers.

The steps required to install a new CA signed certificate are:

Remove the default self-signed certificate

First, you must remove the default self-signed certificate that was created during the installation of Commander because there are no details to uniquely identify your organization. Before doing so, take a snapshot of the Commander server so that you can restore it to a known good state if necessary.

  1. Log in to the VM Access Proxy machine.
  2. Browse to the correct directory:

    cd /var/data/conf

  3. Enter the following command:

    sudo keytool -delete -alias tomcat -keystore "keystore" -storepass changeit

  4. Enter the root password again if prompted.
  5. Confirm that the deletion was successful:

    keytool -list -v -keystore "keystore" -storepass changeit

Note: If the remoteaccess container was stopped prior to deleting the certificate, it can't be started until you have completed the next procedure. Attempting to start it will result in exceptions about the missing certificate.

Generate a new self-signed certificate

The next step is to install a new self-signed certificate, which will contain details about your organization that must be shared with the CA. This ensures that when you create the signing request, all of your organization’s details are included in the Tomcat web server.

  1. In the same directory used for the procedure above, issue the following command:

    sudo keytool -genkey -alias tomcat -keyalg RSA -keystore "keystore" -ext san=dns:proxy.omega.pv,ip:10.10.20.107 -storepass changeit

    or

    sudo keytool -genkey -alias tomcat -keyalg RSA -keystore "keystore" -ext san=dns:proxy.omega.pv -storepass changeit

    You must include at least one Subject Alternative Name for Google Chrome to work. To do so, replace the dns and ip values in this portion of the command, using the specifics that match your Commander server:

    san=dns:fqdn.yourCommander.com,ip:xxx.xxx.xxx.xxx

    Use commas to add as many alternative names as you require.

    For more information on Subject Alternative Names, see What is the SSL Certificate Subject Alternative Name?

  2. When prompted, enter the root password again.
  3. When prompted, provide and confirm the information the certificate contains.
    • First and Last Name: The fully qualified domain name (FQDN) of the Access Proxy server. For example, proxy.embotics.com.
    • Organizational Unit: The name of your department within the larger organization. For example, Engineering.
    • Organization: The name of your organization. For example, Super Corporation.
    • City or Locality: The city where your organization is based. For example, Toronto.
    • State or Province: The state or province where your organization is based. For example, Ontario.
    • Two-letter Country Code: The country where your organization is based. For example, CA for Canada or US for the United States of America. See a complete list.
    • Key Password for Alias: Snow Software doesn't recommend using a password. Press ENTER to proceed past this prompt.
  4. Confirm that the keystore has one entry:

    keytool -list -v -keystore "keystore" -storepass changeit

Note: If the remote access container was previously stopped, it can now be started again without any exceptions because a new certificate has been created and installed.

Create a certificate signing request

The next step is to create a certificate signing request (CSR) file which you will submit to a CA. This proves the identity of the server you're asking to validate. Alternatively, you can use Active Directory Certificate Services as your authority. For more information, see the Generating and Installing an SSL Certificate with Active Directory Certificate Services Snow Globe article.

Depending on the CA you're working with, you'll provide the CSR file either by uploading it through their customer service portal or emailing it to your sales representative. If you aren’t sure how to provide it to your CA, contact their technical support or sales teams.

  1. Still in the same directory used for the procedure above, issue the command:

    sudo keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore "keystore" -ext san=dns:proxy.omega.pv -storepass changeit (note, you don't need to specify the IP)

    Or if you have more than one alternative name:

    sudo keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore "keystore" -ext san=dns:proxy.omega.embotics.com,dns:localhost,ip:10.10.20.107,ip:127.0.0.1 -storepass changeit

  2. Copy the certreq.csr file that's generated to your local machine using your preferred method.
  3. Through an SFTP client, connect to the Proxy server through IP or FQDN.

    Tip: When connecting, if a warning is displayed that the connection is untrusted, select the option to always trust this host and add the key to the cache.

  4. Navigate to /var/data/conf in the SFTP client's remote site area.
  5. Select the certreq.csr file and download it onto the local machine.

Generate a valid certificate through a CA

With the certreq.csr file on your local machine, you can now provide this signing request to your CA. The CA your organization uses may be an Active Directory certificate service, or an external authority such as GoDaddy or Veritas.

You must consult with your CA and follow their unique procedure to generate a chained certificate including the host, root, and intermediary certificates, or a single file in the p7b format.

Send the file to your CA, or Active Directory certificate service (for more information, see the Generating and Installing an SSL Certificate with Active Directory Certificate Services Snow Globe article).

Add the CA signed certificates

To add CA signed certificates to the VM Access Proxy, you must first upload the certificates to the VM Access Proxy server, and then you can install them.

The installation procedure is different for p7b and chained certificates. Note that depending on your provider, the instructions may vary from those provided below. If you have a support agreement with a CA, you may want to arrange a call with them, and you can request that Snow Technical Support be present to assist.

Uploading the certificates

  1. Through an SFTP client, connect to the Proxy server through IP or FQDN.
  2. Navigate to /var/data/conf.
  3. Drag the files returned from the CA on the remote site file listing to copy the file (for example, certnew.p7b) onto the VM Access Proxy server's /var/data/conf directory.
  4. If prompted, enter Yes.

Installing p7b certificates

  1. To browse to the correct directory, enter the following command:

    cd /var/data/conf

  2. To install the certificate, enter the following command:

    sudo keytool -import -trustcacerts -alias tomcat -file certnew.p7b -keystore "keystore" -storepass changeit

Tip: If you receive the error message keytool error: java.security.cert.CertificateException: java.io.EOFException you may have a trailing space in your signed certificate. Open the certificate file in a text editor and remove any spaces leading into or trailing the encrypted content, and import the certificate again.

Installing chained certificates

If you receive a package with more than one certificate, they must be installed in the proper order and be assigned to the proper alias’s.

  1. To browse to the correct directory, enter the following command :

    cd /var/data/conf

  2. To specify the proper alias and associated certificate type for each certificate, enter the following command:

    sudo keytool -import -trustcacerts -alias %aliasname% -file %certname% -keystore "keystore" -storepass changeit

    Note that you must enter the certificates in the proper order: enter the root certificate first, then the intermediary certificate, and finally the host certificate. If you aren't clear which certificate is which, contact your certificate vendor for details.

    Type

    Commonly Named

    Alias to Use

    Example

    Root Certificate

    *g2-g1.crt

    Within the certificate it will be issued to the authorizer (for example, Comodo).

    root

    sudo keytool -import -trustcacerts -alias root -file gd_bundle-g2-g1.crt -keystore "keystore" -storepass changeit

    Intermediary Certificate (also known as a Subordinate Certificate)

    *.pem

    intermed

    sudo keytool -import -trustcacerts -alias intermed -file gdig2.crt.pem -keystore "keystore" -storepass changeit

    Host Certificate

    %numbers/letters%.crt

    Within the certificate it will be issued to the proxy server’s hostname.

    tomcat

    sudo keytool -import -trustcacerts -alias tomcat -file e1c2a11d9102cd62.crt -keystore "keystore" -storepass changeit

Note: If you don't install a CA’s intermediate certificate when one is required, you'll receive the following error when attempting to import the certificate for your request: keytool error: java.lang.Exception: Failed to establish chain from reply

Tips:  

  • If you receive the error message keytool error: java.security.cert.CertificateException: java.io.EOFException you may have a trailing space in your signed certificate. Open the certificate file in a text editor and remove any spaces leading into or trailing the encrypted content, and import the certificate again.
  • If you previously had a certificate on the proxy server and are reissuing the certificate, make sure you generate a new certificate (or rekey) and don't attempt to transfer the keystore from an old installation.

Reset the VM Access Proxy

Log in to the VM Access Proxy and issue the command reboot, which will disconnect any active sessions using the VM Access Proxy.

Reset the connection in Commander

To reset the connection:

  1. Select Configuration > System.
  2. Click the Integration tab.
  3. On the Integration page, for the Console Proxy, click Edit.
  4. In the VM Access Proxy dialog, click Next, Next, Finish

    After you click through the wizard, the VM Access Proxy connection will be reset.

Validate the certificate

To validate that the certificate has been installed successfully, browse to the following URL address:

https://<VM Access Proxy FQDN>:8443/RemoteAccess/details

The certificate should have the secure symbol in the address bar of the browser.

Note: If you're changing or applying a new certificate to the VM Access Proxy, you have to restart the Commander Windows service.

Commander then reads the new certificate and will start to communicate securely.