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

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

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

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.

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

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"

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

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.

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 ).

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.

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'

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

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.

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”

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

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.

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).

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.