Unable to connect to OPSWAT Product instances that have enabled HTTPS mode

When adding a new OPSWAT Product instance that has enabled HTTPS mode, it is possible to encounter several common errors as shown below.

The server's security certificate is not trusted.

One possible cause is that the domain that the instance belong to is not recognized as a trusted host, such as because of missing certificates. To add certificates to OPSWAT Central Management's trust store, please follow the below guidelines

1. Locate the root certificate file (.crt) for the product instance.

2. From an elevated command-line interface, enter the command:

   1. For Windows:

      1. "%JRE_HOME%\bin\keytool" -importcert -keystore "%JRE_HOME%\lib\security\cacerts" -storepass <password> -alias "<alias>" -file "<rootCA.crt path>"
      2. For example: "%JRE_HOME%\bin\keytool" -importcert -keystore "%JRE_HOME%\lib\security\cacerts" -storepass changeit -alias "ocmCA" -file "C:\Users\admin\Downloads\ocm.crt"

   2. For Linux:

      1. "$JRE_HOME/bin/keytool" -importcert -keystore "$JRE_HOME/lib/security/cacerts" -storepass <password> -alias "<alias>" -file "<rootCA.crt path>"
      2. For example: "$JRE_HOME/bin/keytool" -importcert -keystore "$JRE_HOME/lib/security/cacerts" -storepass changeit -alias "ocmCA" -file "/etc/somewhere/ocm.crt"

The host machine should have the JRE_HOME (or JAVA_HOME if OPSWAT Central Management is using JDK) environment variable already set so the command can work properly. Replace the following fields with the correct information.

1. <password>: The keystore's password

2. <alias>: The certificate's alias.

3. <rootCA.crt path>: The path to the product instance's root certificate file.

3. Restart OPSWAT Central Management for the changes to take effect.

Another cause is that the certificates may be invalid if they have already been added. In this case, please verify that the certificates are valid and add them again if necessary.

Could not reach the server.

The "Could not reach the server" error is a catch-all for miscellaneous connection errors. One such error is that the product instance's server address does not match its SSL certificate

To troubleshoot this error, first locate the gears_product_service.log.

• On Windows: <Install folder>\OPSWAT\Central\tomcat\logs\gears_product_service.log
• On Linux: /opt/ocm/tomcat/logs/gears_product_service.log

As an example, we have the instance testCore with the server address https://testhost:8008. This instance uses the SSL certificate with the Common Name (CN) testcore. There should be logs of the failed connection attempt similar to the snippet below:

ProductServiceImpl - ----- Start checking connection of: testCore

ProductServiceImpl - Try to get product version

ProductServiceImpl - Exception occurs when trying to connect to instance. Root cause: HTTPS hostname wrong:  should be <testhost> executing GET https://testhost:8008/version

ProductServiceImpl - Could not get product version, return message: Could not reach the server.

ProductServiceImpl - ----- Finish checking connection of: testCore

ProductServiceImpl - Could not reach the server.

The root cause "HTTPS hostname wrong: should be <testhost> executing GET https://testhost:8008/version" is logged because the SSL certificate's CN testcore does not match with the server address https://testhost:8008

There are several solutions for this issue:

• Change the server address to match the SSL certificate, assuming the new address is valid.

  • Using the example, you would change the server address to https://testcore:8008 to match the SSL certificate.

• Generate a new SSL certificate matching the desired server address and add it to the product instance.

  • Using the example, you would generate a new certificate with the CN testhost to match the desired address https://testhost:8008.