Ошибка проверки SSL-сертификата сервера Subversion: и другие причины

У меня была система SVN, которая работала нормально, и после недавнего обновления внезапно перестала работать. Моя установка:

  • У меня есть репозиторий, размещенный на сервере Windows 2008 с использованием VisualSVN Server 2.7.4. Сервер предлагает мне возможность генерировать самозаверяющие сертификаты по желанию, вводя собственное имя хоста или другие данные по желанию.

  • Я использую Eclipse (Kepler) для java-кодирования как на размещенной машине, так и на своем собственном MacBookPro под управлением Mac OS X 10.9.1 (Mavericks). У меня есть надстройка subclipse для Eclipse, которая требует подрывной деятельности с помощью java HL.

  • Я установил macports и последние пакеты subversion/javahl, запрошенные subclipse. Интерфейс Eclipse/subversion, кажется, работает нормально, но есть ошибки subversion командной строки, с которыми Eclipse не справляется. Устранение ошибок командной строки является основной проблемой.

  • Ранее у меня были установлены следующие версии через macports, и все, казалось, работало нормально:

    subversion @1.8.5_1+universal
    subversion-javahlbindings @1.8.5_0+no_bdb+universal

  • В рамках установки/устранения неполадок, не связанных с чем-то, я обновил все свои macports, которые установили следующие новые версии:

    subversion @1.8.8_0+universal
    subversion-javahlbindings @1.8.8_0+no_bdb+universal

  • После обновления svn через eclipse на моем Mac не работает. Я могу заставить это через командную строку, временно приняв сертификат. Он по-прежнему отлично работает на сервере Windows 2008.

В первый раз после изменения сертификата я получаю возможность принять его навсегда, но после этого он терпит неудачу и возвращается ко второму «временному» диалогу.

$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
(credentials dialogue)
At revision 46.
  • После этого будущие попытки по-прежнему приводят к ошибке и требованию временно принять:
$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate hostname does not match.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
At revision 46.

Многочисленные веб-поиски, включая этот сайт и другие, указывали на файлы аутентификации в ~/.subversion как на потенциальную проблему, но все предложенные решения (удаление, изменение владельца и разрешений и т. д.) не помогли решить проблему.

Конкретные вопросы: 1. Я не могу понять, как вернуться к предыдущей версии Subversion (1.8.5) в macports, чтобы увидеть, была ли ошибка в версии 1.8.8, до которой я обновился. 2. Предполагая, что в версии 1.8.8 нет ошибок, могу ли я сделать что-нибудь еще, чтобы потенциально устранить эту проблему и обеспечить постоянное принятие моих сертификатов?

РЕДАКТИРОВАТЬ: - Мне удалось избавиться от ошибки «имя хоста», изменив имя хоста моего самозаверяющего сертификата на числовой IP-адрес. Однако все остальные симптомы остаются, в том числе загадочное «В сертификате есть неизвестная ошибка». - Я убежден (хотя комментарии говорят об обратном), что обновление 1.8.8 что-то сломало в Mac OS X, и очень заинтересован в откате версий для дальнейшего устранения неполадок. Но я полагаю, что это новый вопрос...


ssl-certificate svn
person Daniel Widdis    schedule 01.03.2014    source источник
comment
Я смог выяснить, как вернуться к Subversion 1.8.5 по этой ссылке: trac.macports. org/wiki/howto/InstallingOlderPort и возврат к версии 1.8.5 решил проблему.   -  person Daniel Widdis    schedule 01.03.2014
comment
И последнее дополнение: по-видимому, была ошибка при использовании subversion 1.8.8 и serf 1.3.2 и более ранних версий. Обновление serf до 1.3.4 решило проблему, поэтому теперь я использую последнюю версию как subversion, так и serf.   -  person Daniel Widdis    schedule 04.03.2014

Ответы (3)


arrow_upward
7
arrow_downward

Как ни странно, буквально день назад была аналогичная проблема. В любом случае, я могу ошибаться, но видимый уровень безопасности для SVN в 1.8.8 выше, чем в предыдущих версиях. Какие сертификаты, которые вы заставили принимать svn, могут больше не быть «приемлемыми» по новым стандартам. Я был неправ, но это не имеет значения.

Если вы посмотрите на предоставленную вами ошибку, вы увидите:

Имя хоста сертификата не совпадает.

Это ошибка SSL, которую svn не будет игнорировать, она означает, что вы подключаетесь к другому имени хоста, чем то, что вы указали. Дело в том, что хотя https://192.168.100.59:443 может ссылаться на тот же URL-адрес, что и ваш сервер репозитория, например: https://foobar.com:443 рукопожатие SSL завершится ошибкой, поскольку имена хостов не совпадают.

Эта проблема сохраняется в любом случае, когда URL-адрес вашего репозитория не соответствует имени хоста, указанному в сертификате сервера SVN.

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

Обратите внимание: вы все равно получите это первое диалоговое окно с предупреждением о том, что вы используете сертификат, который не проверен/действителен, но вы не должны получать это второе диалоговое окно. Кроме того, убедитесь, что и клиентская, и серверная версии SVN одинаковы, разные версии SVN вызывают большой хаос.

Изменить:

Извините, я прочитал ошибку задом наперед, имя хоста вашего сертификата, по-видимому, 571458-tools1, хотя должно быть 192.168.100.59, если вы хотите получить к нему доступ. Выполните те же действия по регенерации сертификата, что и выше, но используйте имя хоста 192.168.100.59 вместо 571458-tools1.

Обратите внимание, что это позволит соединениям SSL/TLS работать только при прямом использовании внутреннего IP-адреса.

person initramfs    schedule 01.03.2014
comment
1.8.8 не имеет более строгих требований к сертификатам. Это не должно измениться для пользователей Mac с 1.8.8. Windows была изменена, чтобы она могла использовать системный список доверенных корневых сертификатов. OS X по-прежнему использует не список доверенных сертификатов в цепочке ключей, а список сертификатов, которым доверяет openssl, чего на Mac обычно нет. Это причина того первого запроса. - person Ben Reser; 01.03.2014
comment
@BenReser Хорошо, спасибо за информацию об этом. Но совершенно очевидно, что OP использует самозаверяющий сертификат, независимо от того, использует ли Mac свою цепочку ключей (или это был ключ?) Сертификаты или сертификаты openssl. Первое приглашение вызвано целой группой сбоев: ненадежный, несоответствующий домен и какая-то общая неизвестная ошибка. - person initramfs; 01.03.2014
comment
CPU Terminator, спасибо за совет, но, похоже, это не помогает, потому что я захожу через vpn, поэтому числовой IP-адрес — это единственное имя хоста, которое у меня есть для целевой машины. Использование полного URL-адреса 571458-tools1.mycompanyname.com дает совершенно другой IP-адрес. Я попытался подписать сертификат только числовым IP-адресом, и в результатах нет никакой разницы. - person Daniel Widdis; 01.03.2014
comment
@DanielWiddis Вы говорите, что обращаетесь к хранилищу с буквальным IP-адресом, указанным в сертификате? Потому что svn, видимо, думает, что это не так. Вся основа SSL/TLS должна быть (относительно) трудной для вмешательства. Если ваша VPN разрешает прохождение другого трафика SSL/TLS, я не могу представить, какие это могут быть проблемы. - person initramfs; 01.03.2014
comment
@CPU Terminator, да, я подключаюсь напрямую по IP. $ svn info Путь: . Корневой путь рабочей копии: /Users/danielwiddis/Documents/workspace/Ascent-JPPF /svn/Ascent/Ascent-JPPF Относительный URL: ^/Ascent-JPPF Корень репозитория: 192.168.100.59 /svn/Ascent Я пытался подписать сертификат, используя числовой IP-адрес в качестве имени хоста, но безрезультатно. - person Daniel Widdis; 01.03.2014
comment
@DanielWiddis Вы случайно не указали номер порта или https://? Имя хоста должно быть только числовым IP. Кроме того, после прямого использования числового IP-адреса он все еще показывает The certificate hostname does not match.? - person initramfs; 01.03.2014
comment
Да, пробовал только IP. Я также пробовал это с номером порта и почти со всеми другими вариантами, которые я могу рассматривать как попытку устранения неполадок. (К счастью, VisualSVN Server делает изменение сертификатов тривиальным упражнением... просто хотелось бы найти работающую комбинацию!) - person Daniel Widdis; 01.03.2014
comment
Только что попробовал еще раз.... $ svn update Обновление '.': Ошибка проверки сертификата сервера для '192.168.100.59:443': - Сертификат содержит неизвестную ошибку. Информация о сертификате: - Имя хоста: 192.168.100.59 - Действителен: с 1 марта 02:21:16 2014 по Гринвичу до 27 февраля 02:21:16 2024 по Гринвичу - Эмитент: - Отпечаток пальца: BE:C4:65:B6:0E:BD: 5C:EE:F4:DB:A9:E1:EB:AE:B6:BC:43:F2:E7:5E (R)отклонить или принять (t)временно? t На ревизии 46. - person Daniel Widdis; 01.03.2014
comment
давайте продолжим обсуждение в чате - person initramfs; 01.03.2014
comment
Чтобы закрыть цикл, обсуждение в чате подтвердило, что изменение имени хоста устранило эту ошибку, но неизвестная ошибка остается. Вопрос пока открыт. - person Daniel Widdis; 01.03.2014
comment
К вашему сведению, поддержка HTTP-библиотеки Serf Subversion не поддерживает проверку сертификатов с IP-адресами в них. Неон сделал (был по умолчанию до 1.7.x и больше даже не включен в 1.8.x). Я не думаю, что это проблема здесь, но стоит упомянуть. - person Ben Reser; 01.03.2014
comment
Бен, спасибо за комментарии. Я вижу, вы являетесь членом команды разработчиков Subversion. Я смог вернуться к 1.8.5, и проблема исчезла. Дайте мне знать, если есть способ работать с вами, чтобы определить, что отличается в 1.8.8 для моей установки. - person Daniel Widdis; 01.03.2014

arrow_upward
1
arrow_downward

Я смог выяснить, как вернуться к Subversion 1.8.5 по этой ссылке:

trac.macports.org/wiki/howto/Установка старого порта

Возврат к 1.8.5 решил проблему. Я продолжу дальнейшее устранение неполадок с 1.8.8 непосредственно с разработчиками Subversion.

person Daniel Widdis    schedule 01.03.2014

arrow_upward
1
arrow_downward

The certificate has an unknown error может быть проблемой цепочки сертификатов. Я столкнулся с этим после обновления Windows SVN 1.8.3 до 1.8.7. Вы можете найти это, выполнив эту команду: echo | openssl s_client -connect host:443

e.g.

Certificate chain
 0 s:/[redacted]/
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Ошибка здесь в том, что тема 1 не соответствует эмитенту 0. Исправить цепочку сертификатов на сервере.

person Kevin Smyth    schedule 06.06.2014
comment
Ошибка была результатом того, что самозаверяющий сертификат генерировал новый тип ошибки в subversion 1.8.8, которая не обрабатывалась должным образом в версиях serf до 1.3.4, и было несколько дней перекрытия, в течение которых я обновлял свои порты. . Теперь все обновлено и работает. - person Daniel Widdis; 07.06.2014