What causes "Can't load keystore {}" in apache/hadoop?

Check the file: size > 0 and readable, then keytool -list -keystore -storetype jceks

apache/hadoop · error · IOException

Can't load keystore {}

Error message

Can't load keystore {}

What it means

Thrown in locateKeystore() when ks.load() raises a GeneralSecurityException while reading the store file: a CertificateException (file bytes are not a valid keystore encoding - corrupt/truncated/not a keystore) or NoSuchAlgorithmException (integrity-check algorithm unavailable). Note: a WRONG PASSWORD during load surfaces as a raw 'Keystore was tampered with, or password was incorrect' IOException from the JDK, not as this message.

Source

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

        password = CREDENTIAL_PASSWORD_DEFAULT.toCharArray();
      }
      KeyStore ks;
      ks = KeyStore.getInstance(getKeyStoreType());
      if (keystoreExists()) {
        stashOriginalFilePermissions();
        try (InputStream in = getInputStreamForFile()) {
          ks.load(in, password);
        }
      } else {
        createPermissions("600");
        // required to create an empty keystore. *sigh*
        ks.load(null, password);
      }
      keyStore = ks;
    } catch (KeyStoreException e) {
      throw new IOException("Can't create keystore", e);
    } catch (GeneralSecurityException e) {
      throw new IOException("Can't load keystore " + getPathAsString(), e);
    }
  }

  @Override
  public boolean needsPassword() throws IOException {
    return (null == ProviderUtils.locatePassword(CREDENTIAL_PASSWORD_ENV_VAR,
        conf.get(CREDENTIAL_PASSWORD_FILE_KEY)));

  }

  @Override
  public String noPasswordWarning() {
    return ProviderUtils.noPasswordWarning(CREDENTIAL_PASSWORD_ENV_VAR,
            CREDENTIAL_PASSWORD_FILE_KEY);
  }

  @Override
  public String noPasswordError() {

View on GitHub (pinned to 2add963021)

Solutions

Check the file: size > 0 and readable, then keytool -list -keystore <file> -storetype jceks
Restore from backup or recreate the store at a fresh path and re-add credentials
If keytool loads it fine, align the JVM/provider set between the tool that validates and the Hadoop process (algorithm availability)

Defensive patterns

Strategy: validation

Validate before calling

// Pre-flight: prove the file loads as JCEKS with the intended password
static void assertLoadableJceks(java.nio.file.Path file, char[] pw) throws Exception {
  KeyStore ks = KeyStore.getInstance("jceks");
  try (InputStream in = Files.newInputStream(file)) {
    ks.load(in, pw);   // wrong password -> 'Keystore was tampered' IOException
  }                 // garbage bytes  -> CertificateException
}

Try / catch

try {
  CredentialProviderFactory.getProviders(conf);
} catch (IOException ex) {
  if (ex.getMessage() != null && ex.getMessage().contains("Can't load keystore")) {
    // file corrupt or algorithm unavailable: restore backup / align JVM; not retryable as-is
  } else { throw ex; }
}

Prevention

Keep backups of every .jceks file (they are small) - corruption has no repair path
Use atomic moves when provisioning store files; never write them in place from scripts
Pin the same Java major version on store writers and readers

When it happens

Trigger: Opening a jceks:// or localjceks:// provider whose file is truncated (crashed writer), binary garbage, or a non-keystore file that happens to sit at the path; JVM missing the algorithm used for the store's integrity check.

Common situations: Keystore file half-written after a node crash or full disk; someone edited/sed'd the binary file; a symlink points at a placeholder file; store created on newer Java then read on an old JVM.

Related errors

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