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

  1. Run with a full-strength standard provider set: restore the default java.security / include SunJCE
  2. Probe at startup: Mac.getInstance("HmacSHA1") and KeyStore.getInstance("jceks") to fail fast with a clear cause
  3. 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

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


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/4deaf852424c9dfb. Report an issue: GitHub.