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
