Question
PKIX path building failed: unable to find valid certification path to requested target when accessing Plugin Repository
Neel Indigo
0 reputation · 21 Dec 2021, 10:49 UTC
34.8K views1
Loading…
0 reputation · 21 Dec 2021, 10:49 UTC
The goal is to allow CLion to trust a self‑signed or corporate‑issued certificate for HTTPS access to the Plugin Repository without modifying the global JDK cacerts truststore, which would affect all Java‑based tools bundled with the IDE.
As of CLion 2024.3 the IDE does not provide a UI for managing custom trust stores; the only documented approach is to set the -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword VM options, which apply to the entire JVM and may cause unintended security warnings for other components.
What mechanisms exist to scope a custom trust store to the CLion instance or specifically to plugin‑repository connections? Can CLion be launched with a per‑IDE truststore that does not alter the bundled JDK? Are there any planned UI enhancements to manage custom CAs for plugin repository access?
35275 reputation · 21 Dec 2021, 11:39 UTC
As of CLion 2024.3, there is no supported way to scope a custom trust store exclusively to plugin-repository connections. The only per-IDE mechanism that avoids modifying the bundled JDK is the IDE's internal Server Certificates store. JVM-wide -Djavax.net.ssl.trustStore options are process-global and replace the default truststore rather than appending to it.
The PKIX path building failed error means the JVM cannot build a trust chain from the repository's certificate to a trusted anchor. Confirmed behavior: JetBrains IDEs ship with a bundled JRE whose cacerts file is the default trust anchor. The IDE also maintains a separate internal trust store for its HTTP client, configured under Settings/Preferences > Tools > Server Certificates. Certificates imported there are stored in the IDE configuration directory and are used by the internal plugin-update client.
clionImport the repository root CA into the IDE store. Obtain the root or intermediate CA certificate for the plugin repository (or your corporate MITM proxy) in PEM or CRT format. In CLion, open Settings/Preferences > Tools > Server Certificates and import the file. This does not alter the bundled JDK's cacerts.Verify the import. Confirm the certificate appears in the Server Certificates list. If the repository is still unreachable, check Help > Show Log in Explorer/Finder for the specific handshake failure. If the log shows the same PKIX error, the internal HTTP client may not be the component making the connection.Fallback: merged JVM truststore. If the IDE store does not resolve the issue—for example, because a proxy or separate process handles the connection—the documented fallback is a JVM-wide truststore. You must merge the bundled cacerts with your custom CA into a new file, then pass -Djavax.net.ssl.trustStore=/path/to/merged.jks and -Djavax.net.ssl.trustStorePassword=changeit via Help > Edit Custom VM Options. Using a custom-only truststore will break trust for public CAs.I cannot confirm any planned UI enhancements for per-connection or per-IDE trust store management beyond the existing Server Certificates page. Treat roadmap claims as unverified until JetBrains publishes them.
Does the PKIX error occur only when browsing the Plugin Repository, or also during other IDE HTTPS operations (update checks, version control, web previews)? If it is repository-only, the Server Certificates import is the correct first step. If it is IDE-wide, the root cause is more likely a missing CA in the bundled JDK or network-level SSL inspection, which would change the recommendation toward a merged truststore or proxy configuration.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.