sunucu sertifikası doğrulanamadı. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: yok

Ssh kullanarak klon projesini zorlayabilirim, ancak https ile projeyi klonladığımda işe yaramıyor.

Beni gösteren hata mesajı:

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"

Uzun cevap

Bunun temel nedeni bilgisayarınızın Gitlab sunucusunda kullanılan sertifikayı imzalayan sertifika yetkilisine güvenmemesidir . Bu, sertifikanın şüpheli olduğu anlamına gelmez, ancak işletim sisteminizin CA'lar listesinde yer almayan bir kurum / şirket tarafından otomatik olarak imzalanabilir veya imzalanabilir. Bilgisayarınızdaki sorunu atlatmak için yapmanız gereken şey bu sertifikaya güvenmesini söylüyor - bu konuda şüphelenmek için bir nedeniniz yoksa.

GitLab sunucunuz için kullanılan web sertifikasını kontrol etmeniz ve sunucunuza eklemeniz gerekir </git_installation_folder>/bin/curl-ca-bundle.crt.

En azından klonun söz konusu sertifikayı kontrol etmeden çalışıp çalışmadığını kontrol etmek için şunları ayarlayabilirsiniz:

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

Ancak bu, " SSL tarayıcı, wget ve curl ile çalışır, ancak git ile başarısız olur " veya bu blog gönderisinde gösterildiği gibi yalnızca test amaçlıdır .

Daki GitLab ayarları, kontrol sorunu 4272 .

Bu sertifikayı almak için ( curl-ca-bundle.crtdosyanıza eklemeniz gerekir ), şunu yazın:

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

(' yourserver.com' GitLab sunucu adınızdır ve YourHttpsGitlabPortgenellikle https bağlantı noktasıdır 443)

CA'yı (Sertifika Yetkilisi yayıncısı) kontrol etmek için aşağıdakileri yazın:

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

Not: Valeriy Katkov yorumlarda-servername openssl komutuna seçenek eklemeyi önerir , aksi takdirde komut Valeriy'nin durumunda www.github.com sertifikasını göstermez.

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

Findekano ekler yorumlarda :

konumunu tanımlamak için curl-ca-bundle.crtşu komutu kullanabilirsiniz:

curl-config --ca

Ayrıca, daha yeni yanıtım olan " github: sunucu sertifikası doğrulaması başarısız oldu " ifadesine bakın: bu sertifikaları yeniden adlandırmanız gerekebilir:

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

Not: Bunun önemli güvenlik etkileri vardır.

Terminalinizi açın ve aşağıdaki komutu çalıştırın:

export GIT_SSL_NO_VERIFY=1

Benim için çalışıyor ve Linux sistemini kullanıyorum.

Bu sorunun bir başka nedeni de saatinizin kapalı olması olabilir. Sertifikalar zaman duyarlıdır.

Geçerli sistem saatini kontrol etmek için:

date -R

Sistem saatini, genel NTP havuzundan güvenilir internet zaman sunucularıyla otomatik olarak eşitlemek için NTP'yi yüklemeyi düşünebilirsiniz . Örneğin, Debian / Ubuntu'ya kurmak için:

apt-get install ntp

Özel bir ağ içinde git sunucusu kullanıyorsanız ve kendinden imzalı bir sertifika veya IP adresi üzerinden bir sertifika kullanıyorsanız; ssl denetimlerini devre dışı bırakmak için git global config komutunu da kullanabilirsiniz:

git config --global http.sslverify "false"

Aynı sorun vardı. Kendi kendine verilen sertifika yetkilisi tarafından. İçin .pem dosyasını ekleyerek çözüldü / usr / local / share / ca-sertifikalar / ve çağrı

sudo update-ca-certificates

PS: ./share/ca-certificates klasöründeki pem dosyasının uzantısı .crt olmalıdır ZORUNLU

Sistem saatinizi kontrol edin,

$ date

Doğru değilse, sertifika denetimi başarısız olur. Sistem saatini düzeltmek için,

$ apt-get install ntp

Saat kendini senkronize etmelidir.

Son olarak klon komutunu tekrar girin.

GIT_CURL_VERBOSE=1 git [clone|fetch]…

sorunun nerede olduğunu söylemeliyim. Benim durumumda, cURL'nin NSS'ye karşı inşa edildiğinde PEM sertifikalarını desteklememesi nedeniyle, bu desteğin NSS'de ana hat olmaması nedeniyle ( # 726116 # 804215 # 402712 ve daha fazlası ).

Veya sunucu sertifikasını veritabanınıza eklemek için bu yorumu çalıştırın:

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

Sonra tekrar klonla git.

Goagent proxy'yi kurarken CA dosyalarımla uğraştım. Github'dan veri çekilemiyor ve aynı uyarı alınamıyor:

sunucu sertifikası doğrulanamadı. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: yok

Vonc yöntemini kullanın, sertifikayı github'dan alın ve /etc/ssl/certs/ca-certificates.crt içine koyun, sorun çözüldü.

echo -n | openssl s_client -showcerts -connect github.com:443 2> / dev / null | sed -ne '/ -BEGIN BELGESİ - /, / - SON SERTİFİKASI- / p'

false olarak ayarlamak için git ssl doğrulamasını ayarlamanıza gerek yoktur. Sistemin tüm CA yetki sertifikalarına sahip olmaması nedeniyle oluşur. Çoğunlukla orijinal SSL sertifikası olan kişiler ara sertifikayı kaçırırlar.

Sadece ara sertifikanın tam metnini (eksik CA ve ara sertifikanın tüm zinciri)

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

çalıştırmadan çalışır update-ca-certificates.

Manuel olarak oluşturulan sertifikalar için de aynı şey geçerlidir, CA sertifika metnini eklemeniz yeterlidir.

Sonunda: İtme başarılı: Her şey güncel

Terminalde bu sorunu çözmek için ne yaptım (Ubuntu 18.04):

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

İki tane sertifika parçası aldım. Sertifika yığınlarını sertifika dosyama kopyaladım /etc/ssl/certs/ca-certificates.crt.

Xubuntu'yu bir Raspberry pi 2'ye yükledim, NTP ve Otomatik Sunucu senkronizasyonu kapalı (veya yüklü değil) ile aynı sorunu buldum. NTP edinin

sudo apt-get install ntp

ve "Saat ve Tarih" i "Manuel" olarak "İnternet Sunucuları ile senkronize tut" olarak değiştirin

Sonunda, http.sslverify dosyasını .git / config dosyasına ekleyin.

[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

Eğer kontrol gereken ilk şey dosya iznidir /etc/sslve /etc/ssl/certs.

Sertifika Yetkilisi Yönetim Aracı üzerinde çalışırken grup adını / kimliğini kullanırken dosya izinlerini bırakma (veya SSL rm -rf /etc/ssl/*dizinlerini havaya uçurma) hatasını yaptımssl-cert .

O zaman ben de aynı hata mesajı wgetve curlCLI tarayıcı araçları fark ettim :

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

/etc/sslVe /etc/ssl/certdizinlerin dosya iznini getirdikten sonra o+rx-w, bu CLI tarayıcı araçları biraz daha kolay nefes almaya başladı:

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

Ayrıca Java alt dizinini yeniden oluşturmak ve Güvenilen CA sertifika dizinlerini yeniden yapılandırmak zorunda kaldım:

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

ve sahil açıktı.

Ben sadece hep benim için çalışan bir git deposu ile aynı sorunla karşılaştı. Sorun, ilk bağlantıda (örneğin reklamları göstermek ve tos ile anlaşmak için) tutsak bir portala yönlendiren genel WiFi erişimi aracılığıyla erişmemdi.

Sertifikayı ve paketi bir .crt dosyasına kopyalayın ve dosyadaki sertifikalar arasında boş bir satır olduğundan emin olun.

Bu, Internet'teki her şeyi denedikten sonra benim için bir GitLab sunucusunda çalıştı.