New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
configure: check for the capath by default #11987
Conversation
Is this an extract of my open PR? Why not merge the PR then? This one misses some bits. |
How so? I did not read anything about this in your PR? |
My PR introduces CA path support for wolfSSL for the detection, lib and the CLI tool. I have also supplied test case (output) for this. |
Ah yes, now I see that you did a partial of this indeed. Sorry, it was not intended. I just fell over this when double-checking how the capath is (not) used when I merged your #11985 |
I believe my fix is a little different and the more complete ca path (check by default) fix, whilst yours is a partial. |
They intersect, but your does not cover:
|
your wolfssl.c change is not the correct one though, see my change |
You mean |
1aa1c19
to
3922a26
Compare
It is actually necessary for not changing the behavior. Without that change, wolfSSL can't run on a vanilla Debian that has a capath. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable now for me. I can rebase my PR on top of this when merged into master.
Not only on Debian, but everywhere where you have expired or invalid CA cers. Noticed this one as well. |
Sure, I meant "in widely used setups". I just happened to test on Debian. |
This comment was marked as resolved.
This comment was marked as resolved.
The default wolfSSL_CTX_load_verify_locations() function is quite picky with the certificates it loads and will for example return error if just one of the certs has expired. With the *_ex() function and its WOLFSSL_LOAD_FLAG_IGNORE_ERR flag, it behaves more similar to what OpenSSL does by default. Even the set of default certs on my Debian unstable has several expired ones. Assisted-by: Juliusz Sosinowicz Assisted-by: Michael Osipov Closes #11987
... if the chosen TLS backend supports it: OpenSSL, GnuTLS, mbedTLS or wolfSSL cmake: synced Assisted-by: Viktor Szakats Closes #11987
7e5d691
to
ed81eb2
Compare
Thanks @vszakats and @michael-o for your help on this, I have you both credited in the commits as well as @julek-wolfssl. |
... if the chosen TLS backend supports it: OpenSSL, GnuTLS, mbedTLS or wolfSSL cmake: synced Assisted-by: Viktor Szakats Closes #11987
Thanks, I will rebase and rephrase my PR. |
The default wolfSSL_CTX_load_verify_locations() function is quite picky with the certificates it loads and will for example return error if just one of the certs has expired. With the *_ex() function and its WOLFSSL_LOAD_FLAG_IGNORE_ERR flag, it behaves more similar to what OpenSSL does by default. Even the set of default certs on my Debian unstable has several expired ones. Assisted-by: Juliusz Sosinowicz Assisted-by: Michael Osipov Closes curl#11987
... if the chosen TLS backend supports it: OpenSSL, GnuTLS, mbedTLS or wolfSSL cmake: synced Assisted-by: Viktor Szakats Closes curl#11987
... and adapt how wolfSSL uses it.