Cannot install or use ssoadm in AM 6.0.x, 6.5.0 and 6.5.0.1 after restricting configuration store (DS) cipher suites or Java upgrade

Last updated Jan 12, 2023

The purpose of this article is to provide assistance if you cannot install or use ssoadm after restricting cipher suites in the AM configuration store (DS), 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 (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 (All versions)?

SSL debugging - DS

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

Recent Changes

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

Restricted cipher suites in the configuration store DS 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 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 later, and then upgrading ssoadm to version 5.1.2.3; you can download this from Backstage.

Workaround

You can work around this issue using one of the following options:

Downgrade to JDK 1.8.0_191 or earlier.
Use Amster or REST instead of ssoadm.

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)