conductor-oss/conductor · error · IllegalArgumentException

Invalid sslProtocol

Error message

Invalid sslProtocol 

What it means

Thrown as IllegalArgumentException when the AMQP ConnectionFactory cannot initialize SSL/TLS via factory.useSslProtocol(). The underlying cause is a NoSuchAlgorithmException (the JVM has no security provider offering the requested TLS algorithm) or a KeyManagementException (key/trust store misconfiguration). The message itself is unhelpfully empty because the real detail lives on the chained exception 'e'. This fires at connection-factory build time, so it blocks every subsequent queue operation.

Source

Thrown at amqp/src/main/java/com/netflix/conductor/contribs/queue/amqp/AMQPObservableQueue.java:508

                factory.setVirtualHost(virtualHost);
            }
            // Get server port from config
            final int port = properties.getPort();
            if (port <= 0) {
                throw new IllegalArgumentException("Port must be greater than 0");
            } else {
                factory.setPort(port);
            }
            final boolean useNio = properties.isUseNio();
            if (useNio) {
                factory.useNio();
            }
            final boolean useSslProtocol = properties.isUseSslProtocol();
            if (useSslProtocol) {
                try {
                    factory.useSslProtocol();
                } catch (NoSuchAlgorithmException | KeyManagementException e) {
                    throw new IllegalArgumentException("Invalid sslProtocol ", e);
                }
            }
            factory.setConnectionTimeout(properties.getConnectionTimeoutInMilliSecs());
            factory.setRequestedHeartbeat(properties.getRequestHeartbeatTimeoutInSecs());
            factory.setNetworkRecoveryInterval(properties.getNetworkRecoveryIntervalInMilliSecs());
            factory.setHandshakeTimeout(properties.getHandshakeTimeoutInMilliSecs());
            factory.setAutomaticRecoveryEnabled(true);
            factory.setTopologyRecoveryEnabled(true);
            factory.setRequestedChannelMax(properties.getMaxChannelCount());
            return factory;
        }

        public AMQPObservableQueue build(
                final boolean useExchange, final String queueURI, final String queueType) {
            final AMQPSettings settings = new AMQPSettings(properties, queueType).fromURI(queueURI);
            final AMQPRetryPattern retrySettings =
                    new AMQPRetryPattern(
                            properties.getLimit(), properties.getDuration(), properties.getType());

View on GitHub (pinned to cf7c3e4a8a)

Solutions

  1. Inspect the chained exception: e is the real cause — read its message (NoSuchAlgorithmException names the missing algorithm, KeyManagementException points at the keystore).
  2. If a specific protocol is required, set the broker/JVM to a supported one (TLSv1.2/TLSv1.3) and ensure jdk.tls.disabledAlgorithms in java.security does not exclude it.
  3. For trust-store problems, provide -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword pointing to a readable store containing the broker CA.
  4. If SSL is not actually required, set conductor.workflow.event-queues.amqp.useSslProtocol=false.
  5. On a FIPS/hardened runtime, install a provider (e.g. BouncyCastle FIPS) that offers the algorithm, or switch to a non-FIPS image for the conductor server.

Example fix

// before
final boolean useSslProtocol = properties.isUseSslProtocol();
if (useSslProtocol) {
    try {
        factory.useSslProtocol();
    } catch (NoSuchAlgorithmException | KeyManagementException e) {
        throw new IllegalArgumentException("Invalid sslProtocol ", e);
    }
}
// after — pin a JDK-supported protocol and surface the real cause
if (useSslProtocol) {
    try {
        factory.useSslProtocol("TLSv1.2"); // or read from properties
    } catch (NoSuchAlgorithmException | KeyManagementException e) {
        throw new IllegalArgumentException(
            "Invalid sslProtocol (algorithm/keystore error): " + e.getMessage(), e);
    }
}
Defensive patterns

Strategy: validation

Validate before calling

// Before enabling SSL, confirm the JVM supports the protocol
import javax.net.ssl.SSLContext;
String proto = "TLSv1.2"; // or read from properties
try {
    SSLContext.getInstance(proto); // throws NoSuchAlgorithmException if unsupported
} catch (java.security.NoSuchAlgorithmException e) {
    throw new IllegalStateException("JVM does not support " + proto + "; cannot enable AMQP SSL", e);
}
// Also verify the trust store path is readable if set
String ts = System.getProperty("javax.net.ssl.trustStore");
if (ts != null && !java.nio.file.Files.isReadable(java.nio.file.Paths.get(ts))) {
    throw new IllegalStateException("Trust store not readable: " + ts);
}

Try / catch

try {
    factory.useSslProtocol("TLSv1.2");
} catch (NoSuchAlgorithmException | KeyManagementException e) {
    // Fail fast with the real cause; this is a startup/config error, not retriable
    throw new IllegalStateException("AMQP SSL init failed: " + e.getMessage(), e);
}

Prevention

When it happens

Trigger: conductor.workflow.event-queues.amqp.useSslProtocol=true (or the AMQPObservableQueue.Builder enabling SSL) on a JVM whose security providers do not expose the default algorithm. Also triggered when the JVM's jdk.tls.disabledAlgorithms or a FIPS/java.security policy strips TLSv1.0/TLSv1.1, or when the trust store referenced by javax.net.ssl.trustStore is missing/unreadable.

Common situations: Upgrading the runtime to JDK 17/21 where legacy TLS versions are disabled by default; running in a hardened/FIPS container that only allows TLSv1.2/1.3; pointing at a broker expecting an algorithm the JRE does not ship; misconfigured or absent -Djavax.net.ssl.trustStore in the conductor server JVM.

Related errors


AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14). Data as JSON: /api/errors/305fd043447a82c6. Report an issue: GitHub.