This is not very friendly to explicitly set the ca file.

Can we dynamically search the system ca file? and then go to set the ca
file to the libcurl.

The following are ca files from golang codebase(this  is what you
mentioned):
```
// Possible certificate files; stop after finding one.
var certFiles = []string{
"/etc/ssl/certs/ca-certificates.crt",                //
Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt",                  // Fedora/RHEL 6
"/etc/ssl/ca-bundle.pem",                            // OpenSUSE
"/etc/pki/tls/cacert.pem",                           // OpenELEC
"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
"/etc/ssl/cert.pem",                                 // Alpine Linux
}

// Possible directories with certificate files; all will be read.
var certDirectories = []string{
"/etc/ssl/certs",               // SLES10/SLES11,
https://golang.org/issue/12139
"/etc/pki/tls/certs",           // Fedora/RHEL
"/system/etc/security/cacerts", // Android
}
```

Thanks,
Zixuan



Yunze Xu <y...@streamnative.io.invalid> 于2023年2月24日周五 02:06写道:

> I've figured out why the Python client does not suffer from this
> issue. I use `strace` to print all system calls. Then I find the
> Python client reads another cert file:
>
> ```
> openat(AT_FDCWD,
> "/usr/local/lib/python3.8/dist-packages/certifi/cacert.pem", O_RDONLY)
> = 6
> ```
>
> The correct cert comes from the `certifi` package.
>
> While the Node.js client first tries to read `/etc/ssl/cert.pem`, then
> tries to read `/etc/pki/tls/certs/ca-bundle.crt` that is the libcurl's
> bundle CA cert location. Both of them don't exist.
>
> ```
> 1828 openat(AT_FDCWD, "/etc/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> 1891 openat(AT_FDCWD, "/etc/pki/tls/certs/ca-bundle.crt", O_RDONLY) =
> -1 ENOENT (No such file or directory)
> ```
>
> Thanks,
> Yunze
>
> On Thu, Feb 23, 2023 at 11:50 PM Yunze Xu <y...@streamnative.io> wrote:
> >
> > Hi all,
> >
> > Currently there are two ongoing releases: Python client 3.1.0 [1] and
> > Node.js client 1.8.1 [2]. Both these two releases depend on the C++
> > client 3.1.2, which fixes an issue that when performing OAuth2
> > authentication with an issuer URL whose protocol is HTTPS, users can
> > configure the tls cert file path to fix it.
> >
> > However, a regression was reported in the vote mail list of Node.js
> > client [2]. In short, since Node.js client 1.8.0, users have to
> > configure the tls cert file path explicitly, while the path could be
> > detected automatically before. Since the Python client is also based
> > on the C++ client and adopts a similar way to build the binaries, I've
> > thought it should suffer the same issue. While the test result shows
> > the Python client works well.
> >
> > So I created a repository [3] to:
> > - Give an example for how to test Python and Node.js clients
> > - Report my test results on various operating systems
> >
> > Please also help verify these two candidate releases.
> >
> > [1] https://lists.apache.org/thread/0mcdfw6ogof2bcl40m9p3gjzwolr8rw2
> > [2] https://lists.apache.org/thread/n8jrg29nmozxqp588dbd8nkm7y18sphf
> > [3] https://github.com/BewareMyPower/pulsar-tls-examples
> >
> > Thanks,
> > Yunze
>

Reply via email to