Hi faberge,

Thanks for your interest in wolfSSL! It sounds like you are 99% of the way there.

The call to read 5 bytes is to get the TLS header, which indicates the total size of the TLS packet. So the next read will be the remainder of the TLS packet. Perhaps you can share a bit more about the code used in your read and write callbacks? You can find our default IO callback functions here: https://github.com/wolfSSL/wolfssl/blob … io.c#L194.

Make sure you are properly handling a non-blocking case, which you would need to return `WOLFSSL_CBIO_ERR_WANT_READ`.

Another common pitfall (depending on your transport layer) is some stacks require getting the entire packet in which case you'd need to cache the remainder of the TLS packet for the read after the 5 byte header.

If you still need help debugging this please provide debug logs, wireshark trace and code snippets for review. If you'd like to keep those private you can email us directly at support@wolfssl.com and reference this forum link.

Thanks,
David Garske, wolfSSL

Hi Paul,

We will look into supporting this feature. I've started an email thread with another engineer. Your code may be valid, but wolfSSL doesn't yet support the serial number as part of the multi-attrib.

Thanks,
David Garske, wolfSSL

Hi ePaul,

We've pushed an example for using large data with PKCS 7 sign/verify here:
https://github.com/wolfSSL/wolfTPM/pull/32

Thanks,
David Garske, wolfSSL

Hi Paul,

The CSR should not contain a serial number. The serial number is assigned by the CA when it gets signed.

I will however take a look at your example and see if there is an issue that needs fixed around CSR gen with serial number provided.

Thanks,
David Garske, wolfSSL

Hi ePaul,

Thanks for the bug report. I was able to reproduce your issue and identiy the cause. I've pushed a wolfSSL fix for this issue here (https://github.com/wolfSSL/wolfssl/pull/1805). It was a new issue that happened after we added some additional fields to support BusinessUnit.

I'm located in PDT (UTC -7).

Thanks,
David Garske, wolfSSL

Hi ePaul,

To build you'll need to use:

Thanks,
David Garske, wolfSSL

Hi AdoraKalb,

That sounds like an issue with not providing enough stack space to the FreeRTOS thread on the xTaskCreate. Try increasing the stack size for that task and let us know if that helps.

Thanks,
David Garske, wolfSSL

Hi kjjy7,

If you are using ./configure you do not need to use user_settings.h. The ./configure outputs a build configuration file to wolfssl/options.h. You can use this file as a template for user_settings.h if you are building the sources directly (without ./configure).

If you are building sources directly then you can define WOLFSSL_USER_SETTINGS and add a user_settings.h file to your include path. There is an excellent template for this here: https://github.com/wolfSSL/wolfssl/blob … settings.h

Thanks,
David Garske, wolfSSL

Hi lupusn00b,

The user_settings.h file is only used when `WOLFSSL_USER_SETTINGS` is defined and is usually used when building the wolfSSL/wolfCrypt sources directly. You asked about only having HMAC+SHA256. It looks like yours is disabling HMAC and SHA256. You should not have the NO_HMAC and NO_SHA256 defined. Also there are a bunch of other defines you'll want for disabling other algorithms.

Here is a good tip: When you run ./configure with your desired options it generates a file in `wolfssl/options.h`. You can use this file as a template for your user_settings.h.

Thanks,
David Garske, wolfSSL

Hi Giovanni,

Have you tried adding `-mlongcalls` to your CFLAGS and CXXFLAGS?

See forum post here:
https://www.esp32.com/viewtopic.php?t=1612

Thanks,
David Garske, wolfSSL

Hi leroyk2,

We have a fix pushed for this here:
https://github.com/wolfSSL/wolfssl/pull/1505

Specifically this line:
https://github.com/wolfSSL/wolfssl/pull … d4937R8575

You may find some of the other improvements in that PR useful as well for the STM32 with CubeMX.

Thanks,
David Garske, wolfSSL

Hi Marco,

The return code from the verify callback allows an error to do overridden. By default the verify callback is only issued in the error case, unless you have `WOLFSSL_ALWAYS_VERIFY_CB` defined. You can use the `store->error` variable to determine the error reason (if one exists). A non-zero return code such a 1 or `WOLFSSL_SUCCESS` allows an error to be overridden. A return value of 0 means continue processing the error in the default way (fail).

For everyones reference the verify callback is set using: `wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_PEER, myVerify);`

Here are some example implementations we use for internal testing of the verify callback:
https://github.com/wolfSSL/wolfssl/blob … st.h#L1361
https://github.com/wolfSSL/wolfssl/blob … st.h#L1404

Thanks,
David Garske, wolfSSL