Test PR only

[renzjephte]

No description provided.

In general, the fix is to stop using a custom X509TrustManager that unconditionally trusts all certificates. Instead, either (a) rely on the default system trust store (what createSecureClient() already does), or (b) if self‑signed or private CA certificates must be supported, load those specific certificates into a KeyStore and initialize a TrustManagerFactory from it, as in the “good” example in your background section.

The minimal, non‑breaking change here is to remove the insecure TrustManager and make createInsecureClient() return a properly verifying client. Since createSecureClient() already creates a standard secure HttpClient, the safest change is to have createInsecureClient() delegate to createSecureClient() instead of building a custom SSLContext with trustAllCerts. This preserves the API (there is still an insecureHttpClient field), avoids guessing about how it is used elsewhere, and completely eliminates the “trust all certificates” behavior.

Concretely, in IDE/src/main/java/com/ing/ide/main/mainui/components/apitester/util/APIHttpClient.java:

• Replace the body of createInsecureClient() (lines 62–84) with a simple call to createSecureClient().
• This removes the insecure X509TrustManager and the custom SSLContext. No new imports or helper methods are required.

In general, the fix is to remove the custom TrustManager that unconditionally trusts all certificates, and instead always use a proper trust manager derived from a key store (either the default system trust store or a custom CA/certificate store). If you need to support self-signed or custom certificates, you should add those certificates to a KeyStore and initialize a TrustManagerFactory from that keystore, instead of bypassing validation.

For this file, the best minimally invasive fix is:

• Stop creating an insecure anonymous X509TrustManager when trustAll is true.
• Reuse the existing createTrustManagers(certConfig) method to obtain the trust managers even when the caller disables “SSL verification”. That keeps certificate validation intact while still honoring any custom CA configuration in CertificateConfig.
• Optionally, if you must allow disabling hostname verification but not certificate validation, you would adjust elsewhere (e.g. via a HostnameVerifier) rather than via a trust-all trust manager. However, no such code is visible here, so the safe change is simply to ignore the trustAll flag for trust manager selection.

Concretely:

• In createCertificateSSLContext in APIHttpClient.java, replace the if (trustAll) { ... } else { ... } block that creates the anonymous X509TrustManager with a simple call to createTrustManagers(certConfig) regardless of the value of trustAll.
• No new imports or additional helper methods are required; we just remove the insecure branch and always rely on createTrustManagers.

---