I think I found the troublemaker. And interestingly enough it was neither the controller nor ziti-edge-tunnel. Since supposedly we were the only ones having this problem I dug into the certificate files, permissions etc. so see where the issue could lie.
Back in the day when we set up our ziti infrastructure, there was still a spurious intermediate certificate in the chain, which as @TheLumberjack pointed out was to demonstrate arbitrarily deep trust roots.
About a year ago we had issues with our Ziti PKI, requiring us to change our cas.pem CAs file. All connections worked afterwards, so we didn't spend too much time investigating this further.
Turns out, this one spurious intermediate cert as mentioned above was NOT in the cas.pem file. However, when using legacy auth, this is apparently NOT a problem (which I don't understand). When using newer ziti-edge-tunnel versions that authenticate via OIDC, it seems as if the TLS connection gets established but then aborted if the chain isn't complete.
Does that explanation make sense for you as well?
Anyways, I do thank you a lot for your continuous support and help in all matters regarding OpenZiti! I love the product and as I already mentioned on LinkedIn on one of Galeal Zinos posts on LinkedIn: It sometimes feels like having a real world cheat code to just being able to always securely communicate through insecure connections and even making it easier to access those services.
Apologies for the effort I've caused with this misconfiguration on your end. I think the ziti-sdk-c PR might still be useful. Il think about how we can manage to skip strndup.