Open Zoey2936 opened 2 months ago
Hi @Zoey2936
Thanks for letting us know about this issue. Could you please test against the latest master and let us know if it works? I tried unsuccessfully to build your Docker file.
Thanks, @embhorn
you can find a curl built with master as base here: https://github.com/ZoeyVid/curl-quic/actions/runs/10287471865 (the "artifacts" Artifact), and no building with master as base still does not work
Thanks @Zoey2936 I was able to reproduce the issue on both the master and v5.7.2-stable. Seems like https://github.com/wolfSSL/wolfssl/pull/7625/files might have introduced the issue.
ok, until it is fixed I will use v5.7.0
Does the certificate have a negative or zero serial number? Those are treated as errors in wolfSSL. You can use CFLAGS="-DWOLFSSL_NO_ASN_STRICT" as a potential solution.
PC-Zoey:~# echo | openssl s_client -connect api.telegram.org:443 -servername api.telegram.org 2>/dev/null | openssl x509 -noout -serial
serial=DF94C51B5A76E3CB
not sure...
so the current solution would be CFLAGS="-DWOLFSSL_NO_ASN_STRICT"?
I tried CFLAGS="-DWOLFSSL_NO_ASN_STRICT" make && sudo make install
but still encounter the same error, I don't use curl, and using wolfssl as library, the code is hosted on gitlab repository
I tried a workaround mentioned by @Zoey2936 switch to commit 8970ff4c34034dbb3594943d11f8c9d4c5512bd5 (where 5.7.0 released) and build from there:
# cleanup previous build
make clean
git ls-files -i -o --exclude-standard | xargs rm -rf
# setup, build and install
./autogen.sh
./configure --enable-sys-ca-certs
make
sudo make install
but I still got the asn parsing error
message :(
is there a way to check wolfssl library version? just to make sure I've compiled and used the appropriate version
Woops, I made a mistake. I didn't aware that I've installed wolfssl (implicitly) from package manager, it might be linked to the library that provided by package manager instead of newly build one
if I run gcc main.c -L ~/path/to/wolfssl/src/.libs/ -lwolfssl
, will it linked with the path from -L or from default path from system /usr/lib or smth? how to make sure which one is linked?
I found ldd command is useful for this purposes:
linux-vdso.so.1 (0x000079bf38ec6000)
libwolfssl.so.42 => /usr/local/lib/libwolfssl.so.42 (0x000079bf38e1f000)
libc.so.6 => /usr/lib/libc.so.6 (0x000079bf38c0f000)
libm.so.6 => /usr/lib/libm.so.6 (0x000079bf38b20000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000079bf38ec8000)
but it seems it not linked to the path where I specify it with -L
alright, I copy the shared library to inline it with c source code, to make it using current dir like: gcc main.c -L. -lwolfssl
mhmm but still linked to the system path
trying with export LD_LIBRARY_PATH=. before execute the binary, the output of LD_DEBUG=libs ./a.out
:
447974: find library=libwolfssl.so.42 [0]; searching
447974: search path=./glibc-hwcaps/x86-64-v4:./glibc-hwcaps/x86-64-v3:./glibc-hwcaps/x86-64-v2:. (LD_LIBRARY_PATH)
447974: trying file=./glibc-hwcaps/x86-64-v4/libwolfssl.so.42
447974: trying file=./glibc-hwcaps/x86-64-v3/libwolfssl.so.42
447974: trying file=./glibc-hwcaps/x86-64-v2/libwolfssl.so.42
447974: trying file=./libwolfssl.so.42
447974: search cache=/etc/ld.so.cache
447974: trying file=/usr/lib/libwolfssl.so.42
447974:
447974: find library=libc.so.6 [0]; searching
447974: search path=./glibc-hwcaps/x86-64-v4:./glibc-hwcaps/x86-64-v3:./glibc-hwcaps/x86-64-v2:. (LD_LIBRARY_PATH)
447974: trying file=./glibc-hwcaps/x86-64-v4/libc.so.6
447974: trying file=./glibc-hwcaps/x86-64-v3/libc.so.6
447974: trying file=./glibc-hwcaps/x86-64-v2/libc.so.6
447974: trying file=./libc.so.6
447974: search cache=/etc/ld.so.cache
447974: trying file=/usr/lib/libc.so.6
447974:
447974: find library=libm.so.6 [0]; searching
447974: search path=./glibc-hwcaps/x86-64-v4:./glibc-hwcaps/x86-64-v3:./glibc-hwcaps/x86-64-v2:. (LD_LIBRARY_PATH)
447974: trying file=./glibc-hwcaps/x86-64-v4/libm.so.6
447974: trying file=./glibc-hwcaps/x86-64-v3/libm.so.6
447974: trying file=./glibc-hwcaps/x86-64-v2/libm.so.6
447974: trying file=./libm.so.6
447974: search cache=/etc/ld.so.cache
447974: trying file=/usr/lib/libm.so.6
447974:
447974:
447974: calling init: /lib64/ld-linux-x86-64.so.2
447974:
447974:
447974: calling init: /usr/lib/libc.so.6
447974:
447974:
447974: calling init: /usr/lib/libm.so.6
447974:
447974:
447974: calling init: /usr/lib/libwolfssl.so.42
447974:
447974:
447974: initialize program: ./a.out
447974:
447974:
447974: transferring control: ./a.out
447974:
447974:
447974: calling fini: [0]
447974:
447974:
447974: calling fini: /usr/lib/libwolfssl.so.42 [0]
447974:
447974:
447974: calling fini: /usr/lib/libm.so.6 [0]
447974:
447974:
447974: calling fini: /usr/lib/libc.so.6 [0]
447974:
447974:
447974: calling fini: /lib64/ld-linux-x86-64.so.2 [0]
447974:
ASN parsing error, invalid input
it print trying file=./libwolfssl.so.42
but at the same time it also print calling init: /usr/lib/libwolfssl.so.42
. mhmmm, so, which version is used based on the log?
same goes for gcc -Wl,-rpath . main.c -lwolfssl
nevermind, using the suggestion mentioned by @Zoey2936 actually works, I just need to make sure that the appropriate compiled library is indeed loaded, and patchelf
come in handy to solve this.
btw, CFLAGS="-DWOLFSSL_NO_ASN_STRICT"
didn't work, I've tried it on master
branch.
I also ran into this, funnily enough also when trying to reach api.telegram.org.
Can confirm that building with -DWOLFSSL_NO_ASN_STRICT added to my cflags fixed it.
I just realize patchelf
command not make my program point to the *.so
file in the current directory, the program still load it from the system path however it works lol (it seems I forgot that I've done make install
before). on my system, the default library name linked each time compile with -lwolfssl
is point to libwolfssl.so.42
thus it's an old one installed from package manager and expected to be error in this case.
Contact Details
zoey@z0ey.de
Version
v5.7.2-stable
Description
curl https://api.telegram.org
curl: (35) SSL_connect failed with error -140: ASN parsing error, invalid input
as errorReproduction steps
No response
Relevant log output
No response