Unable to Connect to SSL Services

This article is aimed at helping you to troubleshoot if you run into problems configuring SSL in LAE and any node that needs to use SSL, for example the HTTP, FTP or Salesforce nodes.

For information on how to configure SSL in Data3Sixty Analyze, see the Help section (Getting Started > Reference > SSL configuration).

For more information on how SSL works, see the Technical Note at the end of this article.

GUIDELINES:

1. Ensure you have imported the public certificate into the keystore.
2. Ensure certificates have been imported into the correct keystore (there may be many JRE / JDKs) 
3. Ensure the correct keystore is in use. 
4. Check if your Anti Virus tool has "SSL Scanning" blocking SSL/TLS. If so it should be disabled or alternatively set exceptions for the target addresses. 
5. Ensure authentication allows plain text, if connecting to a mail server.
6. Using an online SSL Server Test tool, verify that the target server is configured to serve SSL correctly.
7. As a last resort, the keystore may have expired. If that's the case you should upgrade Java to the latest version supported by your application.

If all of the above are in order, then use the SSL Poke graph to investigate further...

STEPS:

1. Download SSLPoke.brg (attached)

2. Execute the graph, changing the URL and port appropriately. The node defaults to port 443 which is the default used for HTTPS connections in web browsers. SFTP uses port 22 by default.

The Lavastorm version of the node fails by default if it is unable to open the SSL connection. But that's ok because it still writes all the information to the output pins. The error only indicates the success or failure opening the connection, not the success or failure of gathering information.

SSL poke can be used to help debug the validation process and find more information about why a certificate may be failing the validation check.

TECHNICAL NOTE:

HTTPS, SFTP, LDAP, EMAIL, and other services often use SSL to:

1. Encrypt the messages being sent back and forth.
2. Validate that they are communicating with a service that can be trusted.

When you connect using HTTPS in a web browser, the web browser is doing this for you.
Several nodes in Lavastorm and Data3Sixty Analyze also use SSL in the same way.

Sometimes in an attempt to establish a secure connection for the purposes of accessing applications that are encrypted with SSL, an exception is thrown and the connection is refused.  This is because Java uses SSL to connect to another application, but it will not be able to connect unless it can trust the application. This trust is established using a keystore, otherwise commonly known as a truststore. The keystore houses a list of the known CA (Certificate Authority) certificates and Java will trust only two types:

- certificates that are signed by a CA and stored in the keystore

- public certificates that are validated using the CA signed certificates in the keystore.

The connecting device (eg. a web browser or a node) will check to see if the certificate was issued by a trusted CA. It will keep searching until either a trusted CA is found and a secure connection is established, or a trusted CA cannot be found and usually an error is displayed.

The list of SSL certificates in the keystore (from the root certificate to the end-user certificate) is known as an SSL Certificate Chain and Java will trust any certificates signed by them. 

Java does not trust self-signed certificates (a certificate that is not signed by a CA) or a certificate chain that does not exist within the Java keystore, and therefore fails to establish a connection to the application.