Hi Samuel,

It looks like you are not enabling our OpenSSL compatibility layer when building curl, this implements EVP_MD_CTX and many other OpenSSL types/functions.  Please share your build settings for wolfSSL and wolfSSL version.  You should be building wolfSSL with --enable-curl to use it with curl.

Thanks,
Kareem

Hi Prabhu,

Our Microchip Harmony library is not licensed under GPL, it has a custom license which you can review here: https://github.com/Microchip-MPLAB-Harm … crochip.md

Please let me know if you have any further questions on this.

Thanks,
Kareem

Copying from zendesk ticket:

When including wolfSSL headers in your application, you must include our build settings (options.h/settings.h) first as follows:

#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/settings.h>

You need to include these headers before all other wolf/OpenSSL headers in all files which include these headers.  Please give it a try and let me know if it helps.

Please rebuild wolfSSL with --enable-debug defined and post debug logs of the server to help confirm what is going wrong.  Please also include your full wolfSSL build settings, ./configure line or user_settings.h.
Is your embedded client running wolfSSL, or something else?

Hi Resarf,

We haven't tried wolfTPM on a Raspberry Pi Pico, but we would expect it to work based on the platform's specs and wolfTPM's requirements.

Which TPM are you planning to use?  Will you be attaching a physical TPM to your Pi?

You will need to build wolfTPM with the appropriate configure option for your TPM, you can find a full description of our configure options here: https://github.com/wolfSSL/wolftpm#buil … nd-defines

Thanks,
Kareem

Hello Mike,

Yes, your understanding of PSK is correct.  I would recommend using PSK with ECDHE for this reason, if feasible.  TLS 1.3 does generally offer forward secrecy, but there are cases where you would want to use PSK only, so it is still offered despite not offering forward secrecy.

You can turn on debug logging in wolfSSL to confirm the key exchange and connection are being completed as expected by building wolfSSL with --enable-debug.  You could also capture a packet dump and open it with Wireshark to confirm everything being sent and received matches your expectations.

You may find our PSK examples and documentation here helpful: https://github.com/wolfSSL/wolfssl-exam … master/psk

Thanks,
Kareem

Hi OptiZle,

The examples include a user_settings.h which is tuned for the ESP32, I would recommend retrying with this.  Our generic user_settings_default.h file is meant as a reference, and is not suitable out of the box for the ESP32.

Yes, we've recently improved our ESP32 support and added support for the S3.  I don't believe this support was present in 5.5.4.  I would strongly recommend upgrading.

Thanks,
Kareem

Hi lazH,

Your code is currently passing in the entire certificate DER to wc_RsaPublicKeyDecode, this won't work as wc_RsaPublicKeyDecode expects just the key.
You will need to call wolfSSL_X509_load_certificate_file followed by wolfSSL_X509_get_pubkey on your certificate to extract the public key.  You can then call wc_RsaPublicKeyDecode on this extracted public key and use it as desired for encryption/decryption.
Check out our full example of this here: https://github.com/wolfSSL/wolfssl-exam … m-certfile

Thanks,
Kareem

Hi ajmal,

You can use our user_settings.h to disable all features which are not needed for your use case.  You can find a documented example of our common settings here: https://github.com/wolfSSL/wolfssl/blob … template.h

For us to give personalized size optimization support, we would need a paid support agreement in place.  If you are interested, please let me know where you are located, and I will connect you with your region's sales rep.

Thanks,
Kareem

Hi m_u_h,

To force a failed FIPS POST state, build wolfSSL with HAVE_FORCE_FIPS_FAILURE defined, then at runtime, call wolfCrypt_SetStatus_fips(DRBG_CONT_FIPS_E).

Thanks,
Kareem

Hi singhshikha,

We do rely on some system calls such as closesocket, htons etc.  Please confirm you are linking in your standard library.  If so, you will need to provide wolfSSL with your OS' equivalent to these functions.  We check if our function aliases such as CloseSocket have been defined, which allows you to override them by defining them in your user_settings.h:

#define CloseSocket(s) YourCloseSocketFn(s)
#define XHTONS(a) YourHtoNsFn((a))
#define XINET_PTON(a,b,c)   YourInet_PtonFn((a),(b),(c))
#define DTLS_RECVFROM_FUNCTION YourRecvFromFn
#define DTLS_SENDTO_FUNCTION YourSendToFn

If you don't have any of these functions, you'll need to define a wrapper function instead which provides equivalent functionality.
setsockopt, getpeername and getsockopt are currently called directly in our code and can't be overridden.
WSAGetLastError is coming from USE_WINDOWS_API, don't define this if you don't have Windows API support.

If you continue to run into issues, please reach out to us at support AT wolfssl DOT com with your user_settings.h.  It would also be helpful to know what kind of system calls your OS has available.

I recommend upgrading to our latest release 5.6.0 when feasible for the best support and performance.

Thanks,
Kareem

Hello avlec,

Yes, this is expected.  As part of certificate validation, we ensure that the current system time falls between the notBefore and notAfter dates from the certificate.  To perform this check, the system time must be set correctly before running wolfSSL.
We get the current system time using gmtime_s, gmtime_r or gmtime, depending on which is available on the system.  It's possible that glibc supports a gmtime call which musl does not, which is causing the behavior difference you are seeing.
You can run strace on your application to confirm which time call we are using, and whether it is returning a valid date.

Thanks,
Kareem