[gschizas]

The fact that most tools have completely different ways to allow them to add certificates is the biggest pain. Git, Python and Rust also have large issues. Git doesn't default to "http.schannel". Python (or rather requests, or maybe urllib3) only looks at its own certificate store, and I have no idea how Rust does this (well, I use uv, and it has its own problems - I know about the --use-native-tls flag, but it should be a default at the least).

[noroot]

It's such a nightmare at my current job as well. Everything always just breaks and needs investigating how to fix.

Even putting aside the MITM and how horrendous that is, the amount of time lost from people dealing with the fallout got to have cost so much time (and money). I can't fathom why anyone competent would want to implement this, let alone not see how much friction and safety issues it causes everywhere.

[dcminter]

> I can't fathom why anyone competent would want to implement this

Compliance. Big financial orgs. and the like must show that they are doing something about "data loss" and this, sadly, is the easiest way to do that.

There's money in it if you can show them a better way.

[nikanj]

And many things break in different, exciting ways. For example, we discovered that whilst the JVM can be configured to use system certificate store, that does not apply to websocket connections. So the product seems to be able to connect to the server, but all socket connections bork out with TLS errors.

Fun!

And so many of those products deliver broken chains, and your client needs to download more certificates transparently ( https://systemweakness.com/the-hidden-jvm-flag-that-instantl... )

Double the fun!

[dcminter]

Yeah, and Java has its nice cacerts file so that should have been easy, but then we were using Bazel which does the "hermetic builds" thing so that had to be told about it separately, and on and on with all the other special-snowflake tools.

It added huge amounts of friction which was one reason I decided to move on from that gig.

[jeroenhd]

On Android, macOS/iOS, and Windows, this is a solved problem. Only on the extremely fragmented Linux/Posix runtimes do these problems surface.

Rust's solution is "it depends". You can use OpenSSL (system or statically compiled) or rustls (statically compiled with your own CA roots, system CA roots, or WebPKI CA roots).

I'm afraid that until the *ix operating systems come out with a new POSIX-like definition that stabilises a TLS API, regardless of whether that's the OpenSSL API, the WolfSSL API, or GnuTLS, we'll have to keep hacking around in APIs that need to be compatible with arbitrary TLS configurations. Alternatively, running applications through Waydroid/Wine will work just fine if Linux runtimes can't get their shit together.

[dmm]

> Windows, this is a solved problem.

Are you sure? It's been a few years, but last I tried Firefox used its own CA store on Windows. I'm pretty sure openjdk uses "<JAVA_HOME>/jre/lib/security/cacerts" instead of the system store too.

[crote]

> On Android, macOS/iOS, and Windows, this is a solved problem.

Is it, though? It is absolutely trivial for an Android app (like the one you use for banking) to pin a specific CA or even a specific server certificate, and as far as I'm aware it is pretty much impossible to universally override this.

In fact, by default Android apps don't accept any user-installed certs. It uses separate stores for system-installed CA roots and user-installed CA roots, and since Android 7.0 the default is to only include the system-installed store. Apps have to explicitly opt-in to trusting the user-installed store.

[arianvanp]

Is it solved in macOS? Curl recently removed macOS keychain support as there are like 7 competing APIs 6 of which are deprecated and number 6 is a complete HTTP replacement so curl can't use it.

Only reason why it works on macOS curl is because they're a few versions behind

[dingaling]

I absolutely do not want to be constrained to a single system cert store controlled by the OS vendor.

[sureglymop]

I have this similar gripe when it comes to http proxy configuration. It's invisible to you until you are in an execution environment where you are mandated to use the providers proxy configuration.

Some software reads "expected" env variables for it, some has its own config or cli flags, most just doesn't even bother/care about supporting it.

[amiga386]

Chiefly because "supporting it" requires a full JavaScript interpreter, and subscribing to changes in "system settings" during the lifetime of your program. Easier just to support http_proxy/https_proxy/no_proxy (and what standard for no_proxy? Does it support CIDR ranges?) or even less flexibility than that.