When you install the vCommander® VM Access Proxy, a Secure Sockets Layer (SSL) certificate is installed to its tomcat web server that confirms the identity of the server when vCommander connects remote control sessions. This default certificate is self-signed, which means that your users have to make a decision whether or not to trust it when they initiate their session, because no certificate authority (CA) has validated the identity with a CA certificate.



The image below shows how this decision will be presented by Firefox:





Users can choose to trust the certificate or you can purchase and install a CA certificate that will be automatically trusted by web browsers, by following the procedures below.







Remove the Default Self-Signed Certificate


The first thing that you must do is remove the default self-signed certificate that was created during the installation of Embotics vCommander, because there are no details uniquely identifying your organization.  Before doing so, take a snapshot of the Embotics® vCommander server so that you can restore to a known good state if anything goes wrong.


  1. Login to the Console Proxy appliance (Connecting with Putty will allow clipboard access):

    Username - vcommander
    Password - gRHrB211



  2. Browse the correct directory by issuing the command cd /var/lib/tomcat/conf

  3. Issue the 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 by issuing the following command keytool -list -v -keystore "keystore" -storepass changeit




Important: If the tomcat service was stopped prior to deleting the certificate, it cannot be started until you have completed the next procedure. Attempting to do so 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 certificate authority. This makes sure that when you create the signing request, all of your organization’s details are included in the tomcat web server.


  1. Still in the same directory used for the procedure above, issue the 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 in order for Google Chrome 58 and later to work. To do so, replace the dns and ip: values in this portion of the command, using the specifics that match your vCommander server:
    san=dns:fqdn.yourvcommander.com,ip:xxx.xxx.xxx.xxx
    Use commas to add as many alternative names as you require.

  2. Enter the root password again when prompted.

  3. You are prompted to provide and confirm the information the certificate contains.
    • First and Last Name: Enter 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, Embotics Corporation.
    • City or Locality: The city where your organization is based. For example, Ottawa.
    • 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: Embotics does not recommend using a password, just strike the ENTER key to proceed past this prompt.



  4. Confirm that the keystore has one entry by issuing the following command:
    keytool -list -v -keystore "keystore" -storepass changeit




If the tomcat service was previously stopped, it can now be started again without any exceptions because a new certificate has been created and installed.





Create the Certificate Signing Request



The next step is to create a certificate signing request (CSR) file which you will submit to a certificate authority. This proves the identity of the server you are asking them to validate. Alternatively, you can use Active Directory Certificate Services as your authority.




Depending on the certificate authority you are working with, you will provide the CSR file either by uploading it via their customer service portal or emailing it to your sales representative. If you aren’t sure how to provide it to your certificate authority, 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. Issue the command: sudo service ssh start

  3. Launch Filezilla FTP Client.

  4. Under the File menu, choose Site Manager.

  5. Click New Site and name it Console Proxy.

  6. Enter the hostname or IP address of the console proxy in the Host field.

  7. Choose SFTP – SSH File Transfer Protocol from the Protocol menu.

  8. Choose Normal as the Logon Type.

  9. Enter the Username (vcommander), and Password (gRHrB211).

  10. Click Connect.

  11. You may receive a warning that the connection is untrusted. Check Always trust this host, add this key to the cache and click OK.



  12. Enter /var/lib/tomcat/conf in the Remote site pane.



  13. Double-click certreq.csr to download it onto your local computer, in the location shown in the Local site pane.









Through your Certificate authority, generate a valid Certificate



With the certreq.csr file on your local machine, you are now able to provide this signing request to your certificate authority. The certificate authority your organization uses may be an active directory certificate service, or an external authority such as Godaddy or Veritas. 




You must consult with your certificate authority 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 certificate authority, or Active Directory Certificate services.








Import the CA Signed Certificates





To import the CA signed certificate(s) you will need to first upload the certificate(s) to the Proxy server as described below. 




Use the process below to import the certificates. Note that depending on your provider, the instructions may vary. If you have a support agreement with the Certificate Authority, you may wish to arrange a call with them, and can request Embotics Technical Support be present to assist.




  1. Through SSH, or the console of the proxy server, edit the /etc/tomcat8 director to be writable by issuing the command 
    sudo chmod 777 /etc/tomcat8
        


  2. Launch Filezilla FTP Client, or you may use WinSCP 
  3. Connect to the Proxy server via IP or FQDN 
  4. Navigate to /var/lib/tomcat/conf
  5. Drag and drop the files returned from the certificate authority on the remote site file listing to copy the file (for example, certnew.p7b) onto the proxy servers /var/lib/tomcat/conf directory.

  6. If prompted, enter Yes.




Once the files are available on the proxy server, depending if you received a p7b file, or a chained certificate (3 files) you must follow the correct procedure as outlined below:





Installing a p7b certificate



  1. Browse to the correct directory by issuing the command

    cd /var/lib/tomcat/conf
  2. Issue the following command

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





Troubleshooting:




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





Installing a chained certificate




Note: If you do not install a certificate authority’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 a package with more than one certificate, they must be installed in the following order and be assigned to the proper alias’s in the “keytool -import -trustcacerts” command. 




  1. Browse to the correct directory by issuing the command

    cd /var/lib/tomcat/conf
        


  2. Run the following command specifying the proper alias and associated certificate type in the correct order. (See the chart below)

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





Order
Type
Commonly named
Alias to use
Example
1
Root Certificate
*g2-g1.crt
Within the certificate it will be issued to the authorizer ex. Go Daddy
root
sudo keytool -import -trustcacerts -alias root -file gd_bundle-g2-g1.crt -keystore "keystore" -storepass changeit
2
Intermediary Certificate (Also known as a Subordinate Certificate)

*.pem
intermed
sudo keytool -import -trustcacerts -alias intermed -file gdig2.crt.pem -keystore "keystore" -storepass changeit
3
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




If you are not clear which is which, please contact your certificate vendor for details.





Troubleshooting:




If you receive the error message keytool error: java.security.cert.CertificateException: java.io.EOFException you most likely have a trailing space in your signed certificate. Open the certificate file in a text editor such as notepad 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, please make sure you generate a new certificate (or rekey) and do not attempt to transfer the keystore from an old installation.










Final Steps



To complete the installation, you must Restart the VM Access Proxy, reset the connection in vCommander, then validate the certificate.




Reset the VM Access Proxy




Log into the VM Access Proxy and issue the command "reboot" this will disconnect any active sessions using the VM Access Proxy.







Reset the connection in vCommander.


Within vCommander:



  1. Browse to Configuration > System Configuration. Switch to the Integration tab. 
  2. Under Console Proxy click Edit.

  3. Click OK.






Validate the Certificate




You can validate that the certificate has been installed successfully by browsing to this 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 are changing or applying a new certificate to the VM Access Proxy you will need to restart the vCommander Windows service. 




vCommander then reads the new SSL certificate and will communicate securely going forward.









Additional understanding












See Also






 < 20 MB DELETE