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?

我通常需要的是像 - 固化参数来卷曲。现在，我们的解决方法是只做一些简单的svn命令，以便我们可以“永久”回答并解决问题...至少在ssl证书再次更改/更新或者构建在另一个新的上完成之前机。

有人解决了这个问题吗？

提前致谢：）

Answer 1

我猜你有两个选择;抛弃所有注意事项并从命令行设置trust-server-cert和non interactive：

 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＆gt;中的文件上。 - 提取您需要的证书信息：

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（“”，））;'for base64decode（如果需要）。

Answer 2

另一个选择是使用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@.*:\/#"

Answer 3

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

我在VisualSVN安装了所有默认选项时遇到的方案2的插图，并为它发现的机器符号名称生成了证书：

LAN计算机名称MACHINE1运行SVN服务器，并且已安装颁发给MACHINE1的证书。您正尝试通过其IP地址访问SVN并获得无效的证书错误。

如果可以通过FQDN从LAN外部访问MACHINE1，例如FocusVisualStyle="{x:Null}"并且您正在连接到FQDN，那么您也会收到该错误。

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

您可以在svn.domain.com文件中添加一个条目，以映射机器的IP地址（LAN或外部，具体取决于您访问它的位置）到颁发的名称证书：

hosts

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

Answer 4

在circtumstance下你有另一个svn版本，没有问题

所以复制：cp -r .subversion / auth ...到受影响系统的.subversion ...

在subversion中绕过ssl证书验证

4 个答案: