The following error may be seen in the TIBCO LogLogic Universal Collector Console in a popup window as a result of performing a test connection with secure ULDP (ULDPS) or TLS TCP syslog to LogLogic LMI:

The server does not answer. Check that the firewall is configured properly and that the IP, Hostname or Port are correct. The remote server may also be down or unreachable.

Although the above error is also reported in other scenarios, such as when the LMI appliance is completely offline, if the UC host is using Java 1.8.0u201 or higher with ULDPS or TLS TCP syslog and the LMI appliance has been confirmed to be operating correctly, then the error is most likely due to an issue with TLS cipher suites.

Another way to confirm if it's a cipher suite issue is if the following events are seen on the LogLogic LMI end of the connection in /var/log/sys.log:
2019.03.12 15:27:53 LOG5[3]: Service [SecureULDP] accepted connection from ::ffff:192.168.1.196:51737
<29>Mar 12 15:27:53 logapp stunnel: LOG5[3]: Service [SecureULDP] accepted connection from ::ffff:192.168.1.196:51737
2019.03.12 15:27:53 LOG3[3]: SSL_accept: Peer suddenly disconnected
<27>Mar 12 15:27:53 logapp stunnel: LOG3[3]: SSL_accept: Peer suddenly disconnected
2019.03.12 15:27:53 LOG5[3]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
<29>Mar 12 15:27:53 logapp stunnel: LOG5[3]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
The events listed above in the LMI sys.log file will occur both as a result of a failed test connection but also each time UC attempts making a connection to LMI (every 1 minute) when the behavior is a result of the known issue documented in this article.

The errors above from UC and LMI are indicating that no attempt at all was made to establish the encrypted tunnel. A packet capture of this connection attempt also will show this. The first step for establishing a secure tunnel is for the UC host to send an SSL Client Hello message to the server (i.e. LMI) but the packet capture shows this is never sent by UC.

All this indicates a fundamental problem, such as one related to cipher suites, exists that is preventing UC from attempting to establish the tunnel. If the UC host was recently upgraded to Java 1.8.0u201 (or higher) then the behavior described above is most likely due to cipher suites. Per the 1.8.0u201 release notes Oracle has disabled anonymous and null cipher suites. That change has generated a known issue with Universal Collector.

How does that change affect UC and the encrypted tunnel to LMI? There are 2 ways that UC is affected:

The first is when using ULDPS. When using ULDPS the UC Console provides the flexibility to enable authentication separately from encryption. UC uses a different cipher suite when encryption is enabled versus if only authentication is enabled. The cipher suite used when encryption is not enabled is one that specifically excludes an encryption algorithm in the suite, which is expected behavior given the user's choices in the UC Console GUI. A cipher suite that doesn't have an encryption component included in it is what is known as a null cipher. For example this is a non-NULL cipher: TLS_RSA_WITH_AES_128_CBC_SHA. This is an example of a NULL cipher: SSL_RSA_WITH_NULL_SHA.

For most situations anyone who uses a cipher suite with SSL certificates is going to be using it for encryption but there are exceptions. In the case of UC, a user who only wants to use certificates for authentication purposes rather than for confidentiality purposes can do so. But starting with Java 1.8.0u201 that requires some changes to the Java configuration.

The other way that UC is affected is when using TLS TCP syslog to forward data to a product like LogLogic LMI. When TLS TCP syslog is used the cipher suite used is an anonymous cipher.


How to resolve this behavior?
Refer to the resolution section for how to resolve this issue in the context of the environments documented in the Environment field.

Oracle or OpenJDK Java 1.8.0u201 and higher, ULDPS or TLS TCP syslog between LogLogic UC and LogLogic LMI

If using secure ULDP (i.e. ULDPS) there are 2 options:

• The easiest solution is to simply enable encryption alongside authentication. This will make UC use a cipher that uses an encryption algorithm and therefore a null cipher suite will no longer be used.
• If for some reason encryption cannot be enabled then editing Java's java.security file is necessary to remove null cipher suites from the disabled algorithm list. Follow the procedure at the end of this resolution section.

If using TLS TCP syslog there is only 1 option:

• Remove anon cipher suites from the disabled algorithm list. Follow the procedure at the end of this resolution section.

Whether removing the anonymous or null cipher suites from the java.security file the procedure is basically the same.
1. Open the java.security file for editing (make a backup beforehand if you wish). It is located in <JAVA_HOME>\lib\security.
2. Find the line that looks like the one shown below. There are multiple disabledAlgorithm properties in the file so be sure you find the one specifically for jdk.tls as shown below.
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC, anon, NULL
3. Edit the line to look like this (thus removing both anon and NULL cipher suites from the disabled list) or only remove the cipher suite type that you need removed, whether that is the anon suite if you are using TLS TCP syslog or NULL if you are using ULDPS without encryption:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC
4. Save the file.
5. Restart both the UC Console and the UC service. Each one uses its own JVM. Restarting the UC Console is only necessary if you want to confirm the change you made is successful by performing a test connection before you restart the entire service. You can restart the Console without restarting the UC service itself but logs won't be forwarded until the UC service is restarted. If the test connection fails then the forwarding will still fail so the test connection can be used to ensure your changes are correct before restarting the service.
 To restart the UC service in Windows using the command line (be sure to open cmd.exe as administrator) issue the following 2 commands in this order:
> net stop loglogic-uc
> net start loglogic-uc
In Windows you can instead use the services.msc MMC snap-in for restarting the service if you prefer.

To restart the UC service in Linux using the command line issue the following 2 commands in this order as root:
$ service loglogic-uc stop
$ service loglogic-uc start

A known compatibility issue exists with TIBCO LogLogic Universal Collector and Java 1.8.0u201 and higher. This article describes the symptoms, explains the issue and provides workarounds.

Java 1.8.0u201 release notes - https://www.oracle.com/technetwork/java/javase/8u201-relnotes-5209271.html