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

Изо дня в день 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.

Будьте осторожны при использовании одного лайнера с sslKey или sslCert, как в Джоша Пика https://my-sertif.ru/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 квартал 2021 г.) сможет правильно интерпретировать такой путь, как ~username/mykey (хотя он все еще может интерпретировать абсолютный путь, например /path/to/privatekey).

См. фиксацию 8d15496 (20 июля 2021 г.) от Junio ​​C Hamano (gitster).
Помощник: Чарльз Бейли (hashpling).
^{(объединено Junio ​​C Hamano – gitster – в commit 17b1e1d, 11 августа 2021 г.}

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

Когда был создан современный кодовый путь http_options () для синтаксического анализа различные параметры http. * на странице 29508e1 («Изолировать общий HTTP-запрос функциональность », 18.11.2005, Git 0.99.9k), а затем были исправлены для взаимодействие между несколькими файлами конфигурации в 7059cd9 (“http_init(): Fix config file parsing”, 2009-03-09, Git 1.6.3-rc0), мы проанализировали переменные конфигурации, такие как http.sslkey, http.sslcert как простые ванильные строки, потому что git_config_pathname() понимает Префикса “~[username]/” не существует.

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

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

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

Тл ; др

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

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

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

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

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

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

Глобальный .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 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/

Один лайнер

РЕДАКТИРОВАТЬ: см. VonCanswer, который указывает на предостережение об абсолютных и относительных путях для конкретных версий 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?

Я не большой поклонник [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

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