[Bug]: curl: (35) SSL_connect failed with error -140: ASN parsing error, invalid input

[Zoey2936]

Contact Details

zoey@z0ey.de

Version

v5.7.2-stable

Description

1. Build curl using this Dockerfile: https://github.com/ZoeyVid/curl-quic/blob/latest/Dockerfile
2. run curl https://api.telegram.org
3. get: curl: (35) SSL_connect failed with error -140: ASN parsing error, invalid input as error
4. rebuilt using v5.7.0 and everything works

Reproduction steps

No response

Relevant log output

No response

[embhorn]

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

[Zoey2936]

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

[tmael]

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.

[Zoey2936]

ok, until it is fixed I will use v5.7.0

[tmael]

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.

[Zoey2936]

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...

[Zoey2936]

so the current solution would be CFLAGS="-DWOLFSSL_NO_ASN_STRICT"?

[RealYukiSan]

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

[RealYukiSan]

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

[RealYukiSan]

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

[RealYukiSan]

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.

[FrothyB]

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.

[RealYukiSan]

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.