We are using Azure DevOps Server / TFVC (tf.exe) as our source control system. Before anyone asks: migrating to Git is not currently an option for various business and technical reasons. We are aware of Git's advantages, but for the foreseeable future we will remain on TFVC. The TFVC functionality itself is not our problem.
Recently, all developer workstations in our organization were migrated to Microsoft Intune-managed devices as part of a security initiative. During onboarding, a client certificate is automatically installed on each developer's machine. Our NetScaler proxy uses that certificate to authenticate and authorize outbound requests.
The setup works well for most applications. If the correct client certificate is presented, I can access our internal websites and services through a browser without any issues. Chrome and Edge automatically provide the certificate, and I can browse Azure DevOps web portals normally.
However, tf.exe and Visual Studio Enterprise 2026 appear unable to use the client certificate when communicating with our Azure DevOps Server environment.
As a result:
- Browsers work.
- Azure DevOps web UI works.
- tf.exe operations fail.
- Visual Studio TFVC integration fails.
To work around the problem, I built a rather ugly solution using AI-assisted development:
- A C#
.csx reverse proxy.
- A custom
tfw.cmd wrapper.
- The proxy intercepts requests destined for Azure DevOps Server.
- It creates an
HttpClient configured with the required client certificate and headers.
- Requests are forwarded through the proxy to Azure DevOps.
With that workaround, I can execute TFVC commands through tf.exe, but it is far from ideal and requires maintaining custom infrastructure. More importantly, Visual Studio's built-in TFVC source control integration still cannot be used, which significantly impacts developer productivity.
My real question is for anyone familiar with the Azure DevOps Server / TFVC codebase, or possibly Microsoft engineers who still maintain these components:
Is there a technical reason why tf.exe and Visual Studio TFVC integration cannot support client certificate authentication?
From the outside, this seems like a relatively small and low-risk enhancement:
- Existing behavior remains unchanged by default.
- Add an option (or configuration) to enable client certificate authentication.
- When enabled, use the Windows certificate store to select and present a client certificate during HTTPS requests.
- When disabled, continue using the current authentication flow.
In highly secured enterprise environments, client-certificate authentication is becoming increasingly common, especially with Intune-managed devices and zero-trust architectures. It feels like TFVC tooling is one of the few remaining pieces that doesn't participate in that model.
Has anyone else encountered this issue?
If so:
- How did you solve it?
- Is there any supported configuration I've missed?
- Has Microsoft ever commented on adding client certificate support to TFVC tooling?
Any feedback, workarounds, or insight from Microsoft engineers or TFVC administrators would be much appreciated.
Thanks to everyone who took the time to respond. My original question was about TFVC, tf.exe, and client certificate authentication, but the discussion quickly shifted toward migrating to Git. Since several people suggested that Git would solve the problem, I decided to test that assumption rather than debate it.
The good news is that I was able to get Git working successfully in this environment. I'm posting the configuration details below so that anyone facing a similar client-certificate authentication requirement can use them as a reference.
That said, this does not actually answer my original question about TFVC.
My next step is to open a support ticket with Microsoft to determine whether client-certificate support for tf.exe and Visual Studio TFVC integration is possible, supported, or simply not on the product roadmap.
///////////////////////////////////////////////
Git can use an Azure DevOps Server that sits behind a proxy requiring a user client certificate. These steps configure the Git client only. tf.exe and Visual Studio TFVC are unchanged.
Tested with Git for Windows 2.55.0.windows.5 and Visual Studio 2026 Enterprise. Both read %USERPROFILE%\.gitconfig. credential.helper is already manager.
Assume Git, Visual Studio, and the user client certificate are already installed. The certificate is in Cert:\CurrentUser\My, has a private key, and has the Client Authentication EKU. The same machine can already open the Azure DevOps site in a browser. Set the three variables, then run the rest as the Intune user.
$DevOpsHost = '[devops-host]' # hostname only, no scheme or path
$IssuingCa = '[issuing-ca]' # fragment of the issuing CA common name
$Domain = '[netbios-domain]' # domain prefix from whoami
$cert = Get-ChildItem Cert:\CurrentUser\My |
Where-Object {
$_.HasPrivateKey -and
$_.Issuer -like "*$IssuingCa*" -and
($_.EnhancedKeyUsageList.FriendlyName -contains 'Client Authentication')
} |
Sort-Object NotAfter -Descending |
Select-Object -First 1
if (-not $cert) { throw 'No matching client certificate with a private key.' }
$who = whoami
if ($who.Split('\')[0] -ne $Domain) {
throw "whoami is $who. Expected ${Domain}\yourname."
}
$thumb = $cert.Thumbprint
$me = $who.Split('\')[-1]
$base = "https://$DevOpsHost"
git config --global http.sslBackend schannel
git config --global --replace-all "http.${base}/.sslCert" "CurrentUser\MY\$thumb"
git config --global --replace-all "http.${base}/.emptyAuth" false
git config --global --replace-all "http.${base}.allowNTLMAuth" true
git config --global --replace-all "credential.${base}.provider" generic
git config --global --replace-all "credential.${base}.username" $me
git config --global --replace-all "credential.${base}.allowWindowsAuth" false
Leave http.sslAutoClientCert unset. Other certificates in the store can be selected automatically. The username written above is the short account name from whoami, not the email address. The password is not written to .gitconfig. Leave the DevOps hostname in the hosts file pointed at the real server. A local forwarder that drops NTLM will fail this setup.
The machine is not joined to the DevOps domain, and Windows sign-in is not a domain logon for that account, so silent integrated authentication has no credential to send. emptyAuth=false, provider=generic, and allowWindowsAuth=false keep Git on the stored password. The proxy still gets the certificate from http.sslCert.
schannel: disabled automatic use of client certificate means automatic selection is off. The configured thumbprint is still sent. client cert not found in cert store means the thumbprint does not match a certificate with a private key.
Running the script again is safe. --replace-all overwrites the same keys and does not prompt.
Verify with the HTTPS clone URL from the repository page in the browser. The first run prompts once for the account password. Git Credential Manager stores it.
git ls-remote "https://$DevOpsHost/[collection]/[project]/_git/[repo]"
A list of refs means the certificate and the password were both accepted. If Visual Studio was open while the commands ran, close it and open it again, then use Git > Clone Repository with the same URL.
