Hey, I’ve dealt with this exact scenario plenty of times when moving Java applications between Windows and CentOS. The core issue boils down to differences in how the two systems handle Java certificate stores, plus separate certificate configurations for tools like curl. Let’s break this down step by step:

Why CentOS isn’t recognizing your imported certificate #

• Wrong JDK certificate store target: Windows and CentOS often use different JDK installations (or even multiple JDKs on CentOS). If you imported the certificate into a cacerts file that your application isn’t actually using, the error will persist. CentOS’s default OpenJDK cacerts are typically located at /usr/lib/jvm/<your-jdk-version>/jre/lib/security/cacerts—double-check you’re targeting the right one.
• Incomplete/incorrect import command: It’s easy to miss specifying the full path to cacerts, or use the wrong keystore password (the default is changeit for most OpenJDK installations). A small typo here means the certificate never makes it into the right store.
• Curl uses a separate CA store: Curl doesn’t use Java’s cacerts—it relies on the system-wide CA bundle (usually /etc/pki/tls/certs/ca-bundle.crt on CentOS). So even if Java trusts the certificate, curl will still throw errors until you update the system CA trust.

Step-by-step fixes #

1. Confirm which JDK your application is using #

First, find out exactly which JDK your app is running with. Use this command to check Java processes:

ps aux | grep java

Look for the JDK path in the process arguments, or check your application’s startup script for the JAVA_HOME variable.

2. Import the certificate to the correct cacerts store #

Assuming your JDK path is /usr/lib/jvm/java-1.8.0-openjdk-amd64, run these commands (replace paths/names to match your setup):

# First, back up the original cacerts file to avoid mistakes
cp /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/security/cacerts /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/security/cacerts.bak

# Import your Base64 .cer certificate
keytool -importcert -file target-cert.cer -alias target-api-cert -keystore /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/security/cacerts -storepass changeit

When prompted "Trust this certificate?", type yes and press Enter.

3. Verify the certificate was imported successfully #

Run this command to confirm the certificate exists in the store:

keytool -list -keystore /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/security/cacerts -alias target-api-cert -storepass changeit

You should see details about the certificate if the import worked.

4. Fix curl’s certificate verification issue #

To get curl working, you have two options:

• Temporary workaround (not for production): Skip certificate verification with the -k flag:

  curl -k https://your-target-api-url.com
  

• Permanent fix (production-safe): Add the certificate to the system CA trust:

  # Copy the certificate to the system CA anchors directory
  cp target-cert.cer /etc/pki/ca-trust/source/anchors/
  
  # Update the system CA bundle
  update-ca-trust extract
  

Now curl should validate the certificate without errors.

Final checks #

• Restart your application: Java only loads the cacerts file on startup—you’ll need to restart your app for the changes to take effect.
• Check certificate validity: Ensure the certificate isn’t expired, and that its Common Name (CN) or Subject Alternative Name (SAN) matches the target API’s domain. A mismatch will still cause SSL errors even after import.
• Containerized apps?: If your app runs in Docker, you need to import the certificate into the container’s JDK cacerts, not the host system’s.

内容的提问来源于stack exchange，提问作者Indu Chabada