Installs a third-party root certificate ACCVRAIZ1. Remove it.

[Driwars]

In the C:\Program Files\Git\etc\pki\ca-trust\extracted\openssl folder is self-sign ACCVRAIZ1.
It is also set as root in windows cert storage

This is a critical safety issue.

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.17.1.windows.2
cpu: x86_64
built from commit: a60968cf435951d9411fc0f980a2e362d5cccea2
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17763.107]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

** insert your response here **

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

no matter

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

no matter

• What did you expect to occur after running these commands?

no matter

• What actually happened instead?

no matter

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?
  no matter

[dscho]

git version 2.17.1.windows.2

Is this still an issue with a newer Git for Windows?

Note that:

$ pacman -Qo /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt is owned by ca-certificates 20180409-1

I.e. the file comes from https://github.com/msys2/MSYS2-packages/tree/master/ca-certificates

In particular, https://github.com/msys2/MSYS2-packages/blob/master/ca-certificates/PKGBUILD suggests that these certificates come from https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ and since I know and trust Mozilla for a long time already, I am kind of biased to distrust a reporter who I never heard from and who claims that Mozilla slipped in something bad.

You will have to prove that there is something we would really not want, that Mozilla made a mistake, and then I will act (unless you open a PR first)...

[rimrul]

According to Mozzilla (or the list they link) the issuer is

Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)

Seems like a fairly legitimate CA to me.

[Driwars]

Well, I found this certification center of Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV).
Quite official.
But I can not understand what it is for. All programs in the catalog are signed by your certificate from COMODO RSA Code Signing CA.

[rimrul]

It isn't for code signing (or verification thereof). It's trusted root CAs for HTTPS connections.

[mfriedrich74]

Somehow I trust MS and the browser vendors more what root CAs are ok. Is this one on their list? Why not?

…

On Wed, Jun 12, 2019, 3:06 PM Matthias Asshauer ***@***.***> wrote: It isn't for code signing (or verification thereof). It's trusted root CAs for HTTPS connections. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2226?email_source=notifications&email_token=ABZH5SD33EZYOBTTRCVJIKDP2FCMZA5CNFSM4HXGJCL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXRPUSA#issuecomment-501414472>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZH5SGMLVFOJBN6SGP3FETP2FCMZANCNFSM4HXGJCLQ> .

[rimrul]

It was on Microsofts list in January 2018 and probably still is. It's on Mozillas list as mentioned above. It has been since Firefox 27 (2014). Idk about googles list for chrome, but I'd guess it's on there.

[Driwars]

Rechecked for git version 2.22.0.windows.1 to work with git clone https: // *.
Installing certificates in the windows repository is not required, as well as etc\pki\ca-trust\extracted\ openssl.
Only the file mingw64\ssl\certs\ca-bundle.crt is required

Solution for me: manually remove the untrusted in my opinion CA from the mingw64\ssl\certs\ca-bundle.crt file.

Recommendations for the developer: Use certificates only from the windows certificate store, or allow the user to choose where to get the root certificates.

[mfriedrich74]

If it is on the MS list, then it's not required by git to install it. I rather rely on the OS and browser vendor to add or remove entries from the root CA list than individual software. This behavior has a bad taste of installing a back door. Did someone check the allowed usages of this CA certificate (I am not able to at the moment)? It may allow much more than what you think (https). Best regards, Mike

…

On Wed, Jun 12, 2019, 4:00 PM Matthias Asshauer ***@***.***> wrote: It was on Microsofts list in January 2018 <https://social.technet.microsoft.com/wiki/contents/articles/51151.microsoft-trusted-root-certificate-program-participants-as-of-january-30-2018.aspx#G> and probably still is. It's on Mozillas list as mentioned above. It has been since Firefox 27 (2014). Idk about googles list for chrome, but I'd guess it's on there. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2226?email_source=notifications&email_token=ABZH5SEZYLVFV4DRHVWL3MTP2FIUVA5CNFSM4HXGJCL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXRUGKI#issuecomment-501433129>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZH5SGJNTTHAOYYSODBDNDP2FIUVANCNFSM4HXGJCLQ> .

[rimrul]

If it is on the MS list, then it's not required by git to install it.

It is required to be bundled in the crt file if you configure curl to use the OpenSSL backend (which was the only backend for years and AFAIK still is the default backend).

I rather rely on the OS and browser vendor to add or remove entries from the root CA list than individual software.

Git's HTTPS communication doesn't involve browsers and may or may not involve reading windows cert store depending on curl configuration. Seeing as this certificate is listed as active in Microsofts current list I rather suspect it wasn't git that added it to the windows cert store, but Microsoft. Also isn't any browser also "individual software"?

[dscho]

Installing certificates in the windows repository is not required, as well as etc\pki\ca-trust\extracted\ openssl.
Only the file mingw64\ssl\certs\ca-bundle.crt is required

The latter is required when you clone/fetch/push via HTTPS and use the OpenSSL backend.

When using git svn via HTTPS, the former is required.

When cloning/fetching/pushing via HTTPS and using the Secure Channel backend, none of those bundles are used, but instead the Windows Certificate Store.

In short: please stop spreading misinformation @Driwars. It is okay not to know how Git for Windows works internally, just ask. Don't pretend to know and say incorrect things as if they were a fact.

Solution for me: manually remove the untrusted in my opinion CA from the mingw64\ssl\certs\ca-bundle.crt file.

Wait.

So you offered your suspicion that this is untrusted, without backing that up with anything remotely convincing, then @rimrul analyzed this properly (unlike you!) and found out when it entered Mozilla's CA bundle, and that it is still there, and you still doubt its validity?

This is curious: what on Earth makes you think that your opinion matters if you don't accept evidence to the contrary?

It should not even have needed @rimrul's excellent second analysis that the certificate is listed as active in Microsoft's current list.

If it is on the MS list, then it's not required by git to install it.

@mfriedrich74 the same thing about "don't spread misinformation" applies to you. If you don't know, just ask. Misinformation is never helpful.

The way Git for Windows works is that it uses certain libraries that then (optionally) use OpenSSL, which does not use the Windows Certificate Store (but instead Mozilla's CA bundle).

As far as git fetch/git clone/git push with https://... URLs are concerned: it depends what HTTPS backend you configured during the installation of Git for Windows. If you chose OpenSSL, you use the CA bundles that are maintained by Mozilla. If you chose the Secure Channel backend, you use the Windows Certificate Store (including all of the certificates your admin installed for you and that you have to trust implicitly because you cannot do anything about that anyway).

As soon as you use a Git command that is implemented as a Perl script, such as git svn or git send-email, your HTTPS backend choice does not matter: OpenSSL is used (and not the mingw64 version but the MSYS version, i.e. reading from /etc/ instead of /mingw64/ssl/), meaning that Mozilla's CA bundle is used.

In any case, my trust in Mozilla has been strengthened by this here ticket, as well as my trust in @rimrul's analyses (which I find super helpful, thank you so much!).

[mfriedrich74]

Hi, My implication from the reporter was that git installs a root CA into the Windows Certificate Store. Can you confirm that this is not the case?

…

On Thu, Jun 13, 2019, 4:38 AM Johannes Schindelin ***@***.***> wrote: Installing certificates in the windows repository is not required, as well as etc\pki\ca-trust\extracted\ openssl. Only the file mingw64\ssl\certs\ca-bundle.crt is required The latter is required when you clone/fetch/push via HTTPS *and use the OpenSSL backend*. When using git svn via HTTPS, the former is required. When cloning/fetching/pushing via HTTPS *and using the Secure Channel backend*, none of those bundles are used, but instead the Windows Certificate Store. In short: please stop spreading misinformation @Driwars <https://github.com/Driwars>. It is okay not to know how Git for Windows works internally, just ask. Don't pretend to know and say incorrect things as if they were a fact. Solution for me: manually remove the untrusted in my opinion CA from the mingw64\ssl\certs\ca-bundle.crt file. Wait. So you offered your suspicion that this is untrusted, without backing that up with anything remotely convincing, then @rimrul <https://github.com/rimrul> analyzed this properly (unlike you!) and found out when it entered Mozilla's CA bundle, and that it is still there, and you *still* doubt its validity? This is curious: what on Earth makes you think that your *opinion* matters if you don't accept evidence to the contrary? It should not even have needed @rimrul <https://github.com/rimrul>'s excellent *second* analysis that the certificate is listed as active in Microsoft's current list. If it is on the MS list, then it's not required by git to install it. @mfriedrich74 <https://github.com/mfriedrich74> the same thing about "don't spread misinformation" applies to you. If you don't know, just ask. Misinformation is never helpful. The way Git for Windows works is that it uses certain libraries that then (optionally) use OpenSSL, which does not use the Windows Certificate Store (but instead Mozilla's CA bundle). As far as git fetch/git clone/git push with https://... URLs are concerned: it depends what HTTPS backend you configured during the installation of Git for Windows. If you chose OpenSSL, you use the CA bundles that are maintained by Mozilla. If you chose the Secure Channel backend, you use the Windows Certificate Store (including all of the certificates your admin installed for you and that you have to trust implicitly because you cannot do anything about that anyway). As soon as you use a Git command that is implemented as a Perl script, such as git svn or git send-email, your HTTPS backend choice does not matter: OpenSSL is used (and not the mingw64 version but the MSYS version, i.e. reading from /etc/ instead of /mingw64/ssl/), meaning that Mozilla's CA bundle is used. In any case, my trust in Mozilla has been strengthened by this here ticket, as well as my trust in @rimrul <https://github.com/rimrul>'s analyses (which I find super helpful, thank you so much!). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2226?email_source=notifications&email_token=ABZH5SHGTXLTQ2XYX6NP5KTP2IBOZA5CNFSM4HXGJCL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXS6ZJY#issuecomment-501607591>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZH5SEQPDXIHSFM6YEH6SDP2IBOZANCNFSM4HXGJCLQ> .

[dscho]

@mfriedrich74 that was a misunderstanding on your part, indeed.

[dscho]

It is also set as root in windows cert storage

@mfriedrich74 ah, I think you were spooked by this.

Rest assured, I would never do anything like this. Git for Windows' job is not to install arbitrary root certificates into the system-wide Windows Certificate Store. So it will never do that.