apache/hadoop · error · IOException

No such algorithm storing keystore " + this

Error message

No such algorithm storing keystore " + this

What it means

During flush(), KeyStore.store() threw NoSuchAlgorithmException: the JVM cannot supply the integrity/protection algorithm the JCEKS writer needs to serialize the store (e.g. the HMAC used for entry protection). The keystore content is fine; the runtime's crypto registry is missing a piece.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/alias/AbstractJavaKeyStoreProvider.java:297

    changed = true;
    return new CredentialEntry(alias, material);
  }

  @Override
  public void flush() throws IOException {
    writeLock.lock();
    try {
      if (!changed) {
        LOG.debug("Keystore hasn't changed, returning.");
        return;
      }
      LOG.debug("Writing out keystore.");
      try (OutputStream out = getOutputStreamForKeystore()) {
        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);
      }
      changed = false;
    } finally {
      writeLock.unlock();
    }
  }

  /**
   * Open up and initialize the keyStore.
   *
   * @throws IOException If there is a problem reading the password file
   * or a problem reading the keystore.
   */
  private void locateKeystore() throws IOException {
    try {

View on GitHub (pinned to 2add963021)

Solutions

1. Run the provider on a standard full JDK (OpenJDK/Oracle 8+) where SunJCE supplies JCEKS algorithms
2. Inspect java.security: ensure security.provider.N=... entries include the provider that wrote the store; add it if missing
3. For FIPS setups, register BouncyCastle (or equivalent) in java.security and verify JCEKS support before flushing
4. As a last resort, recreate the store on the target JVM so it serializes with that JVM's available algorithms

// Pre-flight: JCE provider registry must include SunJCE for JCEKS serialization
static boolean jceksWritable() {
  return java.util.Arrays.stream(java.security.Security.getProviders())
      .anyMatch(p -> p.getName().equals("SunJCE"));
}

try {
  provider.flush();
} catch (IOException ex) {
  if (ex.getCause() instanceof java.security.NoSuchAlgorithmException) {
    // JVM missing the store integrity algorithm; switch JVM/provider config, do not retry blindly
  } else { throw ex; }
}

When it happens

Trigger: Running on a stripped-down or FIPS-mode JVM whose security.provider list omits SunJCE; JVMs where required algorithms are disabled via jdk.security.legacyAlgorithms or crypto policy; exotic Java builds (embedded JRE).

Common situations: Hadoop daemon moved to a hardened/FIPS JVM (e.g. NSS-based) without adding a compatible provider; container images with minimal Java; Java version downgrades between store write and flush.

Related errors

• No such algorithm storing keystore ${this}
• Can't store keystore " + this
• Certificate exception storing keystore {}
• Can't create keystore
• Can't set metadata key ${entry.getKey()}

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