последнего обновления (фактически, я сделал новую установку) git для Windows я больше не могу подключиться к определенному удаленному хранилищу через https. Это на внутреннем сервере, который используетсамоподписанный сертификат, срок действия которого также истек (не спрашивай).

Раньше он работал с git для Windows 2.16.x (iirc) и продолжает работать с параллельными установками в cygwin и mysys2 (которые сообщают о версиях 2.17.0 и 2.20.1 соответственно).

Вот что я попробовал (не все одновременно):

Я установил опцию конфигурацииhttp.sslverify=false во всех местах, сообщенныхgit config -l --show-origin и проверил, что sslverify нигде не соответствует действительности. В частности, в .git / config локального репозитория, который должен переопределять любые стандартные или явные системные или глобальные настройки, это неверно.

Я изменилhttp.sslbackend возможностьsChannel а затем вернуться кopenssl; сообщение об ошибке изменится, указывая, что настройка действовала, но это все еще сообщение об ошибке. Есть сообщения, указывающие, что более новыйsChannel Механизм не может быть полностью защищен от проверки сертификатов, поэтому я хотел убедиться, что я не случайно все еще использую его. (Это механизм по умолчанию в новой установке, по-видимому.)

Я также скачал сертификат и дал указание openssl использовать его, отредактировав~/.ssl/config; к сожалению, это просто приводит к тому, что git (или, скорее, openssl) отклоняет сертификат на том основании, что срок его действия истек.

Я установил для переменной среды GIT_SSL_NO_VERIFY значение «true», которое должно переопределить все параметры конфигурации.

Я использовал переменные средыGIT_TRACE_CURL=path, GIT_TRACE а такжеGIT_CURL_VERBOSE получить выходные данные отладки, которые не показали ничего удивительного, кроме того, что openssl попытался проверить сертификат и потерпел неудачу, что является правильным, если он вообще пытается его проверить. Например. файл трассировки будет содержать строкуInfo: SSL certificate problem: self signed certificate что является правильным.

Другие установки git (соответственно openssl), похоже, пропускают всю проверку сертификата, хотя это то, что нам нужно в данных обстоятельствах.

Это ошибка? Есть идеи?

Изменить: проблема связана с настройками прокси https. В моей среде я нахожусь за HTTPS-прокси, но сервер репо должен быть доступен напрямую. У меня для этого установлены переменные https_proxy и no_proxy. Чтобы исключить все остальные настройки среды, я использовалenv -i (который запускает программу без заданной переменной окружения eny) с двумя различными настройками. Обратите внимание, что я сохранил свой первоначальный путь, в котором сначала находятся каталоги установки git. Единственное отличие состоит в том, что в вызывающем сбой вызове, который идет первым, https_proxy устанавливается на строку, начинающуюся с «https: //» (garbage часть буквально проясняет, что это не допустимый хост):

Настройки ssl

git config -l |grep -i ssl
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslbackend=openssl

env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" <strong>https_proxy="https://garbage"</strong> git fetch 16:41:53.953829 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin 16:41:53.955829 git.c:418 trace: built-in: git fetch 16:41:53.980831 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow noreferrer">https://[FQDN/path-to-git]</a> 16:41:54.001834 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core 16:41:54.003834 git.c:675 trace: exec: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow noreferrer">https://[FQDN/path-to-git]</a> 16:41:54.003834 run-command.c:643 trace: run_command: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow noreferrer">https://[FQDN/path-to-git]</a> 16:41:54.028836 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core * Couldn't find host [repo host FQDN] in the _netrc file; using defaults * Trying [repo host IP address]... * TCP_NODELAY set * Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt CApath: none * SSL certificate problem: self signed certificate * Closing connection 0 fatal: unable to access '<a href="https://[FQDN/path-to-git]" rel="nofollow noreferrer">https://[FQDN/path-to-git]</a>': SSL certificate problem: self signed certificate

Команда работает, еслиhttps_proxy переменная не начинается сhttps://, Бревна практически идентичны до линииCApath: noneза исключением того, что есть строка, где curl подтверждаетno_proxy установка.

env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" <strong>https_proxy=""</strong> git fetch 17:04:56.884616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin 17:04:56.886616 git.c:418 trace: built-in: git fetch 17:04:56.911616 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow noreferrer">https://[FQDN/path-to-git]</a> 17:04:56.931616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core 17:04:56.932616 git.c:675 trace: exec: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow noreferrer">https://[FQDN/path-to-git]</a> 17:04:56.932616 run-command.c:643 trace: run_command: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow noreferrer">https://[FQDN/path-to-git]</a> 17:04:56.957616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core * <strong>Uses proxy env variable no_proxy == '[repo host FQDN]'</strong> * Couldn't find host [repo host FQDN] in the _netrc file; using defaults * Trying [repo host IP address]... * TCP_NODELAY set * Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt CApath: none * <strong>SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384</strong> * ALPN, server accepted to use http/1.1 * Server certificate: [... certificate details incl. past expiration date; successful communication]