Ошибка проверки сертификата сервера. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: нет

Я могу отправить клонированный проект с помощью ssh, но он не работает, когда я клонирую проект с помощью https.

Сообщение об ошибке, которое показывает мне:

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"

Длинный ответ

Основная причина в том, что ваш компьютер не доверяет центру сертификации, который подписал сертификат, используемый на сервере Gitlab . Это не означает, что сертификат является подозрительным, но он может быть самоподписанным или подписанным организацией / компанией, которой нет в списке центров сертификации вашей ОС. Чтобы обойти проблему на вашем компьютере, вы должны заставить его доверять этому сертификату, если у вас нет причин для подозрения.

Вам необходимо проверить веб-сертификат, используемый для вашего сервера gitLab, и добавить его к своему </git_installation_folder>/bin/curl-ca-bundle.crt.

Чтобы проверить, работает ли хотя бы клон без проверки указанного сертификата, вы можете установить:

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

Но это будет только для тестирования, как показано в « SSL работает с браузером, wget и curl, но не работает с git » или в этом сообщении в блоге .

Проверьте настройки GitLab, выпуск 4272 .

Чтобы получить этот сертификат (который вам нужно добавить в ваш curl-ca-bundle.crtфайл), введите:

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

(где ' yourserver.com' - это имя вашего сервера GitLab и YourHttpsGitlabPortобычно порт https 443)

Чтобы проверить CA (эмитент центра сертификации), введите:

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

Примечание: Валерий Катков предлагает в комментариях добавить -servernameопцию к команде openssl, в противном случае команда не показывает сертификат для www.github.com в случае Валерия.

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

Финдекано добавляет в комментариях :

чтобы определить местоположение curl-ca-bundle.crt, вы можете использовать команду

curl-config --ca

Кроме того, посмотрите мой более свежий ответ « github: сбой проверки сертификата сервера »: возможно, вам придется перерегистрировать эти сертификаты:

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

Примечание. Это имеет серьезные последствия для безопасности.

Откройте свой терминал и выполните следующую команду:

export GIT_SSL_NO_VERIFY=1

Это работает для меня, и я использую систему Linux.

Другой причиной этой проблемы может быть то, что ваши часы могут быть выключены. Сертификаты чувствительны ко времени.

Чтобы проверить текущее системное время:

date -R

Вы можете рассмотреть возможность установки NTP для автоматической синхронизации системного времени с доверенными серверами времени из глобального пула NTP . Например, чтобы установить в Debian / Ubuntu:

apt-get install ntp

Если вы используете git-сервер в частной сети и используете самозаверяющий сертификат или сертификат через IP-адрес; Вы также можете просто использовать git global config, чтобы отключить проверки ssl:

git config --global http.sslverify "false"

Была такая же проблема. Вызывается самостоятельно выданным центром сертификации. Решил это, добавив файл .pem в / usr / local / share / ca-сертификаты / и вызвав

sudo update-ca-certificates

PS: файл pem в папке ./share/ca-certificates ДОЛЖЕН иметь расширение .crt

Проверьте ваши системные часы,

$ date

Если это не правильно, проверка сертификата не удастся. Чтобы исправить системные часы,

$ apt-get install ntp

Часы должны синхронизироваться.

Наконец, введите команду клонирования снова.

GIT_CURL_VERBOSE=1 git [clone|fetch]…

должен сказать вам, где проблема. В моем случае это произошло из-за того, что cURL не поддерживает сертификаты PEM при построении против NSS, поскольку эта поддержка не является основной в NSS ( # 726116 # 804215 # 402712 и более ).

Или просто запустите этот комментарий, чтобы добавить сертификат сервера в вашу базу данных:

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

Затем сделайте git clone снова.

Я испортил свои CA-файлы, пока настраивал прокси-сервер goagent. Не могу получить данные из github и получить то же предупреждение:

Ошибка проверки сертификата сервера. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: нет

используйте метод Vonc, получите сертификат от github и поместите его в /etc/ssl/certs/ca-certificates.crt, проблема решена.

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

нет необходимости устанавливать для проверки git ssl значение false. Это происходит, когда система не имеет всех сертификатов центра сертификации. В основном люди, которые имеют подлинный сертификат SSL, не имеют промежуточного сертификата.

Просто добавьте полный текст промежуточного сертификата (всю цепочку отсутствующих CA и промежуточный сертификат) в

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

работает без запуска update-ca-certificates.

То же самое касается сертификатов, созданных вручную, просто добавьте текст сертификата CA.

В конце: Успешный толчок: все актуально

Что я сделал, чтобы решить эту проблему в терминале (Ubuntu 18.04):

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

Я получил два куска сертификата. И я скопировал куски сертификата в мой файл сертификата в /etc/ssl/certs/ca-certificates.crt.

Я установил Xubuntu на Raspberry pi 2, обнаружил ту же проблему со временем, когда NTP и автоматическая синхронизация с сервером были отключены (или не установлены). Получить NTP

sudo apt-get install ntp

и измените «Время и дата» с «Вручную» на «Синхронизировать с интернет-серверами»

В конце концов, добавьте http.sslverify в ваш .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

Первое, что вы должны проверить, это разрешение файла /etc/sslи /etc/ssl/certs.

Я сделал ошибку, отбросив права доступа к файлам (или уничтожив rm -rf /etc/ssl/*каталоги SSL ) при использовании ssl-certимени / идентификатора группы при работе со своим инструментом управления центром сертификации .

Именно тогда я заметил , что точно такое же сообщение об ошибке для wgetи curlCLI инструментов браузера:

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

Как только я увеличил разрешение на доступ к файлам /etc/sslи /etc/ssl/certкаталогам o+rx-w, эти инструменты браузера CLI начали дышать немного легче:

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

Мне также пришлось воссоздать подкаталог Java и восстановить каталоги сертификатов Trusted CA:

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

и побережье было чистым.

Я только что столкнулся с той же проблемой с git-репозиторием, который всегда работает для меня. Проблема заключалась в том, что я получил к нему доступ через общедоступный WiFi-доступ, который перенаправляет на неавтоматизированный портал при первом подключении (например, для показа рекламы и согласования с предложениями).

Скопируйте сертификат и пакет в один файл .crt и убедитесь, что между сертификатами в файле есть пустая строка.

Это сработало для меня на сервере GitLab после того, как я попробовал все в Интернете