weryfikacja certyfikatu serwera nie powiodła się. Plik CA: /etc/ssl/certs/ca-certificates.crt Plik CRL: brak

334

Mogę przepchnąć projekt klonowania za pomocą ssh, ale to nie działa, gdy klonuję projekt za pomocą https.

Wyświetlany jest komunikat o błędzie:

server certificate verification failed. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none
Sokhom Ratanak
źródło

Odpowiedzi:

422

TLDR:

hostname=XXX
port=443
trust_cert_file_location=`curl-config --ca`

sudo bash -c "echo -n | openssl s_client -showcerts -connect $hostname:$port -servername $hostname \
    2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  \
    >> $trust_cert_file_location"

Długa odpowiedź

Podstawowym powodem jest to, że komputer nie ufa urzędowi certyfikacji, który podpisał certyfikat używany na serwerze Gitlab . Nie oznacza to, że certyfikat jest podejrzany, ale może być samopodpisany lub podpisany przez instytucję / firmę, która nie znajduje się na liście urzędów certyfikacji twojego systemu operacyjnego. Aby obejść problem na komputerze, musisz powiedzieć mu, aby zaufał temu certyfikatowi - jeśli nie masz powodu, aby być podejrzanym.

Musisz sprawdzić certyfikat internetowy używany na serwerze gitLab i dodać go do swojego </git_installation_folder>/bin/curl-ca-bundle.crt.

Aby sprawdzić, czy przynajmniej klon działa bez sprawdzania wspomnianego certyfikatu, możesz ustawić:

export GIT_SSL_NO_VERIFY=1
#or
git config --global http.sslverify false

Ale byłoby to tylko do testowania, jak pokazano w „ SSL działa z przeglądarką, wget i curl, ale nie działa z git ” lub w tym poście na blogu .

Sprawdź ustawienia GitLab, problem 4272 .


Aby uzyskać ten certyfikat (który musisz dodać do curl-ca-bundle.crtpliku), wpisz:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

(gdzie „ yourserver.com” to nazwa serwera GitLab i YourHttpsGitlabPortzwykle jest to port https 443)

Aby sprawdzić urząd certyfikacji (wystawcę ośrodka certyfikacji), wpisz:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGilabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | openssl x509 -noout -text | grep "CA Issuers" | head -1

Uwaga: Valeriy Katkov sugeruje w komentarzach, aby dodać -servernameopcję do polecenia openssl, w przeciwnym razie polecenie to nie pokaże certyfikatu dla www.github.com w przypadku Valeriy.

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Findekano dodaje w komentarzach :

aby zidentyfikować lokalizację curl-ca-bundle.crt, możesz użyć polecenia

curl-config --ca

Zobacz także moją najnowszą odpowiedź „ github: weryfikacja certyfikatu serwera nie powiodła się ”: może być konieczne ponowne zainstalowanie tych certyfikatów:

sudo apt-get install --reinstall ca-certificates
sudo mkdir /usr/local/share/ca-certificates/cacert.org
sudo wget -P /usr/local/share/ca-certificates/cacert.org http://www.cacert.org/certs/root.crt http://www.cacert.org/certs/class3.crt
sudo update-ca-certificates
git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt
VonC
źródło
8
Czy oryginalna wiadomość nie wskazuje, gdzie dodać certyfikat? W moim przypadku curl-config --cawrócił /etc/ssl/certs/ca-certificates.crt, gdzie musiałem dodać certyfikat. Poza tym ta odpowiedź była pierwszą informacją wskazującą mi właściwy kierunek w tej kwestii
uli_1973
1
Jak znaleźć folder instalacyjny git?
Bhargav
1
@Bhargav to zależy od twojego systemu operacyjnego. W systemie Linux możesz zrobić which git.
VonC
3
Pobiegłem curl-config --ca, ale nic nie zostało zwrócone.
Fernando Costa
1
Dzięki za wskazówkę - uratowałeś mi dzień.
Janne
220

Uwaga: Ma to poważne konsekwencje dla bezpieczeństwa.

Otwórz terminal i uruchom następujące polecenie:

export GIT_SSL_NO_VERIFY=1

Działa dla mnie i używam systemu Linux.

Afzal Masood
źródło
60
Nie oddawanie głosu w dół, ponieważ jest to obejście, gdy wiesz, co robisz. Zdecydowanie jednak odradzam to w ogólnym przypadku.
tripleee
9
Nie powiedziałbym, że to obejście, gdy wiesz, co robisz. Kiedy wiesz, co robisz, powinieneś spojrzeć na certyfikat, który uległ awarii, ponieważ „może ktoś nas zhakował”, a nie „no cóż, ochrona mówi, że ktoś nas włamał, zgadnij, że musimy wyłączyć zabezpieczenia”. Jest to w najlepszym wypadku środek zapobiegawczy, jeśli coś musi zostać popchnięte jak najszybciej.
srcspider
1
eksportując powyższą flagę, dostaję poniżej błędu. błąd: RPC nie powiodło się; wynik = 22, kod HTTP = 403 krytyczny: Zdalny koniec zawiesił się nieoczekiwanie błąd: RPC nie powiodło się; wynik = 22, kod HTTP = 403 krytyczny: Zdalny koniec nieoczekiwanie rozłączył się
Desu
7
Pracowałem dla mnie tylko zgit config --global http.sslverify false
Dinei
2
Świetny. Uratowałeś mi czas.
Sai prateek
146

Inną przyczyną tego problemu może być wyłączenie zegara. Certyfikaty są wrażliwe na czas.

Aby sprawdzić bieżący czas systemowy:

date -R

Możesz rozważyć zainstalowanie NTP w celu automatycznej synchronizacji czasu systemowego z zaufanymi internetowymi serwerami czasu z globalnej puli NTP . Na przykład, aby zainstalować na Debian / Ubuntu:

apt-get install ntp
dawidings
źródło
5
To był mój problem. Mój uniwersytet blokował pakiety NTTP, co uniemożliwiało mojemu systemowi aktualizację czasu. Po skonfigurowaniu uniwersyteckich serwerów NTTP wszystko znów działało. Dzięki za tę wskazówkę!
Kyle
3
To była również przyczyna mojego problemu, korzystałem z urządzenia osadzonego, które miało niewłaściwą datę!
Shervin Emami,
To był mój problem z certyfikatami. Spędziłem godziny, szukając różnego rodzaju rozwiązań, zanim odkryłem, że problem polegał na ustawieniu zegara serwera na przyszłość. Jednak nie pomogło mi to uzyskać wersji Node.js w przyszłości. :-(
Kevin Teljeur
1
@Katu to nie gitpowiedzmy, że jest to podstawowa wymiana SSL. Git jest zbudowany z obsługą SSL.
Yvan
1
Głosowałbym za tym 10000 razy ... zastanawiałem się, dlaczego to nie działa teraz przez 6 godzin ... Serwer był wyłączony o mniej niż 7 minut i to załatwiło sprawę ... DZIĘKI!
dGo
66

Jeśli używasz serwera git w sieci prywatnej i używasz certyfikatu z podpisem własnym lub certyfikatu za pośrednictwem adresu IP; możesz także po prostu użyć git global config, aby wyłączyć kontrole ssl:

git config --global http.sslverify "false"
Romain VDK
źródło
43

Miałem ten sam problem. Spowodowane przez samodzielnie wydany urząd certyfikacji. Rozwiązano go, dodając plik .pem do / usr / local / share / ca-certyfikaty / i wywołując

sudo update-ca-certificates

PS: plik pem w folderze ./share/ca-certificates MUSI mieć rozszerzenie .crt

Nikolay Ruban
źródło
2
Działa jak urok w Linuksie miętowym 16 :)
greuze
masz na myśli cert.pem lub cert.crt lub cert.pem.crt?
Mojżesz Liao GZ
1
cert.pem należy zmienić nazwę na cert.pem.crt
Nikolay Ruban
34

Sprawdź swój zegar systemowy,

$ date

Jeśli nie jest poprawne, sprawdzenie certyfikatu zakończy się niepowodzeniem. Aby poprawić zegar systemowy,

$ apt-get install ntp

Zegar powinien się zsynchronizować.

Na koniec wprowadź ponownie polecenie klonowania.

mycowan
źródło
1
Tak! Długo miałem zawieszoną instancję Ubuntu w VirtualBox. Zegar systemowy nie zsynchronizował się z jakiegokolwiek powodu, gdy się zawiesiłem. Odpowiedź VonC wydaje się być kompetentna, ale naprawdę się cieszę, że nie musiałem uruchamiać wielu poleceń bezpieczeństwa, których nie rozumiem. Sprawdź to najpierw!
AndyJost
24
GIT_CURL_VERBOSE=1 git [clone|fetch]…

powinien powiedzieć ci, gdzie jest problem. W moim przypadku było to spowodowane tym, że cURL nie wspiera certyfikatów PEM, gdy jest budowany w oparciu o NSS, ponieważ obsługa ta nie jest linią główną w NSS ( # 726116 # 804215 # 402712 i więcej ).

Tobu
źródło
4
Niezły dodatek z GIT_CURL_VERBOSE. Nie wspomniałem o tym w mojej odpowiedzi. +1
VonC
18

Lub po prostu uruchom ten komentarz, aby dodać certyfikat serwera do bazy danych:

echo $(echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort 2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p') >> /etc/ssl/certs/ca-certificates.crt

Następnie ponownie klonuj git.

phiphu
źródło
1
Nie wiem, czy to działa dla każdego, ale potrzebuję „tee”, aby dołączyć plik cert jako root: echo -n | openssl s_client -showcerts -connect yourserver.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt
ywu
W moim przypadku serwer ma prawidłowy certyfikat, ale moja baza danych go nie zawiera, dzięki temu poleceniu rozwiązałem, ale muszę powiedzieć, że to polecenie musi być uruchomione z uprawnieniami administratora.
hermeslm
10

Zepsułem swoje pliki CA podczas konfigurowania goagent proxy. Nie można pobrać danych z github i otrzymać takie samo ostrzeżenie:

weryfikacja certyfikatu serwera nie powiodła się. Plik CA: /etc/ssl/certs/ca-certificates.crt Plik CRL: brak

użyj metody Vonc, pobierz certyfikat z github i umieść go w /etc/ssl/certs/ca-certificates.crt, problem rozwiązany.

echo -n | openssl s_client -showcerts -connect github.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p'

IFQ
źródło
8

nie ma potrzeby ustawiania weryfikacji git ssl w celu ustawienia wartości false. Jest to spowodowane tym, że system nie ma wszystkich certyfikatów urzędu certyfikacji. Głównie ludzie, którzy mają prawdziwy certyfikat SSL, nie posiadają certyfikatu pośredniego.

Wystarczy dodać pełny tekst certyfikatu pośredniego (cały łańcuch brakującego urzędu certyfikacji i certyfikatu pośredniego) do

sudo gedit /etc/ssl/certs/ca-certificates.crt 

działa bez uruchamiania update-ca-certificates.

To samo dotyczy ręcznie wygenerowanych certyfikatów, wystarczy dodać tekst certyfikatu urzędu certyfikacji.

Na koniec: Push udane: wszystko jest aktualne

abcdef12
źródło
1
To samo może być spowodowane, jeśli serwer nie jest poprawnie skonfigurowany z całym łańcuchem certyfikatów CA SSL.
abcdef12,
Przyczyną mogą być problemy z łańcuchem, jak skomentował abcdef12. Miałem ten problem z git 1.9.1 - serwer wysyłał łańcuch certyfikatów: # 0 serwer cert; # 1 certyfikat serwera (ponownie); # 2 certyfikat osoby podpisującej Duplikat w łańcuchu był powodem, dla którego git go nie lubił.
ja
8

Co zrobiłem, aby rozwiązać ten problem w terminalu (Ubuntu 18.04):

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Mam dwie części certyfikatu. I skopiowałem części certyfikatu do mojego pliku certyfikatu do /etc/ssl/certs/ca-certificates.crt.

mindcoder
źródło
To rozwiązanie rozwiązuje mój identyczny problem w Ubuntu 16.04.
user3072843,
Co dokładnie masz na myśli z częściami certyfikacyjnymi ? Blok między ---BEGIN CERTIFICATE---a --- END CERTIFICATE ---?
B - rian
3

Zainstalowałem Xubuntu na Raspberry pi 2, znalazłem ten sam problem z czasem, ponieważ NTP i automatyczna synchronizacja serwera były wyłączone (lub nie zostały zainstalowane). Uzyskaj NTP

sudo apt-get install ntp

i zmień „Czas i datę” z „Ręcznie” na „Zachowaj synchronizację z serwerami internetowymi”

użytkownik273711
źródło
1

Ostatecznie dodaj http.sslverify do swojego .git / config.

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://server/user/project.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[http]
        sslVerify = false
Mickael L.
źródło
1
Lepiej użyć wiersza polecenia git config http.sslVerify false. Czy sugerujesz edycję konfiguracji Git dla poszczególnych repozytoriów, a nie globalnie, jak sugeruje @ romain-vdk?
ahogen
1

Pierwszą rzeczą, którą powinieneś sprawdzić, jest zezwolenie na pliki /etc/ssli /etc/ssl/certs.

Popełniłem błąd, upuszczając uprawnienia do plików (lub usuwając rm -rf /etc/ssl/*katalogi SSL ) podczas używania ssl-certnazwy / identyfikatora grupy podczas pracy z moim narzędziem zarządzania urzędem certyfikacji .

To właśnie wtedy zauważyłem dokładnie ten sam komunikat o błędzie dla wgeti curlCLI Przeglądarka Narzędzia:

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Kiedy podniosłem uprawnienia do plików /etc/ssli /etc/ssl/certkatalogów o+rx-w, te narzędzia przeglądarki CLI zaczęły nieco łatwiej oddychać:

mkdir -p /etc/ssl/certs
chmod u+rwx,go+rx /etc/ssl /etc/ssl/certs

Musiałem także odtworzyć podkatalog Java i zrekonstruować katalogi certyfikatów Trusted CA:

mkdir /etc/ssl/certs/java
chmod u+rwx,go+rx /etc/ssl/certs/java
update-ca-certificates

a wybrzeże było czyste.

John Greene
źródło
0

Właśnie spotkałem ten sam problem z repozytorium git, które zawsze działa dla mnie. Problem polegał na tym, że uzyskiwałem do niego dostęp przez publiczny dostęp do Wi-Fi, który przekierowuje do niewoli portalu przy pierwszym połączeniu (na przykład, aby wyświetlać reklamy i zgadzać się z tos).

Tosha
źródło
0

Skopiuj certyfikat i pakiet do jednego pliku .crt i upewnij się, że między certyfikatami w pliku jest pusta linia.

To zadziałało dla mnie na serwerze GitLab po wypróbowaniu wszystkiego w Internecie.

shambhu
źródło