A java.io.EOFException occurs before an SSL connection is established. You will see this error occurring in different logs depending on what is trying to connect to DS.
If you are using DS as an identity store, you will notice that you cannot see any identities in the repository.
You will also see the following Connect Errors in the CoreSystem, IdRepo or Session debug logs depending on what type of stores you are using DS for (configuration, identity or CTS):Connect Error: No operational connection factories available at org.forgerock.opendj.ldap.LdapException.newLdapException(LdapException.java:206) at org.forgerock.opendj.ldap.LdapException.newLdapException(LdapException.java:144) at org.forgerock.opendj.ldap.LdapException.newLdapException(LdapException.java:113) at org.forgerock.opendj.ldap.LoadBalancer.getMonitoredLdapClient(LoadBalancer.java:411) at org.forgerock.opendj.ldap.LoadBalancer.access$3300(LoadBalancer.java:68) at org.forgerock.opendj.ldap.LoadBalancer$LdapClientSocketImpl.getLoadBalancedContext(LoadBalancer.java:787) at org.forgerock.opendj.ldap.LoadBalancer$LdapClientSocketImpl.lambda$getLoadBalancedContext$4(LoadBalancer.java:797) ... Caused by: Connect Error: The LDAP connection has failed because an error occurred during the SSL handshake: java.io.EOFException at org.forgerock.opendj.ldap.LdapException.newLdapException(LdapException.java:206) at org.forgerock.opendj.ldap.LdapException.newLdapException(LdapException.java:144) at org.forgerock.opendj.ldap.LdapException.newLdapException(LdapException.java:113) at org.forgerock.opendj.grizzly.GrizzlyLdapSocketConnector$CompletionHandlerAdapter$1.failed(GrizzlyLdapSocketConnector.java:274) ... 28 more Caused by: java.io.EOFException ... 27 more
You will see the following errors in openidm0.log after starting IDM:May 28, 2019 2:27:01 PM org.glassfish.grizzly.filterchain.DefaultFilterChain execute FEIN: GRIZZLY0013: Exception during FilterChain execution java.io.EOFException at org.glassfish.grizzly.nio.transport.TCPNIOTransport.read(TCPNIOTransport.java:630) at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:75) at org.glassfish.grizzly.filterchain.TransportFilter.handleRead(TransportFilter.java:173) at org.glassfish.grizzly.ssl.SSLBaseFilter$SSLTransportFilterWrapper.handleRead(SSLBaseFilter.java:1145) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ... May 28, 2019 2:27:01 PM org.forgerock.openidm.repo.opendj.impl.OpenDJRepoService waitForConnection WARNUNG: Unable to get DS connection. Next attempt at Tues May 28 14:28:01 CEST 2019
You will see connect errors similar to the following on the Rest2LDAP side if logging has been enabled:29-May-2019 15:07:42.780 WARNING [OpenDJ LDAP SDK Client Selector(1) SelectorRunner] org.forgerock.i18n.slf4j.LocalizedLogger.warn Connection factory 'CachedConnectionPool(size=0[in:0 + out:0 + pending:0], maxSize=24, blocked=0, ldapClient=org.forgerock.opendj.ldap.LdapClientImpl@2517fc05)' is no longer operational: Connect Error
You can enable logging in the Rest2LDAP gateway servlet (if it runs in the Apache Tomcat™ web container) by specifying logging properties in the logging.properties file (located in the WEB-INF/classes directory where the gateway servlet is deployed).
SSL debugging - AM
If you enable SSL debug logging for AM, you will just see that the secure ciphers are being ignored, for example:Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
You can enable SSL debug logging as described in FAQ: SSL/TLS secured connections in AM and Agents (Q. How do I debug SSL connection issues?).
SSL debugging - DS
If you enable SSL debug logging for DS, you may see errors similar to the following in the DS server.out log:%% Initialized: [Session-7, SSL_NULL_WITH_NULL_NULL] LDAPS 0.0.0.0 port 40636(2) SelectorRunner, fatal error: 40: no cipher suites in common javax.net.ssl.SSLHandshakeException: no cipher suites in common %% Invalidated: [Session-7, SSL_NULL_WITH_NULL_NULL] LDAPS 0.0.0.0 port 40636(2) SelectorRunner, SEND TLSv1.2 ALERT: fatal, description = handshake_failure LDAPS 0.0.0.0 port 40636(2) SelectorRunner, WRITE: TLSv1.2 Alert, length = 2 LDAPS 0.0.0.0 port 40636(2) SelectorRunner, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common Using SSLEngineImpl.
You can enable SSL debug logging as described in FAQ: SSL certificate management in DS 5.x or 6.x (Q. How do I debug a SSL handshake error?).
Additionally, the server.out log does not show the more secure cipher suites that have been enabled.
Upgraded to JDK 1.8.0_192 or later, or JDK 11.
Restricted cipher suites in DS to more secure ones such as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, which use protocol version TLSv1.2.
Installed DS using the --productionMode setup option (which restricts the available ciphers and forces the protocol version to TLSv1.2).
AM connects to DS using the embedded LDAP SDK and IDM connects to DS using the Grizzly LDAP connector (which in turn uses the Rest2LDAP servlet).
These mechanisms for connecting to DS securely do not correctly support the TLSv1.2 protocol, whereas using the more secure ciphers and installing DS in production mode forces the protocol version to TLSv1.2. In Java versions prior to JDK 1.8.0_192, unsupported cipher suites were simply ignored, which is why these connections continued to work despite the mismatch in protocol versions.
Changes were introduced in JDK 1.8.0_192 (JDK-8162362 : Introduce system property to control enabled ciphersuites), which changed how the JDK determined which cipher suites (and resulting protocol) to use. As a consequence of these Java changes, AM, IDM and the Rest2LDAP cannot communicate with DS using a SSL/TLS secured connection because it uses different cipher suites and protocol to the DS server; both the client and server must support the same cipher suites and protocol agreed upon when attempting to establish a secure connection.
This issue can be resolved by as follows:
- If you are experiencing this specific issue with AM connecting to DS, this can be resolved by upgrading to AM 6.5 or later, or AM 5.5.2; you can download this from BackStage.
- If you are experiencing this specific issue with IDM or Rest2LDAP connecting to DS, this can be resolved by upgrading to DS 6.5 or later, or DS 5.5.3; you can download this from BackStage.
You can workaround this issue using one of the following options:
- Downgrade to JDK 1.8.0_191 or earlier.
- Add one or more cipher suites that use the TLSv1.1 or TLSv1.0 protocol version, for example: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, and so on. See Security Guide › TLS Protocols and Cipher Suites for further information. You should review any security risks of using alternative cipher suites before proceeding.
Java 8 does not support keys with 256-bit AES encryption by default, so you may need to install the Oracle® Java JCE unlimited strength jars if you want to use keys with 256-bit AES encryption. See Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files Download for further information and links to download the jars.