SonarQube Quality Gate behavior with self‑signed certificates in plugin downloads

Question

Goal
Determine how SonarQube handles self‑signed or expired SSL certificates when downloading plugins and how that affects future plugin updates, while still evaluating Quality Gates.
Constraints
SonarQube relies on the JVM’s SSLContext for certificate validation. No documented configuration exists to bypass SSL checks for plugin URLs; users must import certificates into the JVM truststore. The impact of this manual step on subsequent plugin downloads and Quality Gate evaluation remains unclear.
Unresolved Decision
It is not documented whether SonarQube automatically retries plugin downloads after a truststore update, or whether the truststore change persists across analysis runs and affects future updates.
Specific Questions

After adding a self‑signed certificate to the JVM truststore, does SonarQube automatically retry a failed plugin download on the next analysis without manual intervention?
Does this truststore modification affect the validation of SSL certificates for all future plugin updates, or is it limited to the current analysis?
Is there a SonarQube configuration option (currently undocumented) that can instruct the server to ignore SSL validation errors for plugin URLs?

Tasadduq Burney · Answer

Direct Answers
1. Auto-retry after truststore update? No. SonarQube does not automatically retry a failed plugin download on the next analysis run. The server must be restarted (or the plugin manually triggered for update/install via the Marketplace UI) for the JVM to reload the updated truststore and attempt the download again.
2. Persistence across future updates? Yes. Adding a certificate to the JVM truststore (cacerts) is a file-system change that persists across all SonarQube restarts and analysis runs. It affects SSL validation for all future outbound HTTPS requests from that JVM instance, including every subsequent plugin download or update.
3. Undocumented config to ignore SSL errors? No. There is no SonarQube configuration property (documented or otherwise) that instructs the server to bypass SSL certificate validation for plugin URLs. The JVM's strict SSLContext must be satisfied.

Confirmed Behavior

Plugin downloads are performed by the SonarQube server process (web/CE nodes), not by the scanner.
The JVM truststore is loaded once at process start; changes require a full SonarQube restart to take effect.
Quality Gate evaluation runs independently on the server after analysis data is received; it is unaffected by plugin-download SSL issues.
Expired certificates continue to throw SSLHandshakeException even if previously imported.

Required Steps to Resolve

Identify the active truststore:
java -XshowSettings:properties -version 2>&1 | grep javax.net.ssl.trustStore

Import the self-signed certificate:
keytool -importcert -alias sonarqube-plugin-ca -file /path/to/cert.pem -keystore /path/to/cacerts -storepass changeit -noprompt

Restart SonarQube completely (all nodes in Data Center edition).
Trigger the plugin update manually via Administration → Marketplace.
Verify in web.log and ce.log that no SSLHandshakeException or ValidatorException appears.

Uncertainty / Needs Verification
Marked for review: The exact log location of plugin-download failures may vary by SonarQube version (9.x vs 10.x vs 2025 LTS). Confirm whether web.log, ce.log, or es.log captures the handshake error in your deployment.

One Diagnostic Detail Needed
Which SonarQube edition and version are you running (Community, Developer, Enterprise, Data Center; 9.9 LTS, 10.x, 2025.1 LTS)? This determines whether a single-node restart suffices or a rolling restart across cluster nodes is required.

SonarQube Quality Gate behavior with self‑signed certificates in plugin downloads

Goal

Constraints

Unresolved Decision

Specific Questions

1 answer

Direct Answers

Confirmed Behavior

Required Steps to Resolve

Uncertainty / Needs Verification

One Diagnostic Detail Needed

Your perspective belongs here.

0 question comments