Connection fails behind corporate proxy

I use git for windows behind a corporate proxy and use connect.exe to tunnel the ssh connection:

Host *
 ProxyCommand "C:/Program Files/Git/mingw64/bin/connect.exe" -H localhost:9000 %h %p
 TCPKeepAlive yes
 IdentitiesOnly yes

The corporate proxy (Zscaler) performs package inspection and therefore I need to add the proxy's root ca certificate to the trust store.

Unfortunately I could not identify the ca-bundle used by connect. Hence the connection fails with a key exchange exception.

What trust store is used by connect.exe?

[jdstroy]

connect is a simple proxy client with no awareness of TLS/SSL; consequently, it has no understanding or capability for using certificates. Your usage of connect (with the -H option) requests that connect use the HTTP Proxy protocol (specifically, the CONNECT verb in RFC 7231, section 4.3.6, without negotiating TLS). Furthermore, for your usage of git over SSH, SSH also does not support using TLS/SSL; it has its own scheme for handling PKI (public keys and certificates) that is separate and distinct from X.509 certificates that are used in TLS.

If the SSH server (hosting the git repository) you're trying to connect to is running on port 443, your network administrator needs to configure zscaler to allow SSH tunneling (deep packet inspection will interfere with SSH traffic on port 443 because zscaler assumes all such traffic is HTTPS over TLS). If it is not running on port 443, your network administrator needs to enable firewall rules in zscaler to allow such connections.

[gotoh]

I don't know much about ZScaler, so I just asked Gemini and got a feel for it. If you're using ZCC, I don't think using a connect will improve the situation.

Would these commands not work? (Without using ProxyCommand)

$ ssh -vT -p 22 git@ssh.github.com

$ ssh -vT -p 443 git@ssh.github.com

(see https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port)

If these errors are due to inspection issues,
I think you should contact your system administrator and ask about how to handle port 22.
It doesn't seem like this issue would change even if connect spoke SSL/TLS.