Qodana Docker Scanner: Custom CA Trust Store Reload Limitation

Short answer

No. Qodana does not offer a flag, environment variable, or API that reloads the Java trust store while the scanner is running, and a shared volume cannot trigger a refresh on its own. This is a JVM limitation that Qodana inherits, not a Qodana-specific restriction. The practical options are: restart the container (cheapest), wrap the entrypoint with a file watcher that restarts the scanner process on certificate change, or bake rotation into your image build pipeline.

Why this happens (confirmed JVM behavior)

The JVM reads the trust store once during initialization of the default SSLContext and caches the trusted certificates in memory. Later changes to the cacerts file on disk are invisible to the running process. Setting -Djavax.net.ssl.trustStore=/path/to/custom.jks only changes which file is read at startup — it does not add any reload mechanism. Because Qodana's linters run on a JVM, the same rule applies: a mounted certificate updated via a Docker volume will be picked up only after the process restarts.

One nuance worth knowing: a custom SSLContext built in application code can be rebuilt at runtime, but that requires the application (Qodana itself) to implement the reload. There is no supported way to inject that behavior from outside.

What you can actually do

Option 1: Point the JVM at a mounted trust store, restart on rotation

Keep a single cacerts file on the host, import your private CA into it once, and mount it read-only:

docker run --rm \
  -v /srv/pki/cacerts:/opt/java/openjdk/lib/security/cacerts:ro \
  -v $PWD:/data/project \
  jetbrains/qodana-jvm:latest

When the CA rotates, update the file on the host and recreate the container. This removes the image rebuild but not the restart.

Option 2: Watcher-driven restart inside a wrapper

If scans are long-running or triggered frequently, wrap the Qodana entrypoint in a small script that watches the certificate directory (e.g., with inotifywait) and kills the scanner process when the file changes, letting your orchestrator (Docker restart policy, Kubernetes, CI job retry) start a fresh container. This gives you "automatic reload" in the only form the JVM supports: fast, automated restart.

Option 3: Terminate TLS before Qodana

Put an internal proxy (e.g., a corporate MITM proxy or a reverse proxy in front of your Maven/NPM mirror) in the trust chain and keep that proxy's certificate stable, rotating the upstream certificates at the proxy instead. The scanner's trust store then never changes.

About the DNS point

Correct — --dns and /etc/resolv.conf are unrelated to this issue. Name resolution happens per connection in the OS resolver, while trust decisions are made by the JVM's cached SSLContext.

Verification

1. Inside the container, confirm the JVM and trust store path: java -version and check $JAVA_HOME/lib/security/cacerts.
2. Start a scan against an internal HTTPS repo, update the CA on the host volume, and re-run — expect an SSLHandshakeException (e.g., PKIX path building failed).
3. Restart the container and confirm the same scan succeeds. If it does not, the problem is the certificate chain itself, not the reload limitation.

Review note: Qodana evolves quickly; check the current release notes for your version in case a trust-store-related option has been added since this was written.