Чтобы навсегда принять конкретный сертификат

Попробуйте http.sslCAPath или http.sslCAInfo. Ответ Адама Спирса дает несколько отличных примеров. Это наиболее безопасное решение вопроса.

Чтобы отключить проверку TLS / SSL для одной команды git

попробуйте передать -c в git с соответствующей переменной конфигурации или используйте ответ Flow:

git -c http.sslVerify=false clone https://example.com/path/to/git

Чтобы отключить проверку SSL для определенного репозитория

Если репозиторий полностью находится под вашим контролем, вы можете попробовать:

git config --global http.sslVerify false

В git есть довольно много параметров конфигурации SSL. На странице руководства git config:

http.sslVerify
    Whether to verify the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_NO_VERIFY environment variable.

http.sslCAInfo
    File containing the certificates to verify the peer with when fetching or pushing
    over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable.

http.sslCAPath
    Path containing files with the CA certificates to verify the peer with when
    fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CAPATH environment variable.

Еще несколько полезных параметров конфигурации SSL:

http.sslCert
    File containing the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CERT environment variable.

http.sslKey
    File containing the SSL private key when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_KEY environment variable.

http.sslCertPasswordProtected
    Enable git's password prompt for the SSL certificate. Otherwise OpenSSL will
    prompt the user, possibly many times, if the certificate or private key is encrypted.
    Can be overridden by the GIT_SSL_CERT_PASSWORD_PROTECTED environment variable.

Вы можете установить GIT_SSL_NO_VERIFY на true:

GIT_SSL_NO_VERIFY=true git clone https://example.com/path/to/git

или, в качестве альтернативы, настройте Git, чтобы не проверять соединение в командной строке:

git -c http.sslVerify=false clone https://example.com/path/to/git

Обратите внимание: если вы не проверяете сертификаты SSL / TLS, то вы уязвимы для атак MitM.

Я не большой поклонник [EDIT: исходные версии] существующих ответов, потому что отключение проверок безопасности должно быть крайней мерой, а не первым предложенным решением. Даже если вы не можете доверять самозаверяющим сертификатам при первом получении без дополнительных методов проверки, использование сертификата для последующих git операций, по крайней мере, значительно усложняет жизнь атакам, которые происходят только после загрузки сертификат. Другими словами, если сертификат, который вы скачали, является подлинным, с этого момента все в порядке. Напротив, если вы просто отключите проверку, вы будете широко открыты для любого вида атак «злоумышленник посередине» в любой момент.

В качестве конкретного примера: знаменитый репозиторий repo.or.cz предоставляет самозаверяющий сертификат. Я могу скачать этот файл, поместить его где-нибудь, например, /etc/ssl/certs, а затем сделать:

# Initial clone
GIT_SSL_CAINFO=/etc/ssl/certs/rorcz_root_cert.pem \
    git clone https://repo.or.cz/org-mode.git

# Ensure all future interactions with origin remote also work
cd org-mode
git config http.sslCAInfo /etc/ssl/certs/rorcz_root_cert.pem

Обратите внимание, что использование здесь local git config (т.е. без --global) означает, что этому самозаверяющему сертификату доверяют только для этого конкретного репозитория, что приятно. Это также лучше, чем использование GIT_SSL_CAPATH, поскольку исключает риск git выполнения проверки через другой центр сертификации, который потенциально может быть скомпрометирован.

Конфигурация самозаверяющего сертификата Git

tl;dr

НИКОГДА не отключайте все проверки SSL!

Это создает плохую культуру безопасности. Не будь таким человеком.

Ключи конфигурации, которые вам нужны:

• http.sslverify - всегда верно. См. Примечание выше.

Они предназначены для настройки сертификатов хоста, которым вы доверяете.

• http.sslCAPath
• http.sslCAInfo

Они предназначены для настройки ВАШЕГО сертификата для ответа на запросы SSL.

• http.sslCert
• http.sslCertPasswordProtected

Выборочно примените указанные выше настройки к определенным хостам.

• http.<url>.*

Глобальный .gitconfig для самозаверяющих центров сертификации

Ради меня и моих коллег вот как нам удалось заставить работать самозаверяющие сертификаты, не отключая sslVerify. Измените свой .gitconfig, используя git config --global -e, добавьте следующее:

# Specify the scheme and host as a 'context' that only these settings apply
# Must use Git v1.8.5+ for these contexts to work
[credential "https://your.domain.com"]
  username = user.name

  # Uncomment the credential helper that applies to your platform
  # Windows
  # helper = manager

  # OSX
  # helper = osxkeychain

  # Linux (in-memory credential helper)
  # helper = cache

  # Linux (permanent storage credential helper)
  # https://askubuntu.com/a/776335/491772

# Specify the scheme and host as a 'context' that only these settings apply 
# Must use Git v1.8.5+ for these contexts to work
[http "https://your.domain.com"]
  ##################################
  # Self Signed Server Certificate #
  ##################################

  # MUST be PEM format
  # Some situations require both the CAPath AND CAInfo 
  sslCAInfo = /path/to/selfCA/self-signed-certificate.crt
  sslCAPath = /path/to/selfCA/
  sslVerify = true

  ###########################################
  # Private Key and Certificate information #
  ###########################################

  # Must be PEM format and include BEGIN CERTIFICATE / END CERTIFICATE, 
  # not just the BEGIN PRIVATE KEY / END PRIVATE KEY for Git to recognise it.
  sslCert = /path/to/privatekey/myprivatecert.pem

  # Even if your PEM file is password protected, set this to false.
  # Setting this to true always asks for a password even if you don't have one.
  # When you do have a password, even with this set to false it will prompt anyhow. 
  sslCertPasswordProtected = 0

Использованная литература:

• Учетные данные Git
• Git Credential Store
• Использование Gnome Keyring в качестве хранилища учетных данных
• https://git-scm.com/docs/git-config/2.12.2#git-config-httplturlgt

Укажите конфигурацию при git clone-ing

Если вам нужно применить его для каждого репо, документация говорит вам просто запустить git config --local в вашем каталоге репо. Что ж, это бесполезно, если вы еще не клонировали репо локально, не так ли?

Вы можете выполнить global -> local hokey-pokey, установив глобальную конфигурацию, как указано выше, а затем скопировать эти настройки в конфигурацию локального репо после ее клонирования ...

ИЛИ вы можете указать команды конфигурации в git clone которые применяются к целевому репо после его клонирования.

# Declare variables to make clone command less verbose     
OUR_CA_PATH=/path/to/selfCA/
OUR_CA_FILE=$OUR_CA_PATH/self-signed-certificate.crt
MY_PEM_FILE=/path/to/privatekey/myprivatecert.pem
SELF_SIGN_CONFIG="-c http.sslCAPath=$OUR_CA_PATH -c http.sslCAInfo=$OUR_CA_FILE -c http.sslVerify=1 -c http.sslCert=$MY_PEM_FILE -c http.sslCertPasswordProtected=0"

# With this environment variable defined it makes subsequent clones easier if you need to pull down multiple repos.
git clone $SELF_SIGN_CONFIG https://mygit.server.com/projects/myproject.git myproject/

Один лайнер

EDIT: см. VonC answer, который указывает на предостережение об абсолютных и относительных путях для конкретных версий git от 2.14.x / 2.15 до этого одного лайнера

git clone -c http.sslCAPath="/path/to/selfCA" -c http.sslCAInfo="/path/to/selfCA/self-signed-certificate.crt" -c http.sslVerify=1 -c http.sslCert="/path/to/privatekey/myprivatecert.pem" -c http.sslCertPasswordProtected=0 https://mygit.server.com/projects/myproject.git myproject/

CentOS unable to load client key

Если вы пытаетесь это сделать в CentOS, и ваш .pem файл дает вам

unable to load client key: "-8178 (SEC_ERROR_BAD_KEY)"

Тогда вам понадобится этот ответ StackOverflow о том, как curl использует NSS вместо Open SSL.

И вам захочется перестроить curl из исходного кода:

git clone http://github.com/curl/curl.git curl/
cd curl/
# Need these for ./buildconf
yum install autoconf automake libtool m4 nroff perl -y
#Need these for ./configure
yum install openssl-devel openldap-devel libssh2-devel -y

./buildconf
su # Switch to super user to install into /usr/bin/curl
./configure --with-openssl --with-ldap --with-libssh2 --prefix=/usr/
make
make install

перезагрузите компьютер, поскольку libcurl все еще находится в памяти как общая библиотека

Python, pip и conda

По теме: Как добавить настраиваемый корневой сертификат CA в хранилище CA, используемое pip в Windows?

Этот ответ взят из эта статья написана Майклом Кауфманом.

Используйте Git для Windows с корпоративным SSL-сертификатом

Проблема:

Если у вас есть корпоративный SSL-сертификат и вы хотите клонировать репо с консоли или VSCode, вы получите следующую ошибку:

фатальный: невозможно получить доступ к 'https://myserver/tfs/DefaultCollection/_git/Proj/ ': проблема с сертификатом SSL: невозможно получить сертификат местного эмитента

Решение:

1. Экспортируйте корневой самоподписанный сертификат в файл. Вы можете сделать это в своем браузере.

2. Найдите файл «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

Я постоянно сталкиваюсь с этой проблемой, поэтому написал сценарий для загрузки самоподписанного сертификата с сервера и установки его в ~ / .gitcerts, а затем обновите git-config, чтобы он указывал на эти сертификаты. Он хранится в глобальной конфигурации, поэтому вам нужно запускать его только один раз для каждого пульта.

https://github.com/iwonbigbro/tools/blob/master/bin/git-remote-install-cert.sh

Чтобы отключить проверку SSL для определенного репозитория Если репозиторий полностью находится под вашим контролем, вы можете попробовать:

 git config --global http.sslVerify false

Не рекомендуется устанавливать для http.sslVerify значение false. Вместо этого мы можем использовать сертификат SSL.

Таким образом, агент сборки будет использовать https с сертификатом SSL и PAT для аутентификации.

Скопируйте содержимое файла cer, включая –begin– и –end--.

git bash в агенте сборки => git config –global http.sslcainfo «C: / Program Files / Git / mingw64 / ssl / certs / ca-bundle.crt» Перейдите в этот файл и добавьте содержимое .cer.

Таким образом, агент сборки может получить доступ к сертификату SSL.

Используя 64-битную версию Git в Windows, просто добавьте самоподписанный сертификат CA в эти файлы:

• C: \ Program Files \ Git \ mingw64 \ ssl \ certs \ ca-bundle.crt
• C: \ Program Files \ Git \ mingw64 \ ssl \ certs \ ca-bundle.trust.crt

Если это просто самоподписанный сертификат сервера, добавьте его в

• C: \ Program Files \ Git \ mingw64 \ ssl \ cert.pem

Будьте осторожны при использовании одного лайнера с sslKey или sslCert, как в Джоша Пика https://stackoverflow.com/a/41253757/6309">answer:

git clone -c http.sslCAPath="/path/to/selfCA" \
  -c http.sslCAInfo="/path/to/selfCA/self-signed-certificate.crt" \
  -c http.sslVerify=1 \
  -c http.sslCert="/path/to/privatekey/myprivatecert.pem" \
  -c http.sslCertPasswordProtected=0 \
https://mygit.server.com/projects/myproject.git myproject

Только Git 2.14.x / 2.15 (3 квартал 2015 г.) сможет правильно интерпретировать путь типа ~username/mykey (хотя он все еще может интерпретировать абсолютный путь, например /path/to/privatekey).

См. фиксацию 8d15496 (20 июля 2017 г.) от Junio ​​C Hamano (gitster).
При поддержке: Charles Bailey (hashpling).
^{(Объединено Junio ​​C Hamano - gitster - в commit 17b1e1d, 11 августа 2017 г.)}

http.c: http.sslcert и http.sslkey - оба пути

Назад, когда был создан современный путь кода http_options () для анализа различных параметров http. * На 29508e1 («Изолировать общую функциональность HTTP-запроса», 2005-11-18, Git 0.99.9k), а затем было исправлено взаимодействие между несколькими файлами конфигурации в 7059cd9 (" http_init(): Исправить синтаксический анализ файла конфигурации ", 2009-03-09, Git 1.6.3-rc0), мы проанализировали переменные конфигурации, такие как http.sslkey, http.sslcert как простые ванильные строки, потому что git_config_pathname(), который понимает префикс "~[username]/", не существует.

Позже мы преобразовали некоторые из них (а именно, http.sslCAPath и http.sslCAInfo) для использования функции и добавили переменные, такие как http.cookeyFile http.pinnedpubkey, чтобы использовать функцию с самого начала. Из-за этого все эти переменные понимают префикс «~[username]/».

Сделайте оставшиеся две переменные, http.sslcert и http.sslkey, также осведомленными о соглашении, так как они обе явно являются путями к файлам.

Проверьте настройки антивируса и брандмауэра.

Изо дня в день git больше не работал. С помощью того, что описано выше, я обнаружил, что Касперский помещает самоподписанный личный корневой сертификат Антивируса посередине. Мне не удалось разрешить Git принять этот сертификат, следуя приведенным выше инструкциям. Я отказался от этого. Что мне подходит, так это отключение функции сканирования зашифрованных соединений.

1. Откройте Kaspersky
2. Настройки> Дополнительно> Сеть> Не сканировать зашифрованные соединения

После этого git снова работает с включенным sslVerify.

Примечание. Меня это все еще не устраивает, потому что я хотел бы, чтобы эта функция моего Антивируса была активной. В расширенных настройках Kaspersky показывает список веб-сайтов, которые не будут работать с этой функцией. Github не входит в их число. Проверю на форуме Касперского. Кажется, есть несколько тем, например https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211.

Возможно, я запоздал с ответом, но у меня это сработало. Это может кому-то помочь.

Я попробовал указанные выше шаги, но это не устранило проблему.

попробуйте этоgit config --global http.sslVerify false

В Windows это сработало для меня:

Добавьте содержимое своего самозаверяющего сертификата в конец файла ca-bundle. Включая строки ----- BEGIN CERTIFICATE ----- и ----- END CERTIFICATE -----

Расположение файла ca-bundle обычно: C: \ Program Files \ Git \ mingw64 \ ssl \ certs.

После этого добавьте путь к файлу ca-bundle в глобальную конфигурацию git. Следующая команда делает свое дело: git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt"

Примечание: Путь зависит от вашего локального пути к файлу ca-bundle!

В файле .gitconfig вы можете добавить указанное ниже значение, чтобы сделать самоподписанный сертификат приемлемым.

sslCAInfo = /home/XXXX/abc.crt

Я использую компьютер с Windows и эту статью мне помогли. По сути, я открыл ca-bundle.crt в блокноте и добавил в него сертификаты цепочки (все). Эта проблема обычно возникает в корпоративных сетях, где у нас есть посредники, сидящие между системой и репозиторием git. Нам нужно экспортировать все сертификаты в цепочке сертификатов, кроме конечного сертификата в формате base 64, и добавить их все в ca-bundle.crt, а затем настроить git для этого измененного файла crt.

Я так делаю:

git init
git config --global http.sslVerify false
git clone https://myurl/myrepo.git

Это работает для меня, просто запустите следующую команду

git config --global http.sslVerify false

он откроет окно учетных данных git, в котором будут указаны ваши учетные данные. в первый раз только спрашиваю