Troubleshooting Secured Socket Layer related issues for AR System Server and Mid Tier
On the AR System Server and Mid Tier, configure a Secured Socket Layer (SSL) for the following scenarios:
- Apache Tomcat publishing webservices over https
- Developer Studio loading a WSDL over https
- Mid Tier making https calls to Smart Reporting
If an issue occurs when you enable an SSL or when you are working with the SSL, see the following symptoms.
Symptoms
- A Jetty service or Apache Tomcat service does not start when you enable the SSL.
- A Jetty service or Apache Tomcat service starts, however, the port does not respond.
- Unable to establish connection between SSL and Remedy.
- Connection from a browser to Apache Tomcat (Mid Tier)
- Connection from the REST client to Jetty server
- Connection from the Developer Studio to Mid Tier while retrieving WSDL from the Mid Tier
- When a workflows calls the third-party REST API
- When a workflow calls the third-party SOAP Web service
- When loading a third-party WSDL to Developer Studio
- When a Java application, such as Developer Studio tries to establish a connection with an SSL endpoint.
- When a Java application, such as Developer Studio tries to establish a connection with an SSL endpoint that requires a client certificate.
Scope
All applications and clients where the SSL is enabled.
Resolution
Perform the following steps to make sure that an SSL connection is established between the AR System Server/Mid Tier and client:
| Step | Task | Description | ||||||||||||||||||||||||||||
| 1 | Install SSL certificates on the AR System Server to enable the SSL service | The procedure to install SSL certificates depends on the component that provides a service protected by SSL.
| ||||||||||||||||||||||||||||
| 2 | Make sure that the service responds to the SSL port | After you enable the SSL, make sure that the service responds to the SSL port. For more information, see the knowledge article
How to test if a webserver is responding to requests - AR System Server
| ||||||||||||||||||||||||||||
| 3 | (Optional) Verify causes when the service does not respond |
| ||||||||||||||||||||||||||||
| 4 | Identify the validity of server certificates | A certificate is considered as valid if it is trusted by the client. The client gets a PUBLIC certificate from the server. Analyze the certificate chain and check the client's trustStore. A certificate can be validated with any type of client. However, each client can have its own trustStore.
| ||||||||||||||||||||||||||||
| 5 | Verify the client used to establish the SSL connection | Note-down the client, the trustStore, and the client Keystore. The client Keystore is required only for the two-way SSL connection. The following table describes the client, the trustStore, and the client Keystore:
Important: If the AR System Server is signed by a well-known certificate authority (CA), such as LetsEncrypt or Verisign, the certificates are trusted and these steps just ensure that the trust relationship is already established. | ||||||||||||||||||||||||||||
| 6 | Analyze the javax.net.debug log if the certificates are not trusted by the client | Analyze the issue by collecting the javax.net.debug logs.
Warning: You can import certificates on the client trustStore. However, we do not recommend to use this as a solution because this might create an additional task. Also, once the certificate expires, you need to import it again on all possible clients. If a signed certificate expires, the certificate needs to be changed only on the server. | ||||||||||||||||||||||||||||
| 7 | Enable Web service to request client certificates | The client certificate uses an additional SSL/Transport Layer Security (TLS) layer. We recommend using a well-known certificate authority (CA). Most Java servers and clients adhere to the standards. After the client validates the server certificate, it sends the certificate to the server for validation. If the client does not send a certificate, the SSL connection is not established.
|
After you determine a specific symptom or error message, use the following table to identify the solution:
| Symptom | Location | Action | Reference |
|---|---|---|---|
The service does not start after you enable the SSL | Web server (Apache Tomcat or Jetty server) | Check if the certificate is valid. See step 4. | NA |
| A Java 6 application cannot connect to an SSL service | Any integration application that tries to connect to an SSL Web service | We recommend to upgrade the Java version on the client side. Java clients on earlier versions do not support all TLS versions. |
Transport level security (TLS) and Java
|
Cannot change the self-signed certificates and unable to connect to the client | Java or browser based clients | Make sure that the steps described in the Resolution section are followed. | See the knowledge article
Remedy AR System Server - How to import certificate for SSL/TLS-Remedy AR System Server
|
The Web server requests a client certificate and the client does not allow to connect | Java clients try connecting to an SSL service. The server requests client certificates | Contact the vendor of your application. The vendor provides client certificates for each client. | See the knowledge article
How to install client certificates in java client
|
| After upgrading the Java version on client or server, the integration fails with SSL handshake error | Analyze and collect the javax net debug logs on the client and server. Either the trust relationship is lost or the Cipher compatibility might have an issue. | NA | |
| The integration is not successful | Collect the information and send it to BMC Customer Support as a new case. Use the following description format: SSL problem between <Client> and <Server>, running in <Dev, QA or Production> after <actions performed> . The last time it was working fine was <date time>
| NA |
Comments
Log in or register to comment.