2012-02-13 111 views
17

我正在管理基于Subversion的构建系统,我们使用自签名ssl作为服务器。所以有时候,我们会因为新机器的添加而导致构建失败,并且无法检出,因为这是第一次让机器联系svn服务器。在颠覆中绕过ssl证书验证

的错误信息是这样的:

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参数卷曲。现在,我们的解决方法是只做一些简单的svn命令,以便我们可以永久回答问题并解决问题......至少在ssl证书再次更改/更新或构建完成另一个新的机。

有人解决了这个问题吗?

感谢提前:)

回答

21

我想你有两个选择;抛出船外的所有注意事项和设置在命令行信任服务器证书和非交互式:

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') 

,另一个选择是使用类似与-showcerts的OpenSSL的s_client.First检查和验证,如果证书已改变之前到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.First与-CApath或与证书验证,看它是否已经改变和/或使用-showcert交叉检查。 (注意:如果需要,替代perl -e'使用MIME :: Base64;打印decode_base64(join(“”,));“)。

+0

谢谢德克。正是我正在寻找的:) – icasimpan 2012-02-20 08:30:35

1

另一种选择是使用expect。使用expect可以模拟接受证书的用户。当其他选项不会时,它将工作。我创建了这个,以便我可以在Dockerfile中从svn下载代码。

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

有两种可能的情况:证书是不可信的,但有效的(即,例如有效的自签名证书),或证书无效(当您通过IP或访问的计算机在局域网上,如从FQDN的局域网外部发出,并且该机器具有颁发给其符号名称的证书)。即使使用--trust-server-certificate选项,svn客户端也不会信任第二种类型的证书。在第二种情况下,我能想到的唯一选择是使用主机文件条目将该机器的IP别名到其内部名称。

插图时的VisualSVN与所有默认选项安装和生成证书机器的符号名称,它发现,我曾经面对的场景二:

LAN机器名MACHINE1运行SVN服务器,它有一个证书安装后发给MACHINE1。您尝试通过其IP地址访问SVN并获取无效的证书错误。

如果可以通过FQDN从局域网外访问MACHINE1,例如svn.domain.com并且您正在连接到FQDN,那么您也会遇到该错误。

在这两种情况下,svn都会抛出无效证书错误。

您可以添加到hosts文件中的条目映射(取决于你在哪里访问它LAN或外部)的名称证书的机器的IP地址发出来:

123.45.67.89 MACHINE1 

和访问SVN通过https://machine1/svn/来规避这种情况。