在颠覆中绕过 ssl 证书验证答案

【问题标题】：bypass ssl certificate validation in subversion在颠覆中绕过 ssl 证书验证
【发布时间】：2012-02-13 08:15:04
【问题描述】：

我正在管理一个基于 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 证书再次更改/更新或构建完成之前另一个新的机器。

有人解决了这个问题吗？

提前致谢:)

【问题讨论】：

标签： svn ssl version-control

【解决方案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

然后可以使用带有 -CApath 的 openssl s_client 或使用该证书进行验证以查看它是否已更改和/或使用 -showcert 进行交叉检查。（注意：如果需要，用 perl -e 'use MIME::Base64;print decode_base64(join("",));' 代替 base64decode）。

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

so copy: cp -r .subversion/auth ...到受影响系统的.subversion ...

【讨论】：

就我而言，我只想在 Docker 上下文中验证一个特定的服务器。基于这个想法，我将使用哈希命名的 SVN 文件复制到 /root/.subversion/auth/svn.ssl.server 文件夹中，它完成了这项工作。

【解决方案4】：

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

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

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

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

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

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

123.45.67.89 MACHINE1

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

【讨论】：