Git Credential Manager Core doesn't support TLS client certificates

[prestongilchrist]

With git 2.28.0 using schannel we were able to use client certificates to connect to HTTPS servers secured with mutual TLS with certificates in the user certificate store. This appears to no longer be possible with GCMC. Is there an option to use these certificates, especially hardware certificates access through the personal certificate store.

[mjcheetham]

Hi @prestongilchrist,

Please can you answer the following questions from the issue template:

---

Which version of GCM Core (and Git) are you using?

From a terminal, run git credential-manager-core version and git --version and paste the output.

Which Git host provider are you trying to connect to?

• Azure DevOps
• Azure DevOps Server (TFS/on-prem)
• GitHub
• GitHub Enterprise
• Bitbucket
• Other - please describe

Can you access the remote repository directly in the browser using the remote URL?

From a terminal, run git remote -v to see your remote URL.

Logs

Set the environment variables GCM_TRACE=1 and GIT_TRACE=1 and re-run your Git command. Review and redact any private information and attach the log.

---

Additionally can you tell us (if you know):

• Did this uses to work in Git Credential Manager for Windows (GCMW?)
• Do you see any output from GCM or Git from the command line? Any errors or warning messages?
• What version of Windows (I assume this is Windows as you mention using schannel) are you on?

Thanks!

[mjcheetham]

Is this possibly related to this Git issue? git-for-windows/git#3292

Starting from Git 2.32 (that includes cURL 7.77), TLS client certificates are not being sent automatically when using the schannel backend.

[dscho]

Please test the latest Git for Windows snapshot. You will need to configure http.sslAutoClientCert e.g. via git config --global http.sslAutoClientCert true.

[pascalmuller]

Hello,

I'm not the one that created this issue, but I did open git-for-windows/git#3292.

I don't use Git Credential Manager Core, but a colleague mentioned he did experience similar problems to the person that opened this issue, and reverted back to the old Git Credential Manager. However, he mentioned this has been going on for a longer time than would be possible, given the cause of that issue. (an update to curl)

As I felt it might be similar to my ticket, I decided to attempt to replicate this.

Unfortunately, the problem seems to be a bit older and is not fixed by the solution to git-for-windows/git#3292

I stored the credentials for a in-company hosted Bitbucket server (unfortunately, I cannot share the URL, as it is internal). The server is additionally secured by needing a client certificate available in the Windows Certificate Store. So my setup should be roughly the same.

Using git blame, I have found a commit that seems to have introduced the problem: a73496b

Until this commit, get returns the stored credentials:

git-credential-manager-core.exe get
protocol=https
host=REDACTED

protocol=https
host=REDACTED
username=mullerp
password=REDACTED

Since a73496b it fails:

git-credential-manager-core.exe get
protocol=https
host=REDACTED

fatal: Er is een fout opgetreden bij het verzenden van het aanvraag.
fatal: De aanvraag is afgebroken: Kan geen beveiligd SSL/TLS-kanaal maken.

I guess it fails as the client certificate is not sent to the server.

I tried repeating this in the most recent main with GCM_TRACE enabled:

git-credential-manager-core.exe get
21:03:35.737050 ...\Application.cs:80   trace: [RunInternalAsync] Version: 2.0.488.23450
21:03:35.743146 ...\Application.cs:81   trace: [RunInternalAsync] Runtime: .NET 5.0.6
21:03:35.743317 ...\Application.cs:82   trace: [RunInternalAsync] Platform: Windows (x86-64)
21:03:35.743528 ...\Application.cs:83   trace: [RunInternalAsync] AppPath: <REDACTED>Git-Credential-Manager-Core\out\shared\Git-Credential-Manager\bin\Debug\net5.0\git-credential-manager-core
21:03:35.743718 ...\Application.cs:84   trace: [RunInternalAsync] Arguments: get
21:03:35.780732 ...GitCommandBase.cs:35 trace: [ExecuteAsync] Start 'get' command...
protocol=https
host=REDACTED

21:03:38.480622 ...GitCommandBase.cs:49 trace: [ExecuteAsync] Detecting host provider for input:
21:03:38.481247 ...GitCommandBase.cs:50 trace: [ExecuteAsync]   protocol=https
21:03:38.481424 ...GitCommandBase.cs:50 trace: [ExecuteAsync]   host=REDACTED
21:03:38.546410 ...viderRegistry.cs:149 trace: [GetProviderAsync] Performing auto-detection of host provider.
21:03:38.547699 ...viderRegistry.cs:162 trace: [GetProviderAsync] Checking against 3 host providers registered with priority 'Normal'.
21:03:38.548868 ...viderRegistry.cs:154 trace: [GetProviderAsync] Querying remote URL for host provider auto-detection.
21:03:38.550435 ...pClientFactory.cs:54 trace: [CreateClient] Creating new HTTP client instance...
fatal: The SSL connection could not be established, see inner exception.
fatal: Authentication failed because the remote party sent a TLS alert: 'HandshakeFailure'.
fatal: Het ontvangen bericht is niet verwacht of onjuist ingedeeld.

I guess the autodetection in a73496b causes a connection to be opened. As no special care is taken to send client certificates from the certificate store, the connection fails.

So I guess either client certificates need to be sent to the server, or the connection failure should not prevent git-credential-manager-core from returning stored credentials.

I hope I've been able to be of help. Have a good weekend!

[vtbassmatt]

@mjcheetham this looks like a tough one for us to handle, since we don't have a mutual TLS setup anyplace. Thoughts on what to do?

[pascalmuller]

While this is not fixed, I think the severity of the problem has decreased with recent changes.

I noticed after the last Git for Windows update, that the new version of Git-Credential-Manager-Core (I have version 2.0.567+3047faf390) shows a better, more informative message if the autodetection goed wrong that points to https://aka.ms/gcmcore-autodetect

On this page, the possibility to disable the autodetection completely was brought to my attention.

After running git config credential.redactedexample.com.provider generic, Git-Credential-Manager-Core returns the credentials instead of showing a fatal error.

I feel that the error message pointing to a page explaining how this can be turned off makes the impact less severe, as turning autodetection off mitigates the problem that the stored credentials are not returned.

After digging around, the new behavior (improved error message) seems to have been introduced in 537c0ba

I do however believe that it might be better if stored credentials would be returned, even if the autodetect fails.

I hope that this update might help to reassess the impact of this bug.