неприятности через https: подпрограммы: SSL23_GET_SERVER_HELLO - PullRequest
11 голосов
/ 14 октября 2011

Я сделал свой собственный git-сервер на дистрибутиве centos. Я могу связаться с сервером по протоколу Git у меня дома. Но когда я пытаюсь получить доступ через https в офисе, я получаю:

Клонирование в / Users / vito / Documents / ... ошибка: ошибка: 14077458: подпрограммы SSL: SSL23_GET_SERVER_HELLO: причина (1112) в то время как доступ https://gitolite@myserverxyz.com/vitorepo.git/info/refs

фатально: HTTP-запрос не выполнен

Где проблема? На моем сервере или в моем офисе Mac?

Ответы [ 6 ]

7 голосов
/ 18 апреля 2012

Я получил точно такой же ответ от curl при попытке соединения с экземпляром ubuntu, работающим с openssl 1.0.0e. Я успешно решил проблему, добавив флаг -ssl3 в команду curl.

3 голосов
/ 09 ноября 2011

Кажется, что это проблема совместимости между более старой версией OpenSSL (0.9.8), действующей в качестве клиента, и недавней версией OpenSSL (1.0.0), действующей в качестве сервера, с некоторыми конкретными параметрами, используемыми Curl на стороне клиента и Apache на сторона сервера.

Вероятно, это связано с недавним исправлением безопасности в OpenSSL (возможно, с исправлением атак на понижение протокола).

Попробуйте обновить версию библиотеки OpenSSL на стороне клиента до 1.0.0.

См:

https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976

2 голосов
/ 31 октября 2012

На случай, если у кого-то возникнет эта проблема с XMLRPC.

Ответ Даниэля (форсирование SSL версии 3) решил эту проблему для меня.просто укажите XMLRPC_SSLVERSION_SSLv3 в параметрах clientXmlTransport_curl (C ++).

Проблема началась, когда мы обновили наш сервер до версии OpenSSL 1.0.1-4ubuntu5.5, и клиенты все еще работали с 0.9.8o-5ubuntu1.7.

1 голос
/ 06 октября 2013

Не уверен, что у меня была точно такая же проблема, но сообщение об ошибке было таким же. Похоже, это происходило только на коробке ubuntu, на которой я настроил git-сервер, по какой-то причине коробка centos с настроенным git-сервером была в порядке.

Я только что решил это через 3 или 4 дня. Оказывается, потому что лежащая в основе git библиотека Curl имеет неработающую реализацию Keep-alive (в итоге я сбросил HTTP-трафик и проверил поведение вручную).

В двух словах: Curl (по крайней мере, версия, используемая в каждой реализации Git, которую я смог найти, включая git командной строки и EGit eclipse), похоже, неправильно интерпретирует заголовок отклика Connection или, более правильно, кажется, неправильно интерпретировать отсутствие этого.

Чтобы решить эту проблему, вам нужно настроить виртуальный хост SSL внутри apache, который обслуживает ваш GIT-репозиторий, с дополнительной директивой специально для git. Добавьте эти строки непосредственно перед .

 BrowserMatch "git" nokeepalive ssl-unclean-shutdown

К сожалению, вы не можете сказать apache просто понизить до HTTP / 1.0 (было бы чище), потому что Curl не может с этим справиться, но вы можете просто сказать ему принудительно устанавливать Connection: close при каждом запросе, который Curl знает как обрабатывать.

В случае ошибочного совпадения, если вы попытаетесь проверить Curl напрямую без этого изменения, оно будет работать, потому что оно делает один запрос, а затем прерывается. Эта проблема станет очевидной только при получении curl для выполнения двух запросов по одному и тому же keep-alive соединению через ssl.

1 голос
/ 29 ноября 2011

Я считаю, что это проблема сопоставления имени хоста на сервере. Ошибка 1112 - это SSL_R_TLSV1_UNRECOGNIZED_NAME, и она возникает из-за несоответствия имени SNI ( информация о SNI ). У меня была та же самая проблема в curl .

Для меня обходным путем было убедиться, что имя, которое я использовал на клиенте, соответствовало одной из конфигураций ServerName или ServerAlias ​​на сервере. Конечно, эти команды предназначены для сервера Apache; Я не знаю, что вам нужно сделать для git-сервера. Но я подозреваю, что имена серверов, которые вы используете из дома и на работе, отличаются, а домашнее имя - это каноническое имя, используемое git-сервером (и, следовательно, SNI работает).

«Настоящее» исправление, вероятно, потребует изменения клиента в git, чтобы позволить способ игнорировать предупреждение о несоответствии имен (как это делает ваш браузер).

0 голосов
/ 12 июля 2014

У меня была такая же ошибка.Основной причиной является несовместимость версий openssl клиент / сервер.Я обновил свой сервер до apt-get upgrade openssl и обновил установку windows git.

Комбинация Windows git client git version 1.9.4.msysgit.0, которая содержит версию openssl: OpenSSL 0.9.8e 23 Feb 2007

И сервер сВерсия openssl: OpenSSL 1.0.1c 10 May 2012

, кажется, отлично работает вместе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...