git проблема через https: подпрограммы: SSL23_GET_SERVER_HELLO

Ответ 1

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

Ответ 2

Похоже, что проблема совместимости между старой версией 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

Ответ 3

В случае, если у кого-то есть эта проблема с XMLRPC.

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

 BrowserMatch "git" nokeepalive ssl-unclean-shutdown

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

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

Ответ 6

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

Комбинация окон 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

кажется, прекрасно работает вместе.