apache/cassandra · error · IllegalStateException
No ciphers left after filtering supported cipher suite
Error message
No ciphers left after filtering supported cipher suite
What it means
SSLFactory.filterCipherSuites() takes the configured cipher suite list, filters it down to ciphers supported by the installed JDK/JCE provider, and throws IllegalStateException if filtering removes every cipher. This fail-fast guards against starting TLS with an empty cipher list, which would make every handshake fail anyway.
Source
Thrown at src/java/org/apache/cassandra/security/SSLFactory.java:348
{
break;
}
if (supportedCiphers.contains(c))
{
newCiphers.add(c);
}
else
{
if (settingDescription != null)
{
logger.warn("Dropping unsupported cipher_suite {} from {} configuration",
c, toLowerCaseLocalized(settingDescription));
}
}
}
if (newCiphers.isEmpty())
{
throw new IllegalStateException("No ciphers left after filtering supported cipher suite");
}
return newCiphers.toArray(new String[0]);
}
}
private static boolean filterOutSSLv2Hello(String string)
{
return !string.equals("SSLv2Hello");
}
public static void validateSslContext(String contextDescription, EncryptionOptions options, EncryptionOptions.ClientEncryptionOptions.ClientAuth clientAuth, boolean logProtocolAndCiphers) throws IOException
{
if (options != null && options.tlsEncryptionPolicy() != EncryptionOptions.TlsEncryptionPolicy.UNENCRYPTED)
{
try
{
CipherSuiteFilter loggingCipherSuiteFilter = logProtocolAndCiphers ? new LoggingCipherSuiteFilter(contextDescription)View on GitHub (pinned to 88fd0f6a0e)
Solutions
- List the ciphers actually supported by your JVM (e.g. via 'jdk.tls.disabledAlgorithms' awareness or SSLContext supported cipher suites) and set cipher_suites in cassandra.yaml to a non-empty intersection.
- Remove obsolete cipher names or correct their spelling/case in cipher_suites.
- Check $JAVA_HOME/jre/lib/security/java.security 'jdk.tls.disabledAlgorithms' — re-enable needed ciphers or pick different ones.
- If a provider (e.g. BouncyCastle/FIPS) is expected to supply the ciphers, verify it is installed and registered.
Example fix
# before (cassandra.yaml) server_encryption_options: cipher_suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384-TYPO] # after server_encryption_options: cipher_suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
Defensive patterns
Strategy: validation
Validate before calling
// Java: verify at least one configured cipher is supported before applying config
String[] supported = SSLContext.getDefault().getSupportedSSLParameters().getCipherSuites();
Set<String> supportedSet = new HashSet<>();
for (String c : supported) supportedSet.add(c.toLowerCase(Locale.ROOT));
List<String> configured = encryptionOptions.cipher_suites; // from cassandra.yaml
if (configured == null || configured.isEmpty() ||
configured.stream().noneMatch(c -> supportedSet.contains(c.toLowerCase(Locale.ROOT)))) {
throw new IllegalArgumentException("No configured cipher suites are supported by this JVM");
} Prevention
- Cross-check cipher_suites in cassandra.yaml against the JVM's supported cipher list after every JDK upgrade
- Avoid copying OpenSSL cipher names into Cassandra config
- Keep a known-good default (omit cipher_suites) unless you need to restrict them
- Review jdk.tls.disabledAlgorithms when changing cipher configuration
When it happens
Trigger: cassandra.yaml (or EncryptionOptions) configures cipher_suites whose entries are all unsupported by the current JVM (e.g. only non-JDK ciphers, or typos/case mismatches after lowercasing), so the filtered set is empty.
Common situations: Migrating to a JDK (e.g. FIPS or newer/older JDK) that dropped or renamed cipher suites; copying cipher lists from OpenSSL-based tools into Cassandra config; typos in cipher names in cassandra.yaml.
Understand the failure class
Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.
Related errors
- Error creating/initializing the SSL Context
- PEM based truststore should not be using password. Ignoring
- Dropping unsupported cipher_suite {} from {} configuration
- Configured node identity is not matching identity extractedf
- No identity was extracted from the outbound keystore '%s'
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/41ad975a5a36c8b9.
Report an issue: GitHub.