kevinlul
commented
4 years ago The crux seems to be because the SSL trust store is structured differently between distributions. Debian/Ubuntu use /usr/lib/ssl, the above Red Hat variants use /etc/pki/tls, and Arch variants use /etc/ssl. These paths can be retrieved with openssl version -d. Our vcpkg-compiled OpenSSL chooses /etc/ssl, which generally contains appropriate certificate symlinks on each distribution.
Of note is that on Debian and Arch variants, the certs folder is a massive clutter of various pem files, certificates with hashed file names, and ca-certificates.crt, a concatenation. On Red Hat variants, the certs folder only contains two symlinks and no ca-certificates.crt. On CentOS 8, by symlinking an appropriate ca-certificates.crt to one of the existing files, our embedded libcurl was able to verify the SSL certificate, but not the embedded libgit2.
It is possible to expose some configuration to choose an appropriate certificate file at runtime (entrypoints: libcurl libgit2) to address this problem as suggested.
I'm still investigating to learn about the root of the problem and what the structure of the trust stores means on each distribution, though this will probably require dev environments on these distributions to see if behaviour changes from the Ubuntu-compiled builds and to debug to see what certificates are actually used in the verification process.
edo9300
Fedora and CentOS have a different handling for certificates that don't seem to work with libgit2 by default.