Ballerina HTTP Client Rejects Self-Signed Certificates by Default: Trust Store or CA-Signed Cert?

Default validation and the open decision

Ballerina's http:Client validates TLS certificates by default, so an endpoint presenting a self-signed or otherwise untrusted certificate fails the handshake. The documented paths forward are supplying a custom trust store through the client's secure socket configuration, or having the endpoint present a CA-signed certificate. A validation-bypass mode exists but is documented as insecure and meant only for isolated testing.

Two constraints frame the choice. Exact ClientSecureSocket field names and options have varied across Swan Lake releases, so they need confirming against the installed distribution's API docs. DNS resolution is delegated to the JVM/OS resolver, and hostname verification runs inside the handshake, so a SAN mismatch surfaces as a generic SSL error that is easy to mistake for a name-resolution problem.

For a caller integrating with such an endpoint, the unresolved decision is whether to pin the self-signed certificate per client through a trust store or to move the endpoint to a CA-signed certificate.

1. On current Swan Lake releases, does a per-client trust store replace or extend the JVM default trust material for that client?
2. Once the certificate is trusted, does hostname verification still reject access by IP address instead of the certificate's DNS name?
3. When does rotating a pinned self-signed certificate cost more operationally than issuing a CA-signed certificate from an internal CA?