This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to Article Number 000385088 for more information about troubleshooting BMC products in containers. Does Remedy support TLS protocol? Remedy works with TLS protocol since the time it has become a Java program from v.9.0 onwards. Thus now Remedy can work with SSL or TLS. How to create Keystore and import the certificate to configure Remedy with SSL/TLS? General Steps: 1. Export the certificate from the respective server. 2. Use the key tool (or any Keystore tool) to import the certificate. 3. Configure Remedy using SSL. Steps to import the certificate to configure Remedy work with SSL or TLS protocol are as below: 1. Obtain a certificate from the LDAP, Exchange, or another server with which you want to establish an SSL/TLS connection, i.e. export the client certificate with .cer extension. (.crt and .der files can be used). 2. Copy the certificate file to the AR Server into which you want to import it. For example C:\Certificates\xxx.cer Where xxx is the certificate name. 3. Verify which Java path is being used by the AR System server (example: C:\Program files\Java\jre\bin). This can be verified from the armonitor.cfg/armonitor.conf file. 4. Use a tool to import the certificate. You can use a 3rd party tool such as Key Store Explorer or the built-in key tool. To use the key tool: Open a command prompt and use the below command to import the certificate that you downloaded from the server (xxx.cer)
Note: You can provide a Keystore value that is not an existing file if you want to use your own Java Key Store.
If you provide a value that does not correspond to an existing file, a new Keystore will automatically be created Command: keytool –import –noprompt –trustcacerts –keystore {path to cacerts} -storepass “<password>” –alias <aliasname> -file <Full path to certificate file name> or keytool -import -trustcacerts -alias {aliasname} -file "{Full path to certificate file name}" -keystore "{path to cacerts}" -storepass "{Password}" -keypass "{KeyPass}" Where: Path to cacerts: Java path being used by the AR System Server under \lib\security\cacerts Password: any password with which the Keystore can be accessed, by default, it is "changeit" Aliasname: alias name for the certificate to be installed, for example: AREALDAP Full path to certificate file name: path where you have copied the .cer file, example: c:\Cert\xxx.cer KeyPass: any keypass with which the Keystore can be accessed, by default, it is "changeit" The above command will import the certificate into the cacerts where it will be available to use with the AR server. If you are using a Keystore other than the default cacerts in the Java path being used by the AR System Server under \lib\security\cacerts, you need to add the following parameters to the arserver.config file in the ARSystem Install directory: jvm.option.22 = -Djavax.net.ssl.trustStore=<path to file> jvm.option.23 = -Djavax.net.ssl.trustStorePassword=<password> jvm.option.24 = -Djavax.net.ssl.keyStoreType=JKS Note that the jvm.option value will be dependent on your specific server configuration. Note: If the certificates are imported in Java's own Keystore "cacerts" and depending upon its type, you may consider using the below option: jvm.option.24=-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT Additional information: You can also use Keystore explorer utility to validate certificates. Check this with your AD Admin. https://keystore-explorer.org/downloads.html Note: In some cases after creating certificates bundle some steps might be missing which lead to error: Post RSSO Cert renewal Discovery RSSO-security-error-Unexpected-error-communicating-with-the-RSSO-server-Could-not-find-a-suitable-TLS-CA-certificate-bundle-invalid-path-usr-tideway-etc-rsso-ca-bundle error received Solution: Replaced the existing certificate bundle, designating and securely pinning the Certificate Authority (CA) certification using the "Get Server Certificate" command, as the previous certificates lacked specific assignment for SSL/TLS verification. |