t8y2/dbx · critical · IllegalStateException
SHA-256 is unavailable
Error message
SHA-256 is unavailable
What it means
JdbcConnectionPoolRegistry.digest() keys each pool by a SHA-256 hash of the identity string. MessageDigest.getInstance("SHA-256") throwing means the JRE cannot supply that algorithm, so digest() wraps the failure in IllegalStateException("SHA-256 is unavailable"). This is an environment/JRE problem, not a data problem.
Source
Thrown at agents/common/src/main/java/com/dbx/agent/JdbcConnectionPoolRegistry.java:224
pools.clear();
checkoutExecutor.close();
connectionReleaseExecutor.close();
poolCloseExecutor.close();
physicalConnectionOpener.close();
physicalConnectionCloser.close();
}
private static String digest(String identity) {
try {
byte[] hash = MessageDigest.getInstance("SHA-256").digest(identity.getBytes(StandardCharsets.UTF_8));
StringBuilder result = new StringBuilder(hash.length * 2);
for (byte value : hash) {
result.append(Character.forDigit((value >>> 4) & 0x0f, 16));
result.append(Character.forDigit(value & 0x0f, 16));
}
return result.toString();
} catch (Exception error) {
throw new IllegalStateException("SHA-256 is unavailable", error);
}
}
private static ThreadFactory daemonThreadFactory(String name) {
return runnable -> {
Thread thread = new Thread(runnable, name);
thread.setDaemon(true);
return thread;
};
}
private static ExecutorService boundedExecutor(int maximumThreads, String name) {
int threads = Math.max(1, maximumThreads);
return new ThreadPoolExecutor(
threads,
threads,
0L,
TimeUnit.MILLISECONDS,View on GitHub (pinned to c0390bff16)
Solutions
- Run on a standard JRE/JDK (11+) that includes the SUN provider with SHA-256; verify with MessageDigest.getInstance("SHA-256") in a smoke test.
- Inspect java.security (jdk.home/conf/security) and re-enable the SUN provider / remove jdk.certpath/jdk.tls disabledAlgorithms entries that block SHA-256.
- If a FIPS provider is required, register a provider that supplies SHA-256 (e.g. BouncyCastle FIPS) via security.provider config.
- As a stopgap, precompute/replace the digest with an application-supplied key derivation so borrow() never invokes MessageDigest.
Example fix
// before (java.security) #security.provider.1=sun.security.provider.Sun // after security.provider.1=sun.security.provider.Sun
Defensive patterns
Strategy: validation
Validate before calling
try {
java.security.MessageDigest.getInstance("SHA-256");
} catch (java.security.NoSuchAlgorithmException e) {
throw new IllegalStateException("Runtime JRE lacks SHA-256; fix providers before starting", e);
} Type guard
static boolean sha256Available() {
try {
return java.security.MessageDigest.getInstance("SHA-256") != null;
} catch (java.security.NoSuchAlgorithmException e) {
return false;
}
} Try / catch
try {
return registry.borrow(identity, factory);
} catch (IllegalStateException e) {
if (e.getMessage().contains("SHA-256 is unavailable")) {
throw new FatalStartupError("JRE lacks SHA-256; check security providers", e);
}
throw e;
} Prevention
- Startup smoke test: resolve SHA-256 MessageDigest before accepting traffic.
- Avoid jlink/trimmed runtimes that drop the SUN crypto provider.
- Review java.security and disabledAlgorithms after hardening or FIPS changes.
- Pin a standard JDK distribution (Temurin, etc.) in deployment images.
When it happens
Trigger: Any borrow()/poolCount()/hasActiveLeases() call when MessageDigest.getInstance("SHA-256") fails — running on a stripped-down JRE without the SUN/MD provider, a misconfigured java.security file removing the provider, or a classloading/registry failure of the security provider.
Common situations: Deploying to a minimal/jlink-trimmed runtime or hardened container with removed crypto providers; a corrupted or overly restrictive java.security policy disabling SHA-2 family algorithms (e.g. legacy FIPS setups); broken JDK installation.
Related errors
AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05).
Data as JSON: /api/errors/7a72a414fb4f874d.
Report an issue: GitHub.