Проверка обхода 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/, чтобы обойти эту ситуацию.