0

git pull大约从 10 月初开始，当我在与服务器运行的同一台机器上（即在 mygitbucketurl 主机上）运行任何远程访问 git 存储库（例如）的命令时收到此消息：

fatal: unable to access 'https://mygitbucketurl/repourl/': server certificate verification failed. CAfile: none CRLfile: none

这是在 Ubuntu 20.04.3 机器上；我正在使用letsencrypt证书对我自己的gitbucket服务器运行它，该服务器位于https的apache2反向代理后面。我知道letsencrypt的ROOT CA最近发生了变化。然而，最奇怪的是，除了服务器之外的主机上没有运行任何客户端，但连接到同一服务器（实际上是相同的存储库）会显示此问题（不是来自 Windows 客户端，也不是来自另一台 ubuntu 机器）。

我的服务器实际上确实通过了 ssllabs.com 上的测试（尽管我不是 100% 确定我在这里所做的一切都正确 - ssllabs 显示了 2 个路径，其中一个以“DST Root CA X3”、“有效期至：星期四，2021 年 9 月 30 日 14:01:15 UTC EXPIRED” - 应该存在吗？或者我应该担心它是否存在）？

我已经看到了另一个问题，并尝试了更新信任库的建议解决方案；当前时间对我来说似乎设置正确。

所以我不知道这里发生了什么。git 会以某种方式使用与 Ubuntu 系统不同的信任库吗？为什么我只在运行服务器的同一台机器上运行客户端时看到此消息，而不是在不同的机器上（似乎表明客户端特定的问题；但另一台运行相同操作系统的机器没有这个问题，并且更新信任库也无济于事-我还能做些什么来调试它？）

添加以回答评论中的问题：

  • mygitbucketurl 是服务器机器的本地网络 IP (192.168 ....)

  • $ ldd /usr/bin/git：

      linux-vdso.so.1 (0x00007fff825d8000)
  libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f2f3b9eb000)
  libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2f3b9cf000)
  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2f3b9ac000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2f3b7ba000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f2f3bdcd000)

至于解决方法：快速解决方法当然是设置 config http.sslVerify=false（每个命令），而我已应用于其中一个受影响的存储库的半永久性解决方法是使用 ssh 而不是 https。不过，我仍然对此的根本原因感兴趣。

4

0 回答 0