Solutions

Cannot install or use ssoadm in AM 5.x, 6.0.0.x, 6.5.0, 6.5.0.1 and OpenAM 13.x after restricting configuration store (DS/OpenDJ) cipher suites or Java upgrade

Last updated Jun 13, 2019

The purpose of this article is to provide assistance if you cannot install or use ssoadm after restricting cipher suites in the AM/OpenAM configuration store (DS/OpenDJ), installing DS using Production mode or upgrading to Java® JDK 11 or JDK 1.8.0_192 (or later). You will see TLSv1.2 client handshake failures such as "No available cipher suite for TLSv1.2" with SSL debug enabled.


Symptoms

The following error is shown when you try to install ssoadm (even though you have already configured the setup scripts with details of the truststore per FAQ: Installing and using ssoadm in AM/OpenAM (Q. How do I install the ssoadm administration tool if I am using SSL?)):

OpenDJ LDAP SDK Grizzly selector thread(1) SelectorRunner, WRITE: TLSv1.2 Handshake, length = 172
Connect Error: No operational connection factories available

SSL debugging - ssoadm

If you enable SSL debug logging for ssoadm and attempt to install ssoadm again, you will see an error similar to the following:

Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
.
.1320 Using SSLEngineImpl.
1321 Allow unsafe renegotiation: false
1322 Allow legacy hello messages: true
1323 Is initial handshake: true
1324 Is secure renegotiation: false
1325 No available cipher suite for TLSv1.2
1326 OpenDJ LDAP SDK Grizzly selector thread(1) SelectorRunner, fatal error: 40: Couldn't kickstart handshaking
1327 javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
1328 OpenDJ LDAP SDK Grizzly selector thread(1) SelectorRunner, SEND TLSv1.2 ALERT:  fatal, description = handshake_failure
1329 OpenDJ LDAP SDK Grizzly selector thread(1) SelectorRunner, WRITE: TLSv1.2 Alert, length = 2

You can enable SSL debug logging for ssoadm as described in How do I enable message level debugging for ssoadm in AM/OpenAM (All versions)? 

SSL debugging - DS/OpenDJ

If you enable SSL debug logging for DS/OpenDJ, you will 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/OpenDJ (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.

Recent Changes

Upgraded to JDK 1.8.0_192 or later, or JDK 11.

Restricted cipher suites in the configuration store DS/OpenDJ to more secure ones such as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, which use protocol version TLSv1.2.

Installed the configuration store DS using the --productionMode setup option (which restricts the available ciphers and forces the protocol version to TLSv1.2).

Causes

ssoadm does 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 ssoadm 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, ssoadm cannot communicate with the configuration store using a SSL/TLS secured connection because it uses different cipher suites and protocol to the DS/OpenDJ server; both the client and server must support the same cipher suites and protocol agreed upon when attempting to establish a secure connection.

Solution

This issue can be resolved by upgrading to AM 6.5.0.2 or AM 6.5.1, and then upgrading ssoadm to version 5.1.2.3; you can download this from BackStage.

Workaround

You can workaround this issue using one of the following options:

  • Downgrade to JDK 1.8.0_191 or earlier.
  • Use Amster (AM 5 and later) or REST instead of ssoadm.

See Also

Federation related pages do not display in the console with a java.lang.NoClassDefFoundError: sun/misc/CharacterEncoder error in AM 6.5.x

LDAP connection fails with No subject alternative DNS name matching error in AM 5.1.x, 6.x and DS 5.5.1, 5.5.2, 6.x

SSL handshake failed with no cipher suites in common in DS 5 after restricting cipher suites or upgrading Java

SSL in DS/OpenDJ

Administration Guide › TLS Protocols and Cipher Suites

Security Guide › Set Up Servers in Production Mode

Related Training

N/A

Related Issue Tracker IDs

OPENAM-14723 (Document limitations on ssoadm and Java )

OPENAM-14669 (ssoadm does not install using Java 1.8.192 and above)



Copyright and TrademarksCopyright © 2019 ForgeRock, all rights reserved.
Loading...