Subversion Server SSL 证书验证失败：和其他原因

Posted 2023-03-08

【中文标题】Subversion Server SSL 证书验证失败：和其他原因

【英文标题】：Subversion Server SSL certificate verification failed: and other reason(s)

【发布时间】：2014-03-01 01:29:33

【问题描述】：

我安装了一个 SVN 系统并且工作正常，但最近一次升级后突然停止工作。我的设置：

我有一个使用 VisualSVN Server 2.7.4 托管在 Windows 2008 服务器上的存储库。服务器让我能够随意生成自签名证书，根据需要输入我自己的主机名或其他数据。

我正在使用 Eclipse (Kepler) 在托管机器和我自己的运行 Mac OS X 10.9.1 (Mavericks) 的 MacBookPro 上进行 java 编码。我有 Eclipse 的 subclipse 插件，它需要使用 java HL 进行颠覆。

我已经安装了 macports 和 subclipse 请求的最新 subversion/javahl 包。 Eclipse/subversion 界面似乎工作正常，但存在 Eclipse 不能很好地导航的命令行 subversion 错误。解决命令行错误是主要问题。

我之前通过 macports 安装了以下版本，一切似乎都运行良好：

颠覆@1.8.5_1+通用 颠覆-javahlbindings @1.8.5_0+no_bdb+universal

作为安装/排除不相关问题的一部分，我升级了我所有的 macport，它安装了以下新版本：

颠覆@1.8.8_0+通用 颠覆-javahlbindings @1.8.8_0+no_bdb+universal

升级后，我的 mac 上的 svn via eclipse 失败。我可以通过临时接受证书来通过命令行强制它。它在 Windows 2008 服务器机器上仍然可以正常工作。

第一次更改证书后，我可以选择永久接受，但在这样做之后，它失败并退回到第二个“临时”对话。

$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
(credentials dialogue)
At revision 46.

在此之后，未来的尝试仍会导致错误并要求暂时接受：

$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate hostname does not match.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
At revision 46.

包括本网站和其他网站在内的多个网络搜索都指出 ~/.subversion 中的身份验证文件可能存在问题，但所有建议的解决方案（删除、更改所有权和权限等）都未能解决问题。

具体问题： 1、不知道怎么在macports中恢复到之前的subversion（1.8.5），看看我更新到的1.8.8版本有没有bug。 2. 假设 1.8.8 中没有错误，我还能做些什么来潜在地解决这个问题并让我的证书永久接受？

编辑： - 通过将我的自签名证书主机名更改为数字 IP，我已经能够摆脱“主机名”错误。但是，所有其他症状仍然存在，包括神秘的“证书存在未知错误”。 - 我确信（尽管 cmets 另有说明）1.8.8 升级在 Mac OS X 上破坏了某些东西，并且对回滚版本以进一步排除故障非常感兴趣。但我想这是一个新问题......

【问题讨论】：

我能够通过此链接了解如何恢复到颠覆 1.8.5：trac.macports.org/wiki/howto/InstallingOlderPort 并恢复到 1.8.5 解决了问题。

作为最后的后续行动，显然使用 subversion 1.8.8 和 serf 1.3.2 及更早版本存在错误。将 serf 升级到 1.3.4 解决了这个问题，所以我现在使用的是 subversion 和 serf 的最新版本。

【参考方案1】：

真奇怪，一天前确实有类似的问题。 无论如何，我可能错了，但 SVN 在 1.8.8 的明显安全级别比以前的版本更严格。你强迫 svn 接受的证书可能不再被新标准“接受”。我错了，但这无关紧要。

如果您查看您提供的错误，您会看到：

证书主机名不匹配。

这是一个 svn 不会忽略的 SSL 错误，它意味着您连接到的主机名与您指定的主机名不同。问题是，虽然https://192.168.100.59:443 可能引用与您的存储库服务器相同的 URL，例如：https://foobar.com:443，但 SSL 握手将失败，因为主机名不匹配。

如果您的存储库 URL 的主机名与 SVN 服务器证书响应的主机名不匹配，此问题仍然存在。

我暗示您正在通过 VisualSVN 证书生成工具使用自签名证书。要解决此问题，请重新生成新证书并确保主机名与您的真实主机名匹配。这应该可以解决您的问题。

请注意：您仍然会看到第一个对话框，警告您正在使用未经验证/有效的证书，但您不应该看到第二个对话框。另外，请确保客户端和服务器的 SVN 版本相同，不同的 SVN 版本会造成很大的破坏。

编辑：

对不起，我读错了，你的证书主机名显然是571458-tools1，如果你想访问它，它应该是192.168.100.59。按照上述相同的证书重新生成步骤，但使用主机名 192.168.100.59 而不是 571458-tools1。

请注意，这将允许 SSL/TLS 连接仅在直接使用内部 IP 时工作。

【讨论】：

1.8.8 对证书没有更严格的要求。对于使用 1.8.8 的 Mac 用户来说，这一点应该没有变化。 Windows 已更改，以便它可以使用受信任的根证书的系统列表。 OS X 仍然不使用钥匙串中的受信任证书列表，而是使用 openssl 信任的证书列表，这在 Mac 上通常没有。这就是第一个提示的原因。

@BenReser 好的，感谢您提供相关信息。但很明显 OP 正在使用自签名证书，无论 mac 使用它的钥匙串（还是钥匙圈？）证书还是 openssl 的证书都无关紧要。第一个提示是由一组故障引起的：不受信任、域不匹配和一些一般的“未知错误”。

CPU 终结者，感谢您的建议，但它似乎没有帮助，因为我在 *** 后面访问，所以数字 IP 是我为目标机器拥有的唯一主机名。使用完整的 571458-tools1.mycompanyname.com URL 会提供完全不同的 IP。我试过只用数字 IP 地址签署证书，结果没有区别。

@DanielWiddis 您是说您正在使用证书中提到的文字 IP 访问存储库吗？因为 svn 显然认为你不是。 SSL/TLS 的整个基础是（相对）难以篡改。如果您的 *** 允许其他 SSL/TLS 流量通过，我无法想象这将是一个问题。

仅供参考 Subversion 的 serf HTTP 库支持不支持验证带有 ips 的证书。 Neon 做到了（在 1.7.x 之前是默认设置，甚至不再包含在 1.8.x 中）。我认为这不是问题所在，但值得一提。

【参考方案2】：

The certificate has an unknown error 可能是证书链问题。我从 Windows SVN 1.8.3 升级到 1.8.7 后遇到了这个问题。您可以通过运行以下命令来查找：echo | openssl s_client -connect host:443

例如

Certificate chain
 0 s:/[redacted]/
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

这里的错误是 1 的 subject 与 0 的 issuer 不匹配。修复服务器上的证书链。

【讨论】：

该错误是由于自签名证书在subversion 1.8.8中产生了一种新型错误，在1.3.4之前的版本中没有正确处理，并且有几天重叠期间我更新了我的端口。现在一切都是最新的并且可以正常工作。

【参考方案3】：

我能够通过此链接弄清楚如何恢复到颠覆 1.8.5：

trac.macports.org/wiki/howto/InstallingOlderPort

恢复到 1.8.5 解决了这个问题。我将直接与 subversion 开发人员进一步解决 1.8.8 的问题。