What causes "Could not load truststore (keep using existing one) : " in apache/hadoop?

Write the new truststore to a temp file in the same directory, verify it, then atomically rename over the old one

apache/hadoop · warning · RuntimeException

Could not load truststore (keep using existing one) :

Error message

Could not load truststore (keep using existing one) :

What it means

ReloadingX509TrustManager.loadFrom wraps any failure of loadTrustManager (IO or security exception while opening/loading the truststore file) in a RuntimeException with the message 'Could not load truststore (keep using existing one) : ' — the previous trust manager stays active. The file-monitor timer in FileBasedKeyStoresFactory catches and logs this (LOG.error) instead of propagating, so most users see it as a log line during certificate reload.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/ssl/ReloadingX509TrustManager.java:120

  }

  private static final X509Certificate[] EMPTY = new X509Certificate[0];
  @Override
  public X509Certificate[] getAcceptedIssuers() {
    X509Certificate[] issuers = EMPTY;
    X509TrustManager tm = trustManagerRef.get();
    if (tm != null) {
      issuers = tm.getAcceptedIssuers();
    }
    return issuers;
  }

  public ReloadingX509TrustManager loadFrom(Path path) {
    try {
      this.trustManagerRef.set(loadTrustManager(path));
    } catch (Exception ex) {
      // The Consumer.accept interface forces us to convert to unchecked
      throw new RuntimeException(RELOAD_ERROR_MESSAGE, ex);
    }
    return this;
  }

  X509TrustManager loadTrustManager(Path path)
  throws IOException, GeneralSecurityException {
    X509TrustManager trustManager = null;
    KeyStore ks = KeyStore.getInstance(type);
    InputStream in = Files.newInputStream(path);
    try {
      ks.load(in, (password == null) ? null : password.toCharArray());
      LOG.debug("Loaded truststore '" + path + "'");
    } finally {
      in.close();
    }

    TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(
        SSLFactory.TRUST_MANAGER_SSLCERTIFICATE);

View on GitHub (pinned to 2add963021)

Solutions

Write the new truststore to a temp file in the same directory, verify it, then atomically rename over the old one
Confirm the new file's password and type match the configured ssl.<mode>.truststore.password/.type
Check file ownership/permissions for the monitoring service user
If you call loadFrom directly, catch RuntimeException, inspect getCause(), and keep serving on the old truststore until the file is fixed

Example fix

# before: rotation script writes in place
cp new-truststore.jks /etc/security/tls/truststore.jks  # torn read possible

# after: atomic replace
cp new-truststore.jks /etc/security/tls/.truststore.jks.tmp
keytool -list -keystore /etc/security/tls/.truststore.jks.tmp -storepass "$PW" >/dev/null
mv /etc/security/tls/.truststore.jks.tmp /etc/security/tls/truststore.jks

Defensive patterns

Strategy: fallback

Validate before calling

// if you invoke reload yourself, validate the file first
KeyStore probe = KeyStore.getInstance(type);
try (InputStream in = Files.newInputStream(path)) {
  probe.load(in, password.toCharArray());
} catch (Exception e) {
  LOG.warn("Refusing to reload from unparseable truststore {}: {}", path, e.getMessage());
  return; // keep current trust manager
}
trustManager.loadFrom(path);

Try / catch

try {
  trustManager.loadFrom(newPath);
} catch (RuntimeException e) {
  // previous truststore remains active; inspect cause and alert
  LOG.error("Truststore reload failed, continuing with existing truststore", e.getCause());
}

Prevention

Deploy truststores atomically (write temp + rename) so reloads never read partial files
Keep truststore password stable across rotations or update configuration in the same change
Monitor for the 'Could not load truststore' log line and page on it during rotation windows

When it happens

Trigger: The truststore file on disk changed and the reload timer (interval from ssl.<mode>.stores.reload.interval, default 10s) tried to reload it while it was corrupt, truncated mid-copy, unreadable, or the password no longer matched.

Common situations: Certificate rotation scripts writing the new truststore in place (torn read); file replaced with a keystore generated under a different password; chmod/chown during deployment making the file unreadable for the monitor; NFS latency exposing partial files.

Related errors

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