Korzystając z Git, czy istnieje sposób, aby nakazać mu zaakceptowanie certyfikatu z podpisem własnym?

Używam serwera https do hostowania serwera git, ale na razie certyfikat jest samopodpisany.

Kiedy próbuję utworzyć tam repozytorium:

git push origin master -f

Dostaję błąd:

error: Cannot access URL     
https://the server/git.aspx/PocketReferences/, return code 22

fatal: git-http-push failed

Aby na stałe zaakceptować określony certyfikat

Spróbuj http.sslCAPathlub http.sslCAInfo. Odpowiedź Adama Spiersa zawiera kilka świetnych przykładów. To jest najbezpieczniejsze rozwiązanie tego pytania.

Aby wyłączyć weryfikację TLS / SSL dla pojedynczego polecenia git

spróbuj przechodząc -cdo gitz właściwego zmiennej konfiguracji lub użyj odpowiedź Flow :

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

Aby wyłączyć weryfikację SSL dla określonego repozytorium

Jeśli repozytorium jest całkowicie pod twoją kontrolą, możesz spróbować:

git config --global http.sslVerify false

Istnieje wiele opcji konfiguracji SSL git. Ze strony podręcznika użytkownika 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.

Kilka innych przydatnych opcji konfiguracji 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.

Można ustawić GIT_SSL_NO_VERIFYna true:

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

lub alternatywnie skonfiguruj Git, aby nie weryfikował połączenia w wierszu poleceń:

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

Pamiętaj, że jeśli nie zweryfikujesz certyfikatów SSL / TLS, jesteś podatny na ataki MitM .

Nie jestem wielkim fanem [EDYTOWANIA: oryginalnych wersji] istniejących odpowiedzi, ponieważ wyłączenie kontroli bezpieczeństwa powinno być ostatecznością, a nie pierwszym oferowanym rozwiązaniem. Mimo że nie można ufać samopodpisanym certyfikatom przy pierwszym otrzymaniu bez dodatkowej metody weryfikacji, użycie certyfikatu do kolejnych gitoperacji przynajmniej utrudnia życie w przypadku ataków, które pojawiają się dopiero po pobraniu certyfikatu. Innymi słowy, jeśli pobrany certyfikat jest autentyczny, od tego momentu jesteś dobry. Przeciwnie, jeśli po prostu wyłączysz weryfikację, jesteś otwarty na każdy rodzaj ataku typu man-in-the-middle w dowolnym momencie .

Podając konkretny przykład: słynne repo.or.czrepozytorium zapewnia samopodpisany certyfikat . Mogę pobrać ten plik, umieścić go gdzieś jak /etc/ssl/certs, a następnie zrobić:

# 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

Zauważ, że użycie lokalnego git configtutaj (tj. Bez --global) oznacza, że ​​ten samopodpisany certyfikat jest zaufany tylko dla tego konkretnego repozytorium, co jest miłe. Jest to również przyjemniejsze niż używanie, GIT_SSL_CAPATHponieważ eliminuje ryzyko gitprzeprowadzenia weryfikacji za pośrednictwem innego urzędu certyfikacji, co może być potencjalnie zagrożone.

Konfiguracja certyfikatu z podpisem własnym Git

tl; dr

NIGDY nie wyłączaj całej weryfikacji SSL!

Stwarza to złą kulturę bezpieczeństwa. Nie bądź tą osobą.

Klucze konfiguracji, których szukasz:

• http.sslverify- Zawsze prawda. Zobacz powyższą notatkę.

Służą one do konfigurowania zaufanych certyfikatów hosta

• http.sslCAPath
• http.sslCAInfo

Służą one do konfigurowania TWOJEGO certyfikatu, aby odpowiadał na wyzwania związane z SSL.

• http.sslCert
• http.sslCertPasswordProtected

Selektywnie zastosuj powyższe ustawienia do określonych hostów.

• http.<url>.*

Globalny .gitconfigdla urzędów certyfikacji z podpisem własnym

Dla mnie i moich kolegów tutaj jest to, jak udało nam się uzyskać samopodpisane certyfikaty do działania bez wyłączania sslVerify. Edytuj swoje.gitconfig za pomocą git config --global -edodaj te:

# 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

Bibliografia:

• Poświadczenia Git
• Git Credential Store
• Używanie Gnome Keyring jako magazynu danych logowania
• Git Config http. <url>. * Obsługiwane z Git v1.8.5

Określić konfigurację podczas git cloneuruchamiania

Jeśli musisz zastosować go na zasadzie repo, dokumentacja mówi, aby po prostu uruchomić się git config --localw katalogu repo. Cóż, to nie jest przydatne, gdy repo nie zostało jeszcze sklonowane lokalnie, prawda?

Możesz wykonać global -> localhokey-pokey, ustawiając globalną konfigurację jak wyżej, a następnie skopiuj te ustawienia do lokalnej konfiguracji repo po sklonowaniu ...

LUB to, co możesz zrobić, to określić komendy configgit clone zastosowane do docelowego repozytorium po sklonowaniu.

# 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/

Jedna wkładka

EDIT: Zobacz VonC jest odpowiedź , która wskazuje na zastrzeżenie o bezwzględnych i względnych ścieżek dla konkretnych wersji git z 2.14.x / 2,15 do tej jednej wkładki

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

Jeśli próbujesz tego na CentOS, a Twój .pemplik Ci to daje

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

Następnie będziesz potrzebować odpowiedzi StackOverflow o tym, jak curlużywa NSS zamiast Open SSL.

I będziesz chciał przebudować curlze źródła :

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

uruchom ponownie komputer, ponieważ libcurl jest nadal w pamięci jako biblioteka współdzielona

Python, pip i conda

Powiązane : Jak dodać niestandardowy certyfikat główny urzędu certyfikacji do sklepu CA Store używanego przez pip w systemie Windows?

Wciąż napotykam ten problem, więc napisałem skrypt, aby pobrać samopodpisany certyfikat z serwera i zainstalować go w ~ / .gitcerts, a następnie zaktualizować git-config, aby wskazywał na te certyfikaty. Jest przechowywany w konfiguracji globalnej, więc wystarczy uruchomić go tylko raz na pilota.

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

Ta odpowiedź została zaczerpnięta z tego artykułu autorstwa Michaela Kauffmana.

Użyj Git dla Windows z korporacyjnym certyfikatem SSL

Problem :

Jeśli masz korporacyjny certyfikat SSL i chcesz sklonować swoje repozytorium z konsoli lub VSCode, pojawia się następujący błąd:

krytyczny: nie można uzyskać dostępu do „ https: // mój serwer / tfs / DefaultCollection / _git / Proj / ”: problem z certyfikatem SSL: nie można uzyskać lokalnego certyfikatu wystawcy

Rozwiązanie :

1. Wyeksportuj główny samopodpisany certyfikat do pliku. Możesz to zrobić z poziomu przeglądarki.

2. Znajdź plik „ca-bundle.crt” w folderze git (aktualna wersja C: \ Program Files \ Git \ usr \ ssl \ certs, ale w przeszłości była zmieniana). Skopiuj plik do swojego profilu użytkownika. Otwórz go za pomocą edytora tekstu, takiego jak VSCode, i dodaj treść wyeksportowanego certyfikatu na końcu pliku.

Teraz musimy skonfigurować git, aby używał nowego pliku:

git config --global http.sslCAInfo C:/Users/<yourname>/ca-bundle.crt

Spowoduje to dodanie następującego wpisu do pliku .gitconfig w katalogu głównym profilu użytkownika.

[http] sslCAInfo = C:/Users/<yourname>/ca-bundle.crt

Aby wyłączyć weryfikację SSL dla określonego repozytorium Jeśli repozytorium jest całkowicie pod twoją kontrolą, możesz spróbować:

 git config --global http.sslVerify false

Bądź ostrożny, gdy używasz jednej liniowej używając sslKey lub sslCert, jak w Josh pik „s odpowiedź :

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

Tylko Git 2.14.x / 2.15 (III kwartał 2015) byłby w stanie ~username/mykeypoprawnie zinterpretować ścieżkę (podczas gdy nadal może interpretować ścieżkę bezwzględną jak /path/to/privatekey).

Zobacz zatwierdzenie 8d15496 (20 lipca 2017 r.) Przez Junio ​​C. Hamano ( gitster) .
Pomocnik: Charles Bailey ( hashpling) .
^{(Połączone przez Junio ​​C Hamano - gitster- w commit 17b1e1d , 11 sierpnia 2017)}

http.c: http.sslcerti http.sslkeyoba są ścieżkami

Dawno temu, gdy utworzono nowoczesną ścieżkę kodową http_options () do analizowania różnych opcji http. * W 29508e1 („Izoluj funkcję współdzielonego żądania HTTP”, 2005-11-18, Git 0.99.9k), a później poprawiono ją pod kątem interakcji między wieloma pliki konfiguracyjne w 7059cd9 ( „ http_init(): Fix plik konfiguracyjny parsowania”, 2009-03-09, Git 1.6.3-RC0), mamy analizowane zmienne konfiguracyjne jak http.sslkey, http.sslcertjako zwykły ciągi wanilii, bo git_config_pathname()to rozumie « ~[username]/» prefiks nie istnieje.

Później przekonwertowaliśmy niektóre z nich (mianowicie http.sslCAPathi http.sslCAInfo), aby korzystać z funkcji, i dodaliśmy zmienne, takie jak http.cookeyFile http.pinnedpubkeykorzystanie z funkcji od samego początku. Z tego powodu wszystkie te zmienne rozumieją ~[username]/przedrostek „ ”.

Dokonaj pozostałych dwóch zmiennych, http.sslcerta http.sslkeytakże zwróć uwagę na konwencję, ponieważ oba są wyraźnie ścieżkami do plików.

Używając 64-bitowej wersji Git na Windows, po prostu dodaj samopodpisany certyfikat CA do tych plików:

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

Jeśli jest to tylko samopodpisany certyfikat serwera, dodaj go do

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

Sprawdź ustawienia antywirusa i zapory ogniowej.

Z dnia na dzień git już nie działał. Zgodnie z tym, co opisano powyżej, odkryłem, że Kaspersky umieszcza samopodpisany osobisty certyfikat główny antywirusa w środku. Nie udało mi się pozwolić Gitowi zaakceptować tego certyfikatu zgodnie z powyższymi instrukcjami. Zrezygnowałem z tego. Dla mnie działa wyłączenie funkcji Skanuj połączenia szyfrowane.

1. Otwórz Kaspersky
2. Ustawienia> Dodatkowe> Sieć> Nie skanuj szyfrowanych połączeń

Następnie git działa ponownie z włączoną funkcją sslVerify.

Uwaga. To wciąż nie jest dla mnie satysfakcjonujące, ponieważ chciałbym mieć tę funkcję mojego programu antywirusowego aktywną. W ustawieniach zaawansowanych Kaspersky wyświetla listę stron internetowych, które nie będą działać z tą funkcją. Github nie jest wymieniony jako jeden z nich. Sprawdzę to na forum Kaspersky. Wydaje się, że istnieją pewne tematy, np. Https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211

W .gitconfig pliku możesz dodać podaną poniżej wartość, aby samopodpisany certyfikat był akceptowalny

sslCAInfo = /home/XXXX/abc.crt

Robię to tak:

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

W systemie Windows działało to dla mnie:

Dodaj treść samopodpisanego certyfikatu na końcu pliku pakietu ca. W tym ----- BEGIN CERTIFICATE ----- i ----- END CERTIFICATE ----- linie

Lokalizacja pliku ca-bundle to zwykle C: \ Program Files \ Git \ mingw64 \ ssl \ certs

Następnie dodaj ścieżkę pliku ca-bundle do globalnej konfiguracji git. Następujące polecenie załatwia sprawę:git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt"

Uwaga: Ścieżka zależy od lokalnej ścieżki pliku pakietu ca!

Ustawienie http.sslVerify na false nie jest dobrą praktyką. Zamiast tego możemy użyć certyfikatu SSL.

Tak więc agent kompilacji użyje https z certyfikatem SSL i PAT do uwierzytelnienia.

Skopiuj zawartość pliku cer, w tym –begin — i –end--.

git bash on build agent => git config –global http.sslcainfo „C: / Program Files / Git / mingw64 / ssl / certs / ca-bundle.crt” Przejdź do tego pliku i dołącz zawartość .cer.

W ten sposób agent kompilacji może uzyskać dostęp do certyfikatu SSL

Moja odpowiedź może się spóźnić, ale zadziałała dla mnie. To może komuś pomóc.

Próbowałem wyżej wymienionych kroków, ale to nie rozwiązało problemu.

Spróbuj tegogit config --global http.sslVerify false

Używam komputera z systemem Windows i ten artykuł pomógł mi. Zasadniczo otworzyłem plik ca-bundle.crt w notatniku i dodałem do niego certyfikaty łańcuchowe (wszystkie). Ten problem zwykle występuje w sieciach firmowych, w których pośrednicy siedzą między systemem a repozytorium git. Musimy wyeksportować wszystkie certyfikaty w łańcuchu certyfikatów oprócz liścia certyfikatu w formacie base 64 i dodać je wszystkie do pliku ca-bundle.crt, a następnie skonfigurować git dla tego zmodyfikowanego pliku crt.