Since approximately start of October, I get this message when running any command with remote access to a git repo (e.g. git pull) on the same machine as the server runs on (i.e. on mygitbucketurl host):
fatal: unable to access 'https://mygitbucketurl/repourl/': server certificate verification failed. CAfile: none CRLfile: none
This is on an Ubuntu 20.04.3 machine; I am running this against my own gitbucket server which is behind an apache2 reverse proxy for https, using a letsencrypt certificate. I am aware of the recent change in letsencrypt's ROOT CA. However, the strangest thing is that no client running on a host other than the server, but connecting to the same server (same repositories actually) shows this problem (not from a windows client, not from another ubuntu machine).
My server actually does pass tests on ssllabs.com (even though I'm not 100% sure I've done everything correctly here - ssllabs shows 2 paths, and one of them ends in the "DST Root CA X3", "Valid until: Thu, 30 Sep 2021 14:01:15 UTC EXPIRED" - should this be there? or should I be concerned if it is there)?
I've seen this other question and tried the proposed resolution of renewing the trust store; also the current time seems correctly set to me.
So I'm out of ideas what's going on here. Could git somehow be using a different trust store than the Ubuntu system? Why am I only seeing this message when running a client on the same machine that the server runs on, but not on different machines (seems to indicate a client-specific issue; but another machine running the same operating system does not have this problem, and updating the trust store also does not help - what can I further do to debug this?)
Added to answer questions from comments:
mygitbucketurl is the local-network IP of the server machine (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)
As for Workarounds: The quick workaround is of course to set config http.sslVerify=false (per command), and a half-permanent workaround I have applied to one of the affected repositories was to use ssh instead of https. I'd still be interested in the root cause of this, though.
