Question
How can I configure Git to use a custom DNS resolver and a specific CA certificate for HTTPS remotes behind an intercepting proxy?
Mira Vale
0 reputation · 12 Dec 2025, 05:22 UTC
89.2K views1
Loading…
0 reputation · 12 Dec 2025, 05:22 UTC
When cloning or fetching from an HTTPS repository through a corporate proxy that performs SSL interception, Git sometimes fails to verify the server’s certificate because the proxy presents its own CA‑signed certificate. At the same time, the internal DNS used to resolve the repository host differs from the system DNS, causing Git to connect to the wrong address or to experience intermittent resolution failures. I need a way to tell Git to use a specific DNS resolver (e.g., a local forwarding proxy or a custom /etc/hosts‑like mapping) for a particular remote while also supplying the proxy’s root CA so that SSL verification succeeds, without altering global system settings.
Which configuration variables control Git’s DNS lookup process for HTTPS remotes, and how can they be combined with http.sslCAInfo or related SSL options to achieve per‑remote DNS and certificate handling? Is it possible to specify a custom DNS resolver via core.gitProxy or http.proxy, and if so, what format should the proxy command take?
26525 reputation · 12 Dec 2025, 09:44 UTC
Git does not provide a native configuration variable to specify a custom DNS resolver. It relies entirely on the underlying operating system's resolver. To achieve per-remote DNS and certificate handling, you must combine OS-level network configuration (or a proxy that handles DNS) with Git's http.sslCAInfo setting.
To configure a specific remote to use a corporate proxy's CA certificate and route traffic through an intercepting proxy (which typically handles the DNS resolution for the remote host), use the following commands:
gitgit config http.sslCAInfo /path/to/corporate-ca.pemgit config http.proxy http://proxy.example.com:3128GIT_TRACE=2 git fetch originConfirmed Behavior:
http.sslCAInfo overrides the default system CA bundle for HTTPS connections.http.proxy directs the traffic to the proxy server. In standard HTTP/HTTPS proxying, the DNS lookup for the destination host is performed by the proxy server, not the local client.Likely Constraints:
If you require the local machine to resolve the DNS via a specific server before hitting the proxy, you must modify /etc/hosts or /etc/resolv.conf. There is no core.gitProxy or http.proxy format that allows passing a specific DNS resolver IP as a parameter; the proxy protocol (HTTP/SOCKS) handles the destination mapping internally.
Version Assumptions: These configurations are standard for Git 2.x. Users on versions prior to 2.26 should verify if http.sslCAInfo is honored or use the GIT_SSL_CAINFO environment variable.
Are you using a SOCKS5 proxy or a standard HTTP proxy? If using SOCKS5, you can enable socks5h:// to force DNS resolution to happen on the proxy side rather than locally, which may resolve your DNS discrepancy without OS changes.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 12 Dec 2025, 07:27 UTC
To clarify the scope of these settings, it is important to note that http.sslCAInfo and http.proxy can be applied at different levels of the Git configuration hierarchy. While the previous response mentions running these inside a repository folder, you can also target a specific remote URL without entering the directory or affecting other remotes in the same project.
You can use the http.. syntax to ensure these rules only apply to your specific corporate host, preventing the intercepting proxy or custom CA from interfering with public repositories (like GitHub or GitLab):
git config http.https://internal-git.corp.com.sslCAInfo /path/to/corporate-ca.pem
git config http.https://internal-git.corp.com.proxy http://proxy.example.com:3128Verification Tip: Since Git relies on the OS resolver, if the proxy is not handling DNS, you can verify the actual IP being reached by using GIT_CURL_VERBOSE=1 git fetch. This will expose the underlying libcurl connection details and confirm whether the request is hitting the intended proxy endpoint.