apache/hadoop · error · IOException
No such algorithm storing keystore ${this}
Error message
No such algorithm storing keystore ${this} What it means
KeyStore.store() computes an integrity MAC over the keystore (classically HmacSHA1 for JCEKS); NoSuchAlgorithmException means the JVM's configured security providers cannot supply that algorithm in the current environment. This is a JVM security-configuration problem, not a keystore-content problem.
Source
Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/JavaKeyStoreProvider.java:614
LOG.debug("Could not reset Keystore to previous state", e);
}
}
private void cleanupNewAndOld(Path newPath, Path oldPath) throws IOException {
// Rename _NEW to CURRENT
renameOrFail(newPath, path);
// Delete _OLD
fs.delete(oldPath, true);
}
protected void writeToNew(Path newPath) throws IOException {
try (FSDataOutputStream out =
FileSystem.create(fs, newPath, permissions);) {
keyStore.store(out, password);
} catch (KeyStoreException e) {
throw new IOException("Can't store keystore " + this, e);
} catch (NoSuchAlgorithmException e) {
throw new IOException(
"No such algorithm storing keystore " + this, e);
} catch (CertificateException e) {
throw new IOException(
"Certificate exception storing keystore " + this, e);
}
}
protected boolean backupToOld(Path oldPath)
throws IOException {
try {
renameOrFail(path, oldPath);
return true;
} catch (FileNotFoundException e) {
return false;
}
}
private void revertFromOld(Path oldPath, boolean fileExisted)View on GitHub (pinned to 2add963021)
Solutions
- Run with a full-strength standard provider set: restore the default java.security / include SunJCE
- Probe at startup: Mac.getInstance("HmacSHA1") and KeyStore.getInstance("jceks") to fail fast with a clear cause
- In restricted environments, switch to a KMS-backed provider instead of local JCEKS files
Defensive patterns
Strategy: try-catch
Validate before calling
// startup probe: fail fast with a clear message in restricted JVMs
try {
javax.crypto.Mac.getInstance("HmacSHA1");
java.security.KeyStore.getInstance("jceks");
} catch (java.security.NoSuchAlgorithmException | java.security.KeyStoreException e) {
throw new IllegalStateException("JCE providers incomplete: " + e.getMessage(), e);
} Try / catch
try { provider.flush(); } catch (IOException e) { if (e.getCause() instanceof java.security.NoSuchAlgorithmException) { // environment fault: fix JVM security providers or move to KMS provider; retrying unchanged will fail } throw e; } Prevention
- Validate JCE provider availability at deployment, not at first flush
- Pin a standard JDK with unmodified java.security for keystore hosts
- In FIPS environments prefer KMS-backed providers over local JCEKS
When it happens
Trigger: FIPS-restricted JVM where the MAC algorithm is unavailable or disabled; a custom java.security that removed SunJCE; an old or stripped JDK distribution missing the algorithm.
Common situations: Hardened FIPS environments; security-manager restricted runtimes; docker images built on minimal JDKs with pruned providers.
Related errors
- No such algorithm storing keystore " + this
- Problem removing ${versionName} from ${this}
- Problem removing ${name} from ${this}
- Can't store key ${versionName} in ${this}
- Can't set metadata key ${entry.getKey()}
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/4deaf852424c9dfb.
Report an issue: GitHub.