Как я могу заставить git принимать самоподписанный сертификат?
Используя 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
22 ответа
Постоянно принимать определенный сертификат
Пытаться http.sslCAPath
или же http.sslCAInfo
, Ответ Адама Спирса дает несколько замечательных примеров. Это самое безопасное решение вопроса.
Чтобы отключить проверку TLS / SSL для одной команды git
попробуйте пройти -c
в git
с правильной переменной config, или используйте ответ Flow:
git -c http.sslVerify=false clone https://example.com/path/to/git
Чтобы отключить проверку SSL для определенного репозитория
Если хранилище полностью находится под вашим контролем, вы можете попробовать:
git config http.sslVerify false
Отключение проверки сертификата TLS(/SSL) в глобальном масштабе является крайне небезопасной практикой. Не делай этого. Не вводите указанную выше команду с --global
модификатор.
Есть довольно много вариантов конфигурации SSL в git
, Из справочной страницы 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.
Я не большой поклонник [РЕДАКТИРОВАТЬ: оригинальные версии] существующих ответов, потому что отключение проверок безопасности должно быть последним средством, а не первым предлагаемым решением. Даже если вы не можете доверять самозаверяющим сертификатам при первом получении без какого-либо дополнительного метода проверки, используйте сертификат для последующего 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
выполнение проверки через другой центр сертификации, который потенциально может быть скомпрометирован.
Глобальный.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 Credentials
- Git Credential Store
- Использование Gnome Keyring в качестве хранилища учетных данных
- Git Config http.
. * Поддерживается в Git v1.8.5
Укажите config когда git clone
-ную
Если вам нужно применить его на основе репо, документация говорит вам просто запустить 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/
Один лайнер
РЕДАКТИРОВАТЬ: см. Ответ VonC, который указывает на предостережение об абсолютных и относительных путях для конкретных версий 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)"
Тогда вам нужен ответ Stackru о том, как curl
использует NSS вместо открытого 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 все еще находится в памяти как общая библиотека
Питон, Пип и Конда
Связанный: Как добавить пользовательский корневой сертификат CA в CA Store, используемый Python в Windows?
Этот ответ взят из этой статьи, автором которой является Майкл Кауфман.
Используйте 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
Не рекомендуется устанавливать для 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.
Я постоянно сталкиваюсь с этой проблемой, поэтому написал сценарий для загрузки самозаверяющего сертификата с сервера и установки его в ~/.gitcerts, а затем обновил git-config, чтобы он указывал на эти сертификаты. Он хранится в глобальной конфигурации, поэтому вам нужно запускать его только один раз для каждого пульта.
https://github.com/iwonbigbro/tools/blob/master/bin/git-remote-install-cert.sh
Чтобы отключить проверку SSL для определенного репозитория Если репозиторий полностью находится под вашим контролем, вы можете попробовать:
git config --global http.sslVerify false
Используя 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
Проверьте настройки антивируса и брандмауэра.
От одного дня к другому, мерзавец больше не работал. Исходя из вышеизложенного, я обнаружил, что Kaspersky помещает самозаверяющий персональный корневой сертификат Антивируса посередине. Мне не удалось позволить Git принять этот сертификат, следуя инструкциям выше. Я отказался от этого. Что работает для меня, так это отключить функцию сканирования зашифрованных соединений.
- Открой Касперского
- Настройки> Дополнительно> Сеть> Не проверять зашифрованные соединения
После этого git снова работает с включенным sslVerify.
Заметка. Это все еще не удовлетворяет меня, потому что я хотел бы, чтобы эта функция моего Антивируса была активной. В расширенных настройках Kaspersky показывает список сайтов, которые не будут работать с этой функцией. Github не указан как один из них. Я проверю это на форуме Касперского. Кажется, есть некоторые темы, например, https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments
На 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!
Будьте осторожны, когда вы используете один вкладыш, используя sslKey или sslCert, как в ответе Josh Peak:
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
)
Помогает: Чарльз Бейли ( hashpling
)
(Объединено Юнио С Хамано - gitster
- в коммите 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 config --global http.sslVerify false
Примечание о option: будет обнаруживать файлы сертификатов в указанном пути к только в том случае, если команда каталогуOpenSSL c_rehash была запущена в каталоге, содержащем файлы сертификатов. Команда создаст символические ссылки для каждого сертификата, где имя ссылки является значением хеш-функции. Например:
$ cd /path/to/ssl/cert/directory
$ ls -al
total 16
drwxr-xr-x 3 user staff 96 Oct 20 13:47 .
drwxr-xr-x 4 user staff 128 Oct 20 13:46 ..
-rw-r--r-- 1 user staff 4832 Oct 20 13:47 google.pem
$ /usr/local/opt/openssl@1.1/bin/c_rehash ./
Doing ./
$ ls -al
total 16
drwxr-xr-x 4 user staff 128 Oct 20 13:58 .
drwxr-xr-x 4 user staff 128 Oct 20 13:46 ..
lrwxr-xr-x 1 user staff 10 Oct 20 13:58 f6dbf7a7.0 -> google.pem
-rw-r--r-- 1 user staff 4832 Oct 20 13:47 google.pem
Обратите внимание, что команда создала следующую символическую ссылку:
f6dbf7a7.0 -> google.pem
.
Вы также можете заменить утилиту следующей командой, хотя учтите, что следующая команда будет обрабатывать только
*.pem
файлы, а
c_rehash
утилита обработает
.pem, .crt, .cer, or .crl
файлы:
for file in *.pem; do ln -s $file `openssl x509 -hash -noout -in $file`.0; done
Если вы теперь настроите каталог, содержащий указанную выше символическую ссылку,
git
заберет файл сертификата:
# contents of /etc/gitconfig
[http]
sslCAPath = /path/to/ssl/cert/directory/
Вы также можете настроить
http.sslCAPath
с помощью переменной среды:
export GIT_SSL_CAPATH=/path/to/ssl/cert/directory/
Я использую машину 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
В моей организации мы использовали канал Windows:
- В Bitbucket настройте токен личного доступа под учетными записями.
- Временно сохраните токен в текстовом файле.
- В git bash запустите приглашение конфигурации git, чтобы настроить schannel.
git config --global http.sslBackend schannel
- Затем клонируйте свой репо.
- Windows создаст всплывающее окно с запросом вашего имени пользователя и пароля. Имя пользователя — это ваше имя пользователя в учетных записях в битбакете. Пароль — это токен, который вы временно сохранили в своем блокноте.
В файле .gitconfig вы можете добавить указанное ниже значение, чтобы сделать самоподписанный сертификат приемлемым.
sslCAInfo = /home/XXXX/abc.crt
Вы можете добавить свой самозаверяющий сертификат, прежде чем нажимать...
git config --global http.sslCAInfo "C:\Program Files\Git\usr\ssl\cert.pem"
Вы можете использовать:
git config --global http.sslbackend schannel
Это работает для меня, просто запустите следующую команду
git config --global http.sslVerify false
он откроет окно учетных данных git, в котором будут указаны ваши учетные данные. в первый раз только спрашиваю
Запустите следующую команду:
git config --global http.sslVerify false