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 an hour ago | parent | next [-]

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 an hour ago \| parent [-]
		> 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.

▲

dcminter an hour ago | parent | prev | next [-]

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 seperately, 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.

▲

sureglymop an hour ago | parent | prev | next [-]

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 an hour ago \| parent [-]
		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.

▲

nikanj an hour ago | parent | prev [-]

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!