Використовуючи 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

Постійно прийняти певний сертифікат

Спробуйте http.sslCAPathабо http.sslCAInfo. Відповідь Адама Шпієра дає чудові приклади. Це найбільш безпечне рішення питання.

Щоб вимкнути перевірку TLS / SSL для однієї команди git

спробуйте перейти -cдо gitвідповідної змінної config або скористайтеся відповіддю потоку :

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

Щоб вимкнути перевірку SSL для конкретного сховища

Якщо сховище повністю під вашим контролем, ви можете спробувати:

git config --global http.sslVerify false

Існує досить багато варіантів конфігурації 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 .

Я не є великим прихильником існуючих відповідей [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зробити перевірку через інший орган сертифікації, який може бути порушений.

Конфігурація сертифікату самопідписання Git

тл; д-р

НІКОЛИ не вимикайте всю перевірку 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 Cententials
• Магазин довіри Git
• Використання Gnome Keyring в якості сховища даних
• Git Config http. <url>. * Підтримується з Git v1.8.5

Вкажіть конфігурацію при git clone-ing

Якщо вам потрібно застосувати його за принципом репо, документація пропонує вам просто запуститись git config --localу каталог репо. Ну, це не корисно, коли у вас ще не було клопотано репо на локальному рівні, чи не так?

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

АБО що ви можете зробити - це вказати команди конфігурації,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 «s відповідь , що точки з застереження про абсолютних і відносних шляхах для конкретних версій 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 все ще зберігається в пам'яті як спільна бібліотека

Пітон, піп і конда

Пов'язане : Як додати спеціальний сертифікат Root CA до магазину CA, який використовується pip в Windows?

Я постійно стикаюся з цією проблемою, тому написав сценарій для завантаження самопідписаного сертифіката з сервера та встановлення його до ~ / .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: неможливо отримати сертифікат локального емітента

Рішення :

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

Відключення перевірки SSL для конкретного сховища Якщо сховище повністю під вашим контролем, ви можете спробувати:

 git config --global http.sslVerify false

Будьте обережні , коли ви використовуєте один вкладиш з використанням sslKey або sslCert, як Джош Пік «S відповідь :

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 (Q3 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також, усвідомлюючи умовність, оскільки вони обидва чітко називають імена до файлів.

Використовуючи 64-бітну версію Git для Windows, просто додайте до цих файлів самопідписаний сертифікат CA:

• C: \ програмні файли \ Git \ mingw64 \ ssl \ certs \ ca-bundle.crt
• C: \ програмні файли \ Git \ mingw64 \ ssl \ certs \ ca-bundle.trust.crt

Якщо це лише сертифікат, який підписав сам сервер, додайте його

• C: \ Програмні файли \ Git \ mingw64 \ ssl \ cert.pem

Перевірте налаштування антивірусу та брандмауера.

З одного дня на інший, git більше не працював. З урахуванням описаного вище я виявив, що Касперський в середину ставить самопідписаний антивірусний особистий кореневий сертифікат. Мені не вдалося дозволити Git прийняти цей сертифікат, дотримуючись вищезазначених інструкцій. Я відмовився від цього. Що для мене працює - відключити функцію Сканування зашифрованих з'єднань.

1. Відкрийте Касперського
2. Установки> Додаткові> Мережа> Не сканувати зашифровані з'єднання

Після цього git знову працює з включеним sslVerify.

Примітка. Це все ще не задовольняє мене, тому що я хотів би, щоб ця особливість мого антивіруса була активною. У розширених налаштуваннях Касперський показує список веб-сайтів, які не працюватимуть із цією функцією. Гітхуб не вказаний як один із них. Я перевірю це на форумі Касперського. Здається, є деякі теми, наприклад, https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211

У файл .gitconfig ви можете додати наведене нижче значення, щоб зробити cert самопідписаним прийнятним

sslCAInfo = /home/XXXX/abc.crt

Я роблю це так:

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

У Windows це працювало для мене:

Додайте вміст свого самопідписаного сертифіката в кінець файлу ca-bundle . У тому числі ----- ПОЧАТОК СЕРТИФІКАТ ----- та ----- ЗАКОННИЙ СЕРТИФІКАТ ----- рядки

Розташування файлу 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!

Недорога практика встановлювати http.sslПідтвердити хибність. Натомість ми можемо використовувати сертифікат SSL.

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

Скопіюйте вміст файлу cer, включаючи –початок —і –кінчення--.

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

Я використовую машину Windows, і ця стаття допомогла мені. В основному я відкрив ca-bundle.crt в блокноті і додав до нього сертифікати ланцюга (усі вони). Ця проблема зазвичай трапляється в мережах компаній, де серед представників системи та git repo є середні чоловіки. Нам потрібно експортувати всі серти в ланцюг cert, за винятком листа cert у форматі base 64 та додати їх до ca-bundle.crt, а потім налаштувати git для цього зміненого файлу crt.