NetBeans JVM TrustStore Configuration for Custom SSL Certificates
0 reputation · 20 Jun 2020, 14:13 UTC
0 reputation · 20 Jun 2020, 14:13 UTC
NetBeans relies on the Java Runtime Environment (JRE) cacerts file for SSL/TLS certificate validation. While global proxy settings are managed within the IDE options, the import of custom or self-signed certificates typically requires external manipulation of the JRE keystore using the keytool utility.
Modifying the default JRE truststore impacts all Java applications utilizing that specific runtime. To isolate certificate trust to the IDE, the netbeans.conf file supports JVM arguments such as -Djavax.net.ssl.trustStore to point to a dedicated keystore file.
When utilizing a custom truststore via netbeans.conf, it is unclear if the IDE maintains a merged trust relationship with the default JRE cacerts or if the specified store completely replaces the default validation chain.
netbeans.conf override or append to the system JRE certificates?35275 reputation · 20 Jun 2020, 21:29 UTC
Specifying a custom trust store via -Djavax.net.ssl.trustStore in netbeans.conf overrides the default JRE cacerts file. It does not append to or merge with the system certificates; the JVM will only trust certificates contained within the specified custom store.
Because the custom store replaces the default one, the recommended approach to maintain global trust while adding a custom certificate is to create a derivative keystore.
cacerts file to a new location to preserve the default CA chain.
cp $JAVA_HOME/lib/security/cacerts /path/to/custom_truststore.jkskeytool utility to add your specific certificate to the copy.
keytool -import -alias custom-cert -file mycert.crt -keystore /path/to/custom_truststore.jks -storepass changeitnetbeans_default_options string in netbeans.conf:
-Djavax.net.ssl.trustStore=/path/to/custom_truststore.jks -Djavax.net.ssl.trustStorePassword=changeitTo confirm that NetBeans is utilizing the custom store during plugin updates or other network operations, use these methods:
-Djavax.net.debug=ssl,handshake to netbeans.conf. Upon restart, check the IDE output/logs for the line trustStore is: /path/to/custom_truststore.jks.SSLHandshakeException indicates the certificate is now trusted.keytool -list -keystore /path/to/custom_truststore.jks.If the connection still fails after these steps, please provide the JDK version NetBeans is using and the exact error message from the log to determine if the JVM is ignoring the configuration or if there is a certificate chain mismatch.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 20 Jun 2020, 23:35 UTC
One practical gotcha worth adding: netbeans.conf exists in two places — the installation directory and the per-user directory (userdir/etc/netbeans.conf). Edits to the wrong copy silently do nothing, which looks exactly like a trustStore problem. Also, if NetBeans runs on its bundled JDK rather than a system JDK, the cacerts you cloned must come from that same runtime, or the default CA set may differ from what you expect.
For verification, the negative test is the most convincing: temporarily point -Djavax.net.ssl.trustStore at an empty keystore and restart. If plugin updates and other HTTPS calls now fail with PKIX path-building errors, the flag is genuinely honored and replaces the default chain. Restore the real store afterward.
Finally, remember to remove -Djavax.net.debug=ssl once diagnosed — it logs TLS handshake details you don't want persisting in IDE logs.