Svn 在subversion中绕过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? 

我通常需要的是一个类似于旋度的不安全参数。现在，我们的解决方法是只执行一些简单的svn命令，这样我们就可以“永久”地回答，问题就会得到解决……至少在ssl证书再次更改/更新或在另一台新机器上完成构建之前是这样

有人解决了这个问题吗

---

提前感谢：）

我想你有两个选择；从命令行抛出所有警告并设置信任服务器证书和非交互式：

 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调用之前是否已更改，然后非常干净地中止并让人进行判断调用，或者使用-showcerts更新~/.subversion中的已知证书

在这两种情况下，~/.subversion/auth/svn.ssl.server/

中的文件都具有非直观的魔力，可以提取您需要的证书信息：

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

cat | grep^MII | base64解码| openssl x509-文本-通知

或者类似的

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

cat | grep^MII | base64解码| openssl x509-text-inform DER-noout-out current-cert.pem

然后可以将openssl s_客户端与-CApath一起使用，或使用该证书进行验证，以查看其是否已更改和/或使用-showcert进行交叉检查。（注意：如果需要，用perl-e'use MIME:：Base64；print decode_Base64（join（“，）；”）替换Base64解码）。
另一个选项是使用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 "root@.*:\/#"

有两种可能的情况：证书不受信任，但有效（例如，有效的自签名证书），或证书无效（例如，当您通过IP或FQDN从LAN外部访问LAN上的计算机，并且该计算机已向其符号名颁发证书时）。即使使用--trust server certificate选项，svn客户端也不会信任第二种类型的证书。在第二个场景中，我能想到的唯一选项是使用hosts文件条目将该机器的IP别名为其内部名称

当VisualSVN使用所有默认选项安装并生成一个它发现的机器符号名的证书时，我曾经遇到的场景2的插图：

LAN计算机名称MACHINE1运行SVN服务器，它安装了一个颁发给MACHINE1的证书。您正试图通过其IP地址访问SVN，但收到无效证书错误

如果FQDN（例如
svn.domain.com
可以从LAN外部访问该机器1，并且您正在连接FQDN，则也会出现该错误

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

您可以在主机文件中添加一个条目，以将机器的IP地址（LAN或外部，具体取决于您从何处访问）映射到颁发给以下人员的名称证书：

123.45.67.89 MACHINE1

并通过访问SVN来避免这种情况。
在Circtunstance下，您有另一个SVN版本，wich没有问题

因此，将：cp-r.subversion/auth…复制到受影响系统的.subversion…
在我的例子中，我只想在Docker上下文中验证一个特定的服务器。基于这个想法，我将名为的SVN文件复制到/root/.subversion/auth/SVN.ssl.server文件夹中，并完成了工作。