обойти проверку SSL-сертификата в Subversion

Question

Я управляю системой сборки на основе subversion, и мы используем самозаверяющий ssl для сервера.Поэтому время от времени мы получаем сбои при сборке, потому что добавлен новый компьютер, и он не может оформить заказ, так как он впервые подключается к серверу svn.

Сообщение об ошибке выглядит следующим образом:

icasimpan ~$ svn ls https://scm.myserver.com/trunk
Error validating server certificate for 'https://scm.myserver.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: scm.myserver.com
 - Valid: from Mon, 05 Dec 2011 00:00:00 GMT until Tue, 11 Dec 2012 23:59:59 GMT
 - Issuer: Terms of use at https://www.verisign.com/rpa (c)10, VeriSign Trust Network, VeriSign, Inc., US
 - Fingerprint: c0:69:f6:67:8d:1f:d2:85:c1:94:9f:59:8e:81:cc:81:3d:1e:44:28
(R)eject, accept (t)emporarily or accept (p)ermanently? 

Что мне обычно нужно, это что-то вроде параметра --insecure to curl.Прямо сейчас наш обходной путь - просто выполнить некоторую простую команду svn, чтобы мы могли ответить «навсегда», и проблема будет решена ... по крайней мере, пока сертификат ssl не будет изменен / обновлен снова, или сборка не будет выполнена на другом новомmachine.

Кто-нибудь решил эту проблему?

Заранее спасибо:)

Answer 1

Я думаю, у вас есть два варианта; выбрасывая всю осторожность за борт и устанавливая trust-server-cert и неинтерактивный из командной строки:

 svn help co
 .... snip....
--non-interactive        : do no interactive prompting
--trust-server-cert      : accept unknown SSL server certificates without
                         prompting (but only with '--non-interactive')

, а другой вариант - использовать что-то вроде openssl s_client с -showcerts, чтобы проверить и проверить, изменился ли сертификат перед вызовом svn, и затем либо очень аккуратно прервать, и позволить человеку сделать суждение, либо что-то грязное - например, использовать -showcert для обновления известного сертификата в ~ / .subversion.

В любом случае - бит неинтуитивной магии находится в файлах в ~ / .subversion / auth / svn.ssl.server / <serverrecord> - для извлечения необходимой вам информации сертификата:

cat <serverrecord> | grep ^MII | base64decode  | openssl x509 -text -inform DER

или что-то вроде

cat <serverrecord> | grep ^MII | base64decode  | openssl x509 -text -inform DER -noout - out current-cert.pem

и может затем использовать openssl s_client с -CApath или проверить с этим сертификатом, чтобы увидеть, изменился ли он, и / или использовать -showcert для перекрестной проверки. (Примечание: подставьте perl -e 'используйте MIME :: Base64; напечатайте decode_base64 (join ("",)); "для base64decode, если необходимо).

Answer 2

Другим вариантом является использование ожидаемого. С помощью ожидаемого вы можете смоделировать пользователя, принимающего сертификат. Это будет работать, когда другие варианты не будут. Я создал это, чтобы я мог загрузить код из SVN в Dockerfile.

#!/usr/bin/expect -f

set svn_username [lindex $argv 0]
set svn_password [lindex $argv 1]
set svn_url [lindex $argv 2]

spawn svn --username=${svn_username} --password=${svn_password} list ${svn_url}
expect "(R)eject, accept (t)emporarily or accept (p)ermanently? "
send -- "p\r"
expect "Store password unencrypted (yes/no)? "
send "no\r"
expect -re "root@.*:\/#"

Answer 3

в ситуации, когда у вас есть другая версия SVN, у которой нет проблем

, поэтому скопируйте: cp -r .subversion / auth ... в .subversion уязвимой системы ...

Answer 4

Существует два возможных сценария: сертификат ненадежен, но действителен (например, действительный самоподписанный сертификат), или сертификат недействителен (например, когда вы обращаетесь к компьютеру в вашей локальной сети по IP или из-за пределов вашей локальной сети) по полному доменному имени, и у этой машины есть сертификат, выданный на его символическое имя). Клиент SVN не будет доверять сертификату 2-го типа, даже если используется опция --trust-server-certificate. Во втором сценарии я могу придумать только один вариант - использовать запись файла hosts для псевдонима IP-адреса этого компьютера и его внутреннего имени.

Иллюстрация сценария 2, с которым я однажды столкнулся, когда VisualSVN был установлен со всеми опциями по умолчанию и сгенерировал сертификат для символического имени машины, которое он обнаружил:

Имя компьютера локальной сети MACHINE1 запускает сервер SVN, и на нем установлен сертификат, выданный MACHINE1. Вы пытаетесь получить доступ к SVN через его IP-адрес и получаете ошибку недействительного сертификата.

Вы также получите эту ошибку, если MACHINE1 доступен из-за пределов вашей локальной сети по полному доменному имени, например svn.domain.com, и вы подключаетесь к полному доменному имени.

В обоих случаях svn выдаст ошибку недействительного сертификата.

Вы можете добавить запись в файл hosts, чтобы сопоставить IP-адрес устройства (локальный или внешний в зависимости от того, откуда вы к нему обращаетесь) с выданным сертификатом имени:

123.45.67.89 MACHINE1

и доступ к SVN через https://machine1/svn/, чтобы обойти эту ситуацию.