apache/hadoop · error · IOException

Can't get algorithm for credential " + alias + " from " + ge

Error message

Can't get algorithm for credential " + alias + " from " + getPathAsString()

What it means

Thrown by AbstractJavaKeyStoreProvider.getCredentialEntry when KeyStore.getKey() fails with NoSuchAlgorithmException: the alias exists in the JCEKS store, but the current JVM's security providers cannot supply the algorithm needed to unwrap/recover the stored SecretKeySpec. It means the keystore entry was written under a JCE configuration the reading JVM does not have. The offending cause is chained on the IOException.

Source

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

    }
  }

  @Override
  public CredentialEntry getCredentialEntry(String alias)
      throws IOException {
    readLock.lock();
    try {
      SecretKeySpec key = null;
      try {
        if (!keyStore.containsAlias(alias)) {
          return null;
        }
        key = (SecretKeySpec) keyStore.getKey(alias, password);
      } catch (KeyStoreException e) {
        throw new IOException("Can't get credential " + alias + " from "
            + getPathAsString(), e);
      } catch (NoSuchAlgorithmException e) {
        throw new IOException("Can't get algorithm for credential " + alias
            + " from " + getPathAsString(), e);
      } catch (UnrecoverableKeyException e) {
        throw new IOException("Can't recover credential " + alias + " from "
            + getPathAsString(), e);
      }
      return new CredentialEntry(alias, bytesToChars(key.getEncoded()));
    } finally {
      readLock.unlock();
    }
  }

  public static char[] bytesToChars(byte[] bytes) throws IOException {
    String pass;
    pass = new String(bytes, StandardCharsets.UTF_8);
    return pass.toCharArray();
  }

  @Override

View on GitHub (pinned to 2add963021)

Solutions

Read the store with the same JVM family/version (and the same security providers) that created it
Check the installed providers (java.security + Security.getProviders()); add the missing provider jar to the classpath or java.security file
On Java < 8u161 install the unlimited JCE policy files, or upgrade to 8u161+ where they are default
Recreate the keystore with Hadoop's own tooling (hadoop credential create -provider jceks://...) so entries use the standard AES SecretKeySpec, and re-add all secrets

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: confirm the JCE registry can supply AES before reading entries
import javax.crypto.Cipher;
import java.security.Security;

boolean jceOk(String algorithm) {
  try {
    Cipher.getMaxAllowedKeyLength(algorithm); // touches JCE policy
    return Security.getProviders().length > 0; // and check SunJCE presence if needed
  } catch (Exception e) {
    return false;
  }
}

Try / catch

try {
  CredentialEntry e = provider.getCredentialEntry(alias);
} catch (IOException ex) {
  if (ex.getCause() instanceof java.security.NoSuchAlgorithmException) {
    // JVM/provider mismatch with the keystore writer - do not retry here;
    // fix the JVM provider set or re-create the store on this JVM
  } else { throw ex; }
}

Prevention

Create and read credential stores with the same JDK vendor and version across the cluster
Keep custom JCE providers on the classpath of every process that opens the store, not just the writer
Standardize on Hadoop tooling (hadoop credential) to create stores so entries always use default AES

When it happens

Trigger: Calling getCredentialEntry(alias) (directly or via hadoop credential list/-get flows that read entries) on a JCEKS file that was created by a different JVM/JCE provider set; JVMs missing SunJCE or a custom provider that was present at write time; older Java 7/8 builds with restricted JCE policy; FIPS-hardened JVMs that disable the needed algorithm.

Common situations: Keystore created on OpenJDK 11 but read on an old JRE 7 client; IBM J9 to OpenJDK migration; a BouncyCastle-based tool wrote the entry and BC is not on the Hadoop classpath at read time; JDK downgrades in the cluster.

Related errors

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