What causes "Certificate exception storing keystore {}" in apache/hadoop?

Inspect the mixed content: keytool -list -v -keystore -storetype jceks

apache/hadoop · error · IOException

Certificate exception storing keystore {}

Error message

Certificate exception storing keystore {}

What it means

flush() got a CertificateException from KeyStore.store(): an entry in the store carries certificate material that cannot be encoded when persisting. Pure Hadoop credential entries are SecretKeySpecs and never hit this, so it means the keystore also holds certificate entries (added by keytool or another tool) that this JVM/provider cannot encode.

Source

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

  }

  @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 {
      password = ProviderUtils.locatePassword(CREDENTIAL_PASSWORD_ENV_VAR,
          conf.get(CREDENTIAL_PASSWORD_FILE_KEY));

View on GitHub (pinned to 2add963021)

Solutions

Inspect the mixed content: keytool -list -v -keystore <file> -storetype jceks
Split concerns: keep certificates in their own store; recreate a clean credentials-only JCEKS via hadoop credential
Encode/flush on the newest JVM that wrote the certificates, or upgrade the reading JVM to match

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: confirm the store holds only secret-key entries before flush
class Probe {
  static boolean onlySecretEntries(KeyStore ks) throws KeyStoreException {
    java.util.Enumeration<String> e = ks.aliases();
    while (e.hasMoreElements()) {
      if (ks.isCertificateEntry(e.nextElement())) return false;
    }
    return true;
  }
}

Try / catch

try {
  provider.flush();
} catch (IOException ex) {
  if (ex.getCause() instanceof java.security.cert.CertificateException) {
    // mixed-in certificates cannot be encoded by this JVM;
    // split certs into a separate store and keep this one secrets-only
  } else { throw ex; }
}

Prevention

Dedicate one keystore to Hadoop credentials; never import certificates into it
When both must live on a host, use separate files and separate provider paths

When it happens

Trigger: A .jceks file shared with keytool certificate operations; certificates written by a different JDK/provider version whose encoding the current one rejects; corrupted certificate entry in the store.

Common situations: Reusing one keystore file for both TLS certs and Hadoop credentials; certificate renewed with a newer keytool and encoded with parameters the old reader's JVM cannot handle.

Understand the failure class

SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

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