добавление SSL-сертификата только для Github (не все сертификаты из пакета ca-Certificates)


13

Я получаю следующую ошибку при доступе к Github через HTTPS:

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

Это потому, что у меня нет сертификатов /etc/ssl/certs/. Я знаю, как решить эту проблему. Я могу установить пакет ca-certificatesиз репозитория Debian. Проблема, однако, в том, что при этом будут установлены все сертификаты (тысячи), которые я не обязательно хочу принимать / доверять.

Как я могу установить сертификат только для Github?

Подзадача / Подзапрос

На другом компьютере, где пакет ca-certificatesуже установлен и git работает, я заметил, что некоторые сертификаты /etc/ssl/certs/находятся в одном сертификате на файл, а другие - много сертификатов в одном файле. Конкретный файл, содержащий сертификат Github, /etc/ssl/certs/ca-certificates.crtсодержит более 150 других сертификатов:

$ grep 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt | wc -l
159

Как я могу найти, какой из этих 159 сертификатов мне нужен? (кроме грубой силы - разрезание файла пополам и проверка обеих половин, повторение while n > 1).


Что вы пытаетесь достичь? Связаться с GitHub программно?
Нейт У.

Вы пытались загрузить исходный пакет, а затем извлечь только тот сертификат, который вам нужен?
Джейхендрен

Что вы используете для доступа к GitHub? какой-нибудь инструмент командной строки? браузер?
14

Ответы:


13

Чтобы получить доступ к вашему Github, вам нужно сделать это через ssh. Поэтому вам нужно добавить ваш открытый ключ ssh в github. После этого вы можете получить доступ к github через ssh, т.е.

git init git@github.com:yourname/yourrepo.git

Смотрите также: Github: генерация ключей ssh , WikiHow

[Правка № 1]

без проверок сертификатов:

GIT_SSL_NO_VERIFY=true git clone https://github.com/p/repo.git

или заверенный

GIT_SSL_NO_VERIFY=true git clone https://user@pass:github.com/p/repo.git

Для меня все еще не ясно, о чем вы просите, потому что вы знаете, что установка CA-сертификатов решит проблему.

[Правка № 2]

Хорошо, другой вопрос

как получить только сертификат, необходимый для доступа к github.com через https

  1. Откройте браузер и перейдите на https://github.com/ . Нажмите на зеленое имя слева от https://и нажмите на Certificates. На Detailsвкладке вы увидите цепочку сертификатов, которая:

    DigiCert ...
      DigiCert ...
       github.com ...
    
  2. Экспортируйте каждый из сертификатов DigiCert в файл.

  3. скопировать файлы в /etc/ssl/certs/
  4. запустить c_rehashкакой кот все сертификатыca-certificates.crt
  5. вы сделали.

Как я уже сказал, я не являюсь другом таких действий, потому что github может изменить CA в любое время, поэтому это всегда приведет к дополнительной работе.


1
Спасибо за предложение. Но я хотел бы получить доступ githubчерез https.
Мартин Вегтер

1

Как было предложено ранее, вы можете использовать ключи SSH, вместо того чтобы полагаться на HTTPS, чтобы избежать этой проблемы и, возможно, повысить безопасность.

Сказав это, я думаю, что вы ищете, как установить сертификаты root / CA в / etc / ssl / certs. В двух словах, недостаточно просто выгружать файл в кодировке PEM в / etc / ssl / certs - вы также должны вычислить хэш указанного сертификата и создать символическую ссылку в / etc / ssl / certs для этого сертификата. файл. Имя символической ссылки должно содержать хеш с суффиксом .0 или, если есть коллизия хешей, .1 и т. Д.

Вот подробное описание, а также пример сценария, который вы можете использовать для автоматизации процесса: http://wiki.openwrt.org/doc/howto/wget-ssl-certs#adding.root.certificates

Надеюсь, это то, что вы искали, но, как я уже говорил ранее, ключи SSH, вероятно, являются «лучшим» решением. :)


c_rehashделает то, что вы объяснили. Смотрите c_rehashсправочную страницу. Кстати: нет необходимости вычислять хэши. Достаточно добавить сертификаты в ca-сертификаты.crt, так как gitчитает только этот файл. Кроме того, ссылка объясняет, как вручную получить сертификаты с помощью openssl. Это очень сомнительно и провоцирует человека в середине атаки. Я бы не рекомендовал это.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.