PKIX path building failed after truststore update in Quarkus

Resolution

A running Quarkus application cannot recognize newly added CA certificates in the truststore without a restart. There is no supported Quarkus API or configuration property to programmatically reload the JVM's default SSLContext or truststore at runtime.

Likely Explanation

The PKIX path building failed error occurs because the Java Virtual Machine (JVM) loads the truststore into memory during the initialization of the SSLContext. Once the TrustManagerFactory is initialized, it does not monitor the underlying file for changes. Because Quarkus relies on the standard JVM networking stack for its REST clients and server configurations, any updates to the cacerts file or a custom truststore specified via javax.net.ssl.trustStore remain invisible to the active process.

Verification and Recovery Steps

To resolve the failure and verify the truststore state, follow these steps:

1. Verify Certificate Presence: Ensure the certificate was correctly imported into the store using the JDK keytool:

   keytool -list -v -keystore /path/to/truststore -alias your_cert_alias

2. Check Active Store Path: If you are unsure which truststore the JVM is using, restart the application with the following debug flag to see the loaded store in the logs:

   -Djavax.net.debug=ssl,handshake

3. Perform a Full Restart: Restart the Quarkus application process. This is the only reliable way to force the JVM to re‑initialize the SSLContext and load the updated certificates.

JVM vs. Native Mode

• JVM Mode: The behavior is governed by the JSSE (Java Secure Socket Extension). Reloading requires a process restart or a complex manual replacement of the SSLContext in all active HTTP clients.
• Native Mode: In GraalVM native images, the truststore behavior depends on whether you are using the bundled cacerts or the system truststore. If certificates are baked into the image at build time, a full rebuild and redeploy are required. If the native image is configured to use the system truststore, a restart of the binary is still required to refresh the memory state.

Diagnostic Detail Needed: Are you using a custom SSLContext bean or the default Quarkus REST Client configuration? If you have implemented a custom SSLContext, a programmatic refresh may be possible by rotating the bean, but this is not the default Quarkus behavior.