Question

После последнего обновления (фактически, я сделал новую установку) 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]" https_proxy="https://garbage" 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]" https_proxy="" 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 * Uses proxy env variable no_proxy == '[repo host FQDN]' * 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 connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: [... certificate details incl. past expiration date; successful communication]

VonC · Answer 1 · 25 января 2019

Сначала попробуйте и получите доступ к своему репо в сеансе CMD, где вы установили упрощенный PATH , используя portable Git для Windows (PortableGit-2.20.1-64-bit.7z.exe), без сжатия в C:\Git:

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH%

Затем попробуйте получить доступ к вашему репо в этом сеансе.

Редактор ОП, Питер: Сработал тест с незагроможденной средой. Разница заключается в том, что переменные среды https_proxy и HTTPS_PROXY, которые оба должны быть не установлены. ¹ Это верно, даже если сервер указан в переменной среды no_proxy, которая обычно указывает программам не использовать прокси для определенных серверов, указанных в значении переменной. К счастью, сервер репо находится в локальной сети. ²

Мне неясно, виноват ли здесь настоящий git, cURL или openssl; Я полагаю, что переменные оцениваются как самим git, так и сетевыми библиотеками.

<ч /> _{¹ Я думаю, что по историческим причинам переменная существует в верхнем и нижнем регистре.}

² Насколько я могу судить, проблема не в прокси-сервере, поскольку сертификат сервера репо получен и правильно признан самосертифицированным.

git 2.20.1.windows.1 не поддерживает http.sslverify = false

Пожалуйста, войдите или зарегистрируйтесь чтобы ответить на этот вопрос.

1 Ответ

Пожалуйста, войдите или зарегистрируйтесь что бы добавить комментарий.

git 2.20.1.windows.1 не поддерживает http.sslverify = false

Пожалуйста, войдите или зарегистрируйтесь чтобы ответить на этот вопрос.

1 Ответ

Пожалуйста, войдите или зарегистрируйтесь что бы добавить комментарий.

Похожие темы