Проверка обхода ssl сертификата в подрывной деятельности

Я управляю системой построения на основе 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?

Мне обычно нужно что-то вроде параметра --incecure для завивки. Прямо сейчас наше обходное решение состоит в том, чтобы просто выполнить некоторую простую команду svn, чтобы мы могли ответить "навсегда", и проблема была решена... по крайней мере до тех пор, пока сертификат ssl не будет снова изменен/обновлен или сборка не будет выполнена на другом новом машина.

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

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

Ответ 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; print decode_base64 (join ("",));' для base64decode, если необходимо).

Ответ 2

Другой вариант - использовать expect. Используя ожидание, вы можете имитировать пользователя, принимающего сертификат. Он будет работать, когда другие варианты не будут. Я создал это, чтобы загрузить код из svn в файл Docker.

#!/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 "[email protected]*:\/#"

Ответ 3

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

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

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

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

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

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

123.45.67.89 MACHINE1

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