在 Subversion 中绕过 ssl 证书验证

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? 

我通常需要的是类似 --insecure 参数的curl。现在，我们的解决方法是只执行一些简单的 svn 命令，以便我们可以“永久”回答并且问题将得到解决......至少直到 ssl 证书再次更改/更新或在另一个新证书上完成构建机器。

有人解决这个问题了吗？

提前致谢 ：）

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

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 'use MIME::Base64;print Decode_base64(join("",));' 替换 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

在这种情况下，你有另一个 svn 版本，它没有问题，

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

Answer 4

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

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

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

如果可以通过 FQDN（例如 svn.domain.com）从 LAN 外部访问 MACHINE1，并且您正在连接到 FQDN，您也会收到该错误。

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

您可以向 hosts 文件添加一个条目，以将计算机的 IP 地址（LAN 或外部，具体取决于您从何处访问它）映射到证书颁发给的名称：

123.45.67.89 MACHINE1

并通过 https://machine1/svn/ 来规避这种情况。