[Feature]: Native Rust HTTP requests on Windows should use the OS Trust Store and Support OS-provided client certificates (mTLS parity with WebView `fetch`)

[Ryanphoenix]

Before you start

• I searched the existing issues and did not find a duplicate request.

What problem does this solve?

Remote HTTP requests in the desktop app have two different behaviors depending on how they are routed. Certain fetches use webview + javascript, which works natively with OS provided certificate trust stores. In some enterprise cases, mTLS is required for endpoints, which then prompt the user to select their certificate.

However, the native rust HTTP isn't configured in such a way that the OS provided trust store is accessible, which means requests that require mTLS (such as OGC GetCapabilities) fail as the client side application doesn't allow the user to present their certificate.

Proposed solution

Users should have a similar experience as the javascript/WebView fetch requests where if a server requires mTLS, the user is prompted for their certificate. I do not know if rust has any way to natively prompt the user for their certificate interatively.

As a secondary, less desired option, the application should either let a user pass in a path to both their CA verify certificate and a .pem or .p12 + passphrase for user certificate, but this presents a lot more configuration o nthe user end as well as possible security concerns.

Estimated scope

Medium: a broader feature that is feasible in a reasonable timeframe

Alternatives considered

Currently none. Any native rust HTTP request method fails if accessing an enterprise http endpoint protected by mTLS.

[Ryanphoenix]

I scoped this specifically to windows, as that's the main user base in the environment where enterprise level mTLS support is required. I'm not familiar enough with rust to know if there is an appropriate library we could use instead.

[giswqs]

I don't use Windows and I don't have an endpoint with mTLS for testing it. Will see if it can be implemented.

[Ryanphoenix]

understood, I can look into seeing if I can't get something working locally, or optionally if you are able to implement I can definitely test. Thank you!

[giswqs]

I took a pass at this. Quick assessment and a PR that covers the config-based path.

On the interactive certificate prompt (the preferred option): the WebView gets that prompt because WebView2/SChannel drives an OS certificate-selection UI during the handshake. The native Rust HTTP client (reqwest) exposes no equivalent, on either TLS backend (rustls or native-tls) it cannot pop an OS cert picker. Reaching parity would mean custom Windows-only SChannel code, which is a much larger and riskier effort. So this is not feasible with the current stack.

What the PR does instead (#1225), implementing the secondary option you outlined:

1. Native Rust HTTP now trusts the OS/system certificate store in addition to the bundled roots, so servers signed by an enterprise CA installed on the machine work with no configuration.
2. For mTLS, you point the app at a client certificate with environment variables:
   • GEOLIBRE_HTTP_CLIENT_CERT a .pem (chain + unencrypted PKCS#8 key) or a PKCS#12 .p12/.pfx
   • GEOLIBRE_HTTP_CLIENT_CERT_PASSWORD passphrase for a PKCS#12 cert
   • GEOLIBRE_HTTP_CA_CERT optional PEM bundle for a private CA not installed system-wide

PKCS#12 certs (with passphrase) go through the platform native TLS stack (SChannel on Windows); PEM certs use rustls.

I verified the plumbing end to end against a local mTLS test server (both PEM and PKCS#12-with-passphrase client certs complete the handshake; a client without the cert is rejected), but I don't have a Windows machine or a real enterprise mTLS endpoint. Since you offered to test, could you try a build from the PR branch against your OGC endpoint once it is available? That is the validation I can't do here. Thanks!