Ответ 1
Обновление с SVN 1.6.15 до 1.6.16 исправить эту проблему для меня.
Я запускаю сервер, который принимает запросы https. Я создал свой собственный сертификат. При переходе на сайт в firefox я получаю неизвестную ошибку сертификата, но это нормально. Это (я думаю) указывает, что переадресация порта и такие работы.
Я пытаюсь использовать svn с этим. При использовании svn на сервере (но с использованием внешнего ip) он работает. Снова я получаю сертификат неизвестен, но мне все равно.
При использовании svn на Mac OS X я получаю
Ошибка согласования SSL: код ошибки SSL -1/1/336032856
Я нашел несколько сообщений в google об этом, но все они говорят об ошибке с версией openssl 0.9.8, и что использование чего-то большего должно исправить.
В настоящее время я использую openssl 1.0.0c. Я понятия не имею, что происходит. Я также проверил журнал ошибок в httpd, и ничего не появилось.
Любые идеи по этому поводу действительно помогут.
Спасибо
Обновление с SVN 1.6.15 до 1.6.16 исправить эту проблему для меня.
Я получил то же сообщение об ошибке, когда моя конфигурация Apache была неправильной - мой параметр ServerName в httpd.conf
не соответствовал имени хоста в самозаверяющем сертификате.
Я начал получать эту ошибку от более старых клиентов subversion (Tortoise 1.6.4, я думаю, и pysvn r1280), когда наш сервер svn обновил экземпляр Apache. Он исходил от использования OpenSSL 0.9.8n до 1.0.0d.
Черепаха исправлена обновлением до 1.6.16 (использует OpenSSL 1.0.0d).
Фиксинг pysvn был другой историей. Последняя версия (r1360) появилась с той же ошибкой. Похоже, что информации не было много, кроме подсказок о необходимости обновления OpenSLL. Я пытался копировать в разных версиях OpenSSL (libeay32.dll и ssleay32.dll), и вот результаты:
Так что все, что они исправили в выпуске L, вскоре снова сломалось или появилось что-то особенное в двоичных файлах CollabNet OpenSSL.
В моем случае это началось после некоторых изменений сертификатов на стороне сервера. Я попытался удалить .subversion/dir, обновить openssl, openssh, svn и ничего...
Наконец, он был исправлен, когда я заменил имя хоста urp на ip-адрес этого узла. В существующих рабочих экземплярах было достаточно:
svn switch --relocate http://hostname.com https://ipaddress
Не уверен, что это ошибка или что-то еще, но кажется, что новые сертификаты не распознаются и продолжают использовать старые кешированные данные для определенного имени хоста.
Я согласен с более ранним ответом Лукаса Ценовского, что установка ServerName в конфигурации apache устраняет проблему.
В этой ссылке http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf говорится, что ошибка исходит из библиотеки SSL.
Полное сообщение об ошибке (просто чтобы включить лучшую индексацию google), я получаю:
$ svn ls https://www.OMITTED.dk/svn svn: E175002: Unable to connect to a repository at URL 'https://www.OMITTED.dk/svn' svn: E175002: OPTIONS of 'https://www.OMITTED.dk/svn': SSL handshake failed: SSL error code -1/1/336032856 (https://www.OMITTED.dk)
В файле /etc/apache 2/sites-available/ssl (debian linux) Я добавил имя_сервера как:
NameVirtualHost *:443 <VirtualHost *:443> ServerAdmin [email protected] SSLEngine On ServerName www.OMITTED.dk
Посмотрите, что произойдет, если устранить проблему SSL, добавив сгенерированный сертификат в хранилище доверенных сертификатов вашего клиента.
На шаг впереди мой случай - рабочая станция MSWindows Client и сервер CentOs с Apache.
Используя Tortoise Subversion 1.6.16, я понимаю, что после выполнения "svn checkout https://OMITTED.dk/project, я получил ту же самую ошибку ssl handshake.
То, что я сделал, было
Таким образом, я пытаюсь выполнить команду: svn update path_to_project --non-interactive --trust-server-cert. Надежда будет полезна