TrustAnchors
Which certificates a client is willing to trust for TLS.
useTls used to be the whole story, and with one engine and a JVM caller it was enough: anything unusual was reachable through configureClient, which hands back Ktor's HttpClientConfig<*>. A star projection cannot open an engine-specific block, so that escape hatch stopped working the day the transport went multiplatform — on three of the four targets it was never available at all.
The cases this exists for are ordinary. Qdrant Cloud serves a public certificate and needs nothing here. A self-hosted cluster behind a company CA, a staging node with a self-signed certificate, and anything that wants certificate pinning are all normal deployments, and all of them ended at "use the JVM".
Which store each platform reads
System is not one store. It is whichever store the platform keeps, and knowing which one is the difference between adding a certificate in the right place and adding it twice in the wrong ones:
| Target | Engine | System trust means |
|---|---|---|
| JVM | CIO | the JDK's cacerts truststore |
| iOS, macOS | Darwin | the system keychain, plus App Transport Security |
| Linux | Curl | the CA bundle libcurl was built against, usually /etc/ssl/certs |
| Windows | WinHttp | the machine and user certificate stores |
What each platform supports
A combination a target cannot honour is refused when the client is built, with a message naming the platform and the store to put the certificate in. Silently falling back to system trust would be the worst of the options: the connection would succeed, and the caller would believe they had pinned it.