Add Support for Custom CA Certificates in DevoxxGenie TLS Connections

[stephanj]

There doesn't appear to be an explicit mechanism for configuring custom CA certificates. The plugin uses standard Java HTTP clients and libraries for making connections, which typically rely on the system's trusted certificate store or the JVM's cacerts keystore.

Additional configuration might be necessary to establish TLS connections with custom CA certificates.

To address this issue we have a few options:

1. Modify the plugin code to allow custom CA certificate configuration: You could add a configuration option in the settings to specify a custom truststore or individual CA certificates. This would involve modifying the OkHttpClient configurations used in various parts of the plugin.

   For example, in the GeminiClient class:

   public class GeminiClient {
       // ... existing code ...
   
       @Builder
       public GeminiClient(String baseUrl,
                           String apiKey,
                           String modelName,
                           Duration timeout,
                           String customTrustStorePath,
                           String customTrustStorePassword) {
   
           OkHttpClient.Builder clientBuilder = new OkHttpClient.Builder()
               .callTimeout(timeout)
               .connectTimeout(timeout)
               .readTimeout(timeout)
               .writeTimeout(timeout);
   
           if (customTrustStorePath != null && !customTrustStorePath.isEmpty()) {
               try {
                   KeyStore trustStore = KeyStore.getInstance("JKS");
                   trustStore.load(new FileInputStream(customTrustStorePath), customTrustStorePassword.toCharArray());
                   TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
                   tmf.init(trustStore);
                   SSLContext sslContext = SSLContext.getInstance("TLS");
                   sslContext.init(null, tmf.getTrustManagers(), null);
                   clientBuilder.sslSocketFactory(sslContext.getSocketFactory(), (X509TrustManager) tmf.getTrustManagers()[0]);
               } catch (Exception e) {
                   throw new RuntimeException("Failed to initialize custom trust store", e);
               }
           }
   
           OkHttpClient okHttpClient = clientBuilder.build();
   
           // ... rest of the existing code ...
       }
   }
   

   You would need to make similar modifications to other classes that create HTTP clients, such as OllamaApiService, JanService, etc.

2. Use system properties to specify the truststore: Instead of modifying the plugin code, you could set Java system properties when launching IntelliJ IDEA. This approach affects all Java applications running in that JVM instance, including the DevoxxGenie plugin.

   Add these VM options to your IntelliJ IDEA launcher:

   -Djavax.net.ssl.trustStore=/path/to/your/truststore.jks
   -Djavax.net.ssl.trustStorePassword=your_truststore_password
   

3. Import the custom CA certificate into IntelliJ IDEA's JVM cacerts: Locate the cacerts file used by the JVM that runs IntelliJ IDEA (usually in the JDK's lib/security directory) and import your custom CA certificate into it using the keytool utility.

   keytool -importcert -alias your_custom_ca -file your_ca.crt -keystore path/to/intellij/jdk/lib/security/cacerts -storepass changeit
   

   Note that this affects the entire IntelliJ IDEA instance and all plugins.

4. Use a network debugging tool: To diagnose the issue, you can use tools like Wireshark or mitmproxy to inspect the TLS handshake and identify exactly why the connection is failing. This might reveal if the problem is related to certificate validation or some other TLS configuration issue.

Option 2 or 3 would be the quickest solutions without modifying the plugin code. If you need a more tailored solution, you might consider contributing a feature to the DevoxxGenie project to add custom CA certificate support.

[stephanj]

We could also consider to trust all certificates. However many of the model clients are based in the langchain4j package, so they would need to be "extended".

https://www.baeldung.com/okhttp-client-trust-all-certificates

[stephanj]

Won't fix