Используя Git, есть ли способ заставить его принять самозаверяющий сертификат?
Я использую сервер https для размещения сервера git, но на данный момент сертификат самоподписан.
Когда я впервые пытаюсь создать там репо:
git push origin master -f
Я получаю ошибку:
error: Cannot access URL
https://the server/git.aspx/PocketReferences/, return code 22
fatal: git-http-push failed
git
version-control
https
self-signed
Ян Винк
источник
источник
sslcainfo
опцию. если вы можете успешно использоватьcurl --cacert
путь извлечения, но git не работает, вы должны добавить сертификат в таинственную программу OSX Keychain. больше здесь superuser.com/questions/605900/…Ответы:
Постоянно принимать определенный сертификат
Попробуйте
http.sslCAPath
илиhttp.sslCAInfo
. Ответ Адама Спирса дает несколько замечательных примеров. Это самое безопасное решение вопроса.Чтобы отключить проверку TLS / SSL для одной команды git
попробуйте перейти
-c
кgit
правильной переменной config или используйте ответ Flow :Чтобы отключить проверку SSL для определенного репозитория
Если хранилище полностью находится под вашим контролем, вы можете попробовать:
Есть довольно много вариантов конфигурации SSL в
git
. Со страницы руководстваgit config
:Несколько других полезных опций конфигурации SSL:
источник
git -c http.sslVerify=false clone https://domain.com/path/to/git
решило мою проблему, спасибо ...Вы можете установить
GIT_SSL_NO_VERIFY
наtrue
:или альтернативно настройте Git, чтобы он не проверял соединение в командной строке:
Обратите внимание, что если вы не проверяете сертификаты SSL / TLS, то вы подвержены атакам MitM .
источник
-c
флагgit
для изменения значения конфигурации для одной команды. Я думаю, что этот синтаксис чище, хотя.-c
в Git. Я на самом деле думаю, что это более чистое решение, чем загрязнение окружающей среды. :)git -c http.sslVerify=false <gitSubCommand>
также может работать через посредников.Я не большой поклонник [РЕДАКТИРОВАТЬ: оригинальные версии] существующих ответов, потому что отключение проверок безопасности должно быть последним средством, а не первым предлагаемым решением. Даже если вы не можете доверять самозаверяющим сертификатам при первом получении без какого-либо дополнительного метода проверки, использование сертификата для последующих
git
операций, по крайней мере, значительно усложняет жизнь атакам, которые происходят только после загрузки сертификата. Другими словами, если сертификат, который вы скачали, является подлинным, то с этого момента вы хороши. Напротив, если вы просто отключите проверку, то вы будете широко открыты для любой атаки «человек посередине» в любой точке .Для конкретного примера: известный
repo.or.cz
репозиторий предоставляет самозаверяющий сертификат . Я могу скачать этот файл, поместить его где-то вроде/etc/ssl/certs
, а затем сделать:Обратите внимание, что использование локального
git config
здесь (то есть без--global
) означает, что этот самозаверяющий сертификат является доверенным только для этого конкретного репозитория, что хорошо. Это также приятнее, чем использование,GIT_SSL_CAPATH
поскольку устраняет рискgit
выполнения проверки через другой центр сертификации, который потенциально может быть скомпрометирован.источник
/etc/ssl/certs/
каталоге, и это эффективно рассортировало бы все, что вам нужно.--global
Заметьте, я не проверял это, но это может позволить вам использовать целую кучу сертификатов. Стоит проверить, однако.git config http.validCertFingerprint <base64-encoded-hash-of-certifcate>
git clone --config http.sslCAInfo=<path_to_cert> https://repo.or.cz/org-mode.git
(не нужно вызывать команду 'git config' после).Git Конфигурация подписанного сертификата
ТЛ; др
Ключи конфигурации, которые вы ищете:
http.sslverify
- Всегда правда. Смотри примечание выше.Это для настройки сертификатов хоста, которым вы доверяете
http.sslCAPath
http.sslCAInfo
Они предназначены для настройки ВАШЕГО сертификата для ответа на вызовы SSL.
http.sslCert
http.sslCertPasswordProtected
Выборочно применить вышеуказанные настройки к конкретным хостам.
http.<url>.*
Global
.gitconfig
для самоподписанных центров сертификацииРади меня и моих коллег здесь показано, как нам удалось заставить самозаверяющие сертификаты работать без отключения
sslVerify
. Отредактируйте,.gitconfig
чтобы использоватьgit config --global -e
добавить эти:Ссылки:
Укажите config когда
git clone
-ingЕсли вам нужно применить его для каждого репо, в документации сказано, что вы должны просто запустить его
git config --local
в своем репо-каталоге. Ну, это бесполезно, если вы еще не клонировали репо локально, не так ли?Вы можете сделать
global -> local
hokey-pokey, установив вашу глобальную конфигурацию, как указано выше, а затем скопировать эти настройки в вашу локальную конфигурацию репо, как только она клонируется ...ИЛИ что вы можете сделать, это указать команды config,
git clone
которые будут применены к целевому репо после его клонирования.Один лайнер
РЕДАКТИРОВАТЬ: см. Ответ VonC , который указывает на предостережение об абсолютных и относительных путях для конкретных версий git от 2.14.x / 2.15 до этого одного лайнера
CentOS
unable to load client key
Если вы пытаетесь это сделать на CentOS, и ваш
.pem
файл дает вамТогда вам понадобится ответ StackOverflow о том, как
curl
использовать NSS вместо Open SSL.И вы хотите, чтобы восстановить
curl
из источника :перезагрузите компьютер, так как libcurl все еще находится в памяти как общая библиотека
Питон, Пип и Конда
Связанный : Как добавить пользовательский корневой сертификат CA в CA Store, используемый pip в Windows?
источник
http.sslCAPath
. В моем случае мне пришлось использовать,http.sslCAInfo
чтобы указать конкретный файл. Это позволило Git подключиться к нашему частному GitHub без отключения проверки SSL.Я постоянно сталкиваюсь с этой проблемой, поэтому написал сценарий для загрузки самозаверяющего сертификата с сервера и установки его в ~ / .gitcerts, а затем обновил git-config, чтобы он указывал на эти сертификаты. Он хранится в глобальном конфиге, поэтому его нужно запускать только один раз для каждого пульта.
https://github.com/iwonbigbro/tools/blob/master/bin/git-remote-install-cert.sh
источник
Этот ответ взят из этой статьи, автором которой является Майкл Кауфман.
Используйте Git для Windows с корпоративным сертификатом SSL
Выпуск :
Если у вас есть корпоративный сертификат SSL и вы хотите клонировать репозиторий из консоли или VSCode, вы получите следующую ошибку:
fatal: невозможно получить доступ к https: // myserver / tfs / DefaultCollection / _git / Proj / ': проблема с сертификатом SSL: невозможно получить сертификат локального эмитента
Решение :
Экспортируйте корневой самозаверяющий сертификат в файл. Вы можете сделать это из вашего браузера.
Найдите файл «ca-bundle.crt» в вашей папке git (текущая версия C: \ Program Files \ Git \ usr \ ssl \ certs, но она изменилась в прошлом). Скопируйте файл в свой профиль пользователя. Откройте его в текстовом редакторе, таком как VSCode, и добавьте содержимое экспортированного сертификата в конец файла.
Теперь нам нужно настроить git для использования нового файла:
git config --global http.sslCAInfo C:/Users/<yourname>/ca-bundle.crt
Это добавит следующую запись в ваш файл .gitconfig в корне вашего профиля пользователя.
[http] sslCAInfo = C:/Users/<yourname>/ca-bundle.crt
источник
Отключение проверки SSL для определенного хранилища. Если хранилище полностью находится под вашим контролем, вы можете попробовать:
источник
Будьте осторожны , когда вы используете один вкладыш с использованием sslKey или sslCert, как Джош Пик «S ответ :
Только Git 2.14.x / 2.15 (3 квартал 2015 г.) сможет интерпретировать путь как
~username/mykey
правильно (хотя он все еще может интерпретировать абсолютный путь как/path/to/privatekey
).См. Коммит 8d15496 (20 июля 2017 г.) от Junio C Hamano (
gitster
) .Помогает: Чарльз Бейли (
hashpling
) .(Слиты Junio C Hamano -
gitster
- в фиксации 17b1e1d , 11 августа 2017)источник
Используя 64-битную версию Git для Windows, просто добавьте самоподписанный сертификат CA в эти файлы:
Если это просто самозаверяющий сертификат сервера, добавьте его в
источник
Проверьте настройки антивируса и брандмауэра.
От одного дня до другого, git больше не работал. С помощью описанного выше я обнаружил, что Kaspersky помещает самоподписанный антивирусный личный корневой сертификат в середину. Мне не удалось позволить Git принять этот сертификат, следуя инструкциям выше. Я отказался от этого. Что работает для меня, так это отключить функцию сканирования зашифрованных соединений.
После этого git снова работает с включенным sslVerify.
Запись. Это все еще не удовлетворяет меня, потому что я хотел бы, чтобы эта функция моего Антивируса была активной. В расширенных настройках Kaspersky показывает список сайтов, которые не будут работать с этой функцией. Github не указан как один из них. Я проверю это на форуме Касперского. Кажется, есть некоторые темы, например, https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211
источник
В файле .gitconfig вы можете добавить указанное ниже значение, чтобы сделать самоподписанный сертификат приемлемым.
sslCAInfo = /home/XXXX/abc.crt
источник
Я делаю это так:
источник
--global
! Много уроков показывают,--global
но это очень плохая идея в целом иhttp.sslVerify
в частности. Как только у вас есть более одного клона из разных проектов, компаний, команд на компьютере, вы можете быстро столкнуться с неприятностями. Например, идентификатор пользователя и электронные письма, просачивающиеся из одного проекта в другой, могут быть довольно смущающими. А использование--global
onhttp.sslVerify
может открыть для вас все виды проблем безопасности. Итак: не используйте--global
- если вы не полностью осведомлены о побочных эффектах и не готовы пойти на риск.На Windows это работало для меня:
Добавьте содержимое вашего собственного подписанного сертификата в конец файла ca-bundle . Включая ----- НАЧАТЬ СЕРТИФИКАТ ----- и ----- КОНЕЦ СЕРТИФИКАТА ----- строки
Расположение файла ca-bundle обычно C: \ Program Files \ Git \ mingw64 \ ssl \ certs
Затем добавьте путь к файлу ca-bundle в глобальный git config. Следующая команда делает трюк:
git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt"
Примечание: Путь зависит от вашего локального пути к файлу ca-bundle!
источник
Я использую машину Windows, и эта статья помогла мне. В основном я открыл ca-bundle.crt в блокноте и добавил цепные сертификаты в него (все они). Эта проблема обычно возникает в сетях компаний, где у нас посредники сидят между системой и git-репо. Нам нужно экспортировать все сертификаты в цепочке сертификатов, кроме листового сертификата в формате base 64, добавить их все в ca-bundle.crt и затем настроить git для этого модифицированного файла crt.
источник
Не рекомендуется устанавливать http.sslVerify false. Вместо этого мы можем использовать сертификат SSL.
Таким образом, агент сборки будет использовать https с SSL-сертификатом и PAT для аутентификации.
Скопируйте содержимое файла cer, включая –begin — и –end--.
git bash on build agent => git config –global http.sslcainfo «C: / Program Files / Git / mingw64 / ssl / certs / ca-bundle.crt» Перейдите к этому файлу и добавьте содержимое .cer.
Таким образом, агент сборки может получить доступ к SSL-сертификату.
источник
Мой ответ может быть поздно, но это сработало для меня. Это может кому-то помочь.
Я попробовал вышеупомянутые шаги, и это не решило проблему.
попробуй это
git config --global http.sslVerify false
источник