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.
Certificates copied from other servers or wildcard certificates being reused without completing this process are unsupported. Some certificate authorities offer renewals based on your original signing request.
To install a new CA signed certificate perform the following tasks:
- Remove the default self-signed certificate
- Generate a new self-signed certificate
- Create a certificate signing request
- Generate a valid certificate through a CA
- Add the CA signed certificates
- Reset the VM Access Proxy
- Reset the connection in Commander
- Validate the certificate
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.
- Log in to the VM Access Proxy machine.
- Browse to the correct directory:
cd /var/data/conf
- Enter the following command:
sudo keytool -delete -alias tomcat -keystore "keystore" -storepass changeit
- Enter the root password again if prompted.
- Confirm that the deletion was successful:
keytool -list -v -keystore "keystore" -storepass changeit
If the remoteaccess container was stopped prior to deleting the certificate, it cannot 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.
- 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
dnsandipvalues 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?
- When prompted, enter the root password again.
- 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 does not recommend using a password. Press ENTER to proceed past this prompt.
- Confirm that the keystore has one entry:
keytool -list -v -keystore "keystore" -storepass changeit
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 are asking to validate. If no details about the server have changed, your CA may store your CSR or allow them to be reused. Alternatively, you can use Active Directory Certificate Services as your authority. For more information, see the Generating and Installing an SSL Certificate Snow Globe article.
Depending on the CA you are working with, you will 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.
- 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 do not 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
- Copy the
certreq.csrfile that is generated to your local machine using your preferred method. - Through an SFTP client, connect to the Proxy server through IP or FQDN.
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.
- Navigate to
/var/data/confin the SFTP client's remote site area. - Select the
certreq.csrfile 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 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
- Through an SFTP client, connect to the Proxy server through IP or FQDN.
- Navigate to
/var/data/conf. - 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/confdirectory. - If prompted, enter Yes.
Installing p7b certificates
- To browse to the correct directory, enter the following command:
cd /var/data/conf
- To install the certificate, enter the following command:
sudo keytool -import -trustcacerts -alias tomcat -file certnew.p7b -keystore "keystore" -storepass changeit
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.
- To browse to the correct directory, enter the following command :
cd /var/data/conf
- 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 are not clear which certificate is which, contact your certificate vendor for details.
If you do not install a CA’s intermediate certificate when one is required, you will receive the following error when attempting to import the certificate for your request: keytool error: java.lang.Exception: Failed to establish chain from reply
- If you receive the error message
keytool error: java.security.cert.CertificateException: java.io.EOFExceptionyou 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 do not 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:
- Select Configuration > System.
- Click the Integration tab.
- On the Integration page, for the Console Proxy, click Edit.
- 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.
If you are 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.
