Hi rocotocloc -

Yay! nicely done.

One of the things to be aware of for some CDN / load balanced sites such as `google.com` is that a different ISP may have a different cert chain. My ESP32 was connecting directly, my computer via VPN. For example, each would see a different result for:

openssl s_client -connect www.google.com:443 -showcerts -servername www.google.com < /dev/null

The root cause was the FP_MAX_BITS. I had it set to 4096, but that's for only a 2048 bit (the size needs to hold two operands!)

Since some of the certs use RSA, these are needed:

#define HAVE_RSA
#define FP_MAX_BITS (2 * 4096)

I put back your original curl file and confirmed it is working:

https://curl.se/ca/cacert.pem

I have this all resolved in the latest commit on my sample app:

https://github.com/gojimmypi/wolfssl/tr … ssl_client

I realize this is not at all intuitive, so I put together this PR that should make certificate troubleshooting vastly more easy:

https://github.com/wolfSSL/wolfssl/pull/8902

With the PR, when the `FP_MAX_BITS` is found to be too small at runtime, and when `WOLFSSL_DEBUG_CERTS` is enabled, a message such like this will be displayed:

I (15765) wolfssl: TFM fp_exptmod_nct failed: P.used (128) > (FP_SIZE/2); FP_SIZE: 136; FP_MAX_SIZE: 4096
I (15773) wolfssl: Consider adjusting current FP_MAX_BITS: 4096

Answers to your specific questions:

All settings should be in the `user_settings.h`. There should be only one file, located in

[project]\components\wolfssl\include\user_settings.h

See the reference template project:

https://github.com/wolfSSL/wolfssl/tree … s/template

This will be a little tricky, as the registered components don't like to be changed. There will be instruction at build time to convert to a non-managed component.

Oh, some of those were just for testing. Sorry for the confusion there. The one in the working commit, above, should be cleaned up now.

I'm pretty sure this is the RSA and max bit settings.

The wolfSSL setting is `WOLFSSL_ALT_CERT_CHAINS`. Macros with a `CONFIG_`prefix came from the ESP-IDF menuconfig via Kconfig.

- The wolfSSL-related `components/[name]/include` directory should be empty for all components except wolfssl.

There are other components such as wolfssh and wolfmqtt; ONLY wolfssl should have a `user_settings.h` in the respective include directory

- Files in this directory are renamed with `.bak` suffixes when performing publish-time build checks.

This is intended for wolfssl maintainers. I'll make this more clear in future releases. It refereces what happens when components are published to the ESP Registry.

Please let me know if this answers all of your questions or if I can be of further assistance.

I'll be working more on additional `WOLFSSL_DEBUG_CERTS` functionality. Open to suggestions for other diagnostics.

Best Regards & Have a great weekend!

Jim

Hi @rocotocloc

That sounds interesting! Even for just development stage products, we might be able to provide additional pre-sales support to help with integration for your commercial product. I definitely encourage you to send a message to support [at] wolfssl.com

Yes, I understand your reluctance to use a custom toolchain. If you are only talking to a limited number of servers, a fixed PEM certificate is probably the better way to go. Not only is it more standard, but on an embedded device better performance, too.

To clarify: it is only the ESP-IDF build-time-generated Certificate Bundle binary file that is not compatible between mbedTLS and wolfSSL. I believe both properly support a PEM root CA files directly (those not assembled into a single file by the python script). wolfSSL certainly does. For reference, this is the difference:

https://github.com/wolfSSL/wolfssl/blob … dle.c#L152

I'll go reply to the other forum question now regarding the certificate validation failure.

You may also be interested in some other recent changes to wolfSSL for Espressif support, such as this PR updating example for Post Quantum Key Exchange (ML-KELM) support:

https://github.com/wolfSSL/wolfssl/pull/8813

btw - are you using the wolfSSL source directly, or with a Managed Component?

https://components.espressif.com/compon … sl/wolfssl

Best Regards,

Jim

p.s. There are other wolfSSL products that might be useful for your project: wolfSSH, wolfMQTT, wolfTPM

Hi rocotocloc & Anthony,

There are two different types of "Certificate Bundles."

The first is the standard, RFC-compliant format - a simple list of certificates - as Anthony described in his reply. This is the preferred and official method.

The second is Espressif’s (more specifically, mbedTLS’s) custom, proprietary format used exclusively in the ESP-IDF. This format is generated at build time using the gen_crt_bundle.py Python script, located here:

https://github.com/espressif/esp-idf/tr … crt_bundle

Given the error message, I assume this is the Certificate Bundle method you are referring to?

We added support for this Espressif-style Certificate Bundle to wolfSSL last year:

https://github.com/wolfSSL/wolfssl/pull/7936

And just this week, we added improved support for PlatformIO Certificate Bundles:

https://github.com/wolfSSL/wolfssl/pull/8847

Currently, some minor modifications to the ESP-IDF are needed to properly link wolfSSL with the esp-tls library when using Certificate Bundle support. These changes can be found in my fork here:

https://github.com/gojimmypi/esp-idf/tree/my_531

I still need to submit a pull request upstream to add this support to the official Espressif releases. The branch above targets ESP-IDF v5.3.1. Unless otherwise requested, my first PR will aim to port the changes to the latest master (v5.5).

If this is for a commercial product, please feel free to contact us at support [at] wolfssl.com and/or open a GitHub issue.

Thank you for your interest in wolfSSL,

Jim

Edit: for reference here are the files changed between my ESP-IDF branch and upstream:

$ git diff --name-only c8fc5f6 041cd42
.github/workflows/release_zips.yml
.gitignore
README.md
components/esp-tls/CMakeLists.txt
components/esp-tls/Kconfig
components/esp-tls/esp-tls-crypto/esp_tls_crypto.c
components/esp-tls/esp_tls.c
components/esp-tls/esp_tls.h
components/esp-tls/esp_tls_wolfssl.c
components/esp-tls/private_include/esp_tls_private.h
components/esp-tls/private_include/esp_tls_wolfssl.h
components/esp_http_client/esp_http_client.c
components/tcp_transport/transport_ssl.c
package.json
version.txt

That's curious. Just changing the library location should not have made a difference.

Do you have a user_settings.h in some other location? It should really be only in one place: in the component.

Please let me know if there are and suggested changes to the wolfSSL library, or if this was really only an issue in your project.

Note there are some minor post-v5.7.6 changes for the next release: https://github.com/wolfSSL/wolfssl/pull/8641

In any case - YAY! Glad you have it working.

Is this still for your EV Charge Point product? Let me know if you'd like to be in contact with one of the business directors; The 2025 wolfSSL roadmap is coming together, in case you have input on it.

Hi Adam,

Typically the

<wolfssl/options.h>

is not used concurrently with

<wolfssl/wolfcrypt/settings.h>

More importantly: 

<wolfssl/wolfcrypt/settings.h>

needs to be specified before each wolfSSL include file.

Also - the

WOLFSSL_USER_SETTINGS

*MUST* be seen by each of

settings.h

files in wolfSSL.

Typically the odd errors occur when these criteria are not met.

There's additional information and examples here:

https://github.com/wolfSSL/wolfssl/tree/master/IDE/Espressif

Hello Gabriel,

Thank you for providing the source code and additional details.

Now that I see what you are doing, perhaps this will help.

I placed your code in my `wolfssl-gojimmypi\IDE\Espressif\ESP-IDF\examples`directory so that wolfSSL source code would be found in a parent directory. Alternatively, the `WOLFSSL_ROOT` environment variable can be set, as described above. From your log, you probably don't need to move your code.

Please try adding these two lines to the `CryptoAPI` component `CmakeLists.txt` in `esp32-crypto-api\components\CryptoAPI`:

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DWOLFSSL_USER_SETTINGS")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DWOLFSSL_USER_SETTINGS")

There are still a few compile errors, indirectly related to wolfSSL that can be readily addressed, but otherwise successful:

Error    enumeration value 'RSA' not handled in switch wolfssl_IDF_v5.2_ESP32 C:\workspace\wolfssl-gojimmypi\IDE\Espressif\ESP-IDF\examples\esp32-crypto-api\components\CryptoAPI\src\WolfsslModule.cpp 98  
Error    'ret' may be used uninitialized               wolfssl_IDF_v5.2_ESP32 C:\workspace\wolfssl-gojimmypi\IDE\Espressif\ESP-IDF\examples\esp32-crypto-api\components\CryptoAPI\src\WolfsslModule.cpp 399 
Error    'cert_type' may be used uninitialized         wolfssl_IDF_v5.2_ESP32 C:\workspace\wolfssl-gojimmypi\IDE\Espressif\ESP-IDF\examples\esp32-crypto-api\components\CryptoAPI\src\WolfsslModule.cpp 488 

The message you asked about is informative and otherwise ok:

C:/Users/myuser/Documents/CryptoAPI/components/wolfssl is not within IDF_PATH.

It only indicates that the wolfSSL is not an ESP-IDF component.

Please let me know how that goes.

Best Regards,

Jim

Hi gabriel,

I've done PQ on the ESP32, but only the key share part, and prior to the recent NIST approvals. See X/Tweet thread:

https://x.com/gojimmypi/status/1772675517482705379

I also wrote this blog:  https://www.wolfssl.com/post-quantum-ke … sif-esp32/ that might help.

In the tweet thread there's this example code:

            ret = wolfSSL_UseKeyShare(ssl, WOLFSSL_P521_KYBER_LEVEL5);
            if (ret == SSL_SUCCESS) {
                ESP_LOGI(TAG, "UseKeyShare WOLFSSL_P521_KYBER_LEVEL5 success");
            }
            else {
                ESP_LOGE(TAG, "UseKeyShare WOLFSSL_P521_KYBER_LEVEL5 failed");
            }

and this optional config for user_settings.h

#if 1
    #define WOLFSSL_EXPERIMENTAL_SETTINGS
    #define WOLFSSL_HAVE_KYBER
    #define WOLFSSL_WC_KYBER
#endif

Here's a copy of the client code from the tweet thread:

$ ./examples/client/client  -h 192.168.1.38 -v 4 -l  TLS_AES_128_GCM_SHA256 --pqc KYBER_LEVEL5
Using Post-Quantum KEM: KYBER_LEVEL5
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
I hear you fa shizzle!
gojimmypi:/mnt/c/workspace/wolfssl-master

I've been meaning to reach out to Anthony to see what might be different now that NIST has PQ out of "experimental mode". That will depend on the specific version of wolfSSL you are using.

I, too went down the road of liboqs. I don't recall where I saw that, but it is not needed for wolfSSL PQ.

p.s. there's a failly significant upgrade in a recent PR that adds wolfSSL support to the esp-tls layer:

https://github.com/wolfSSL/wolfssl/pull/7936

Good luck with your project! Let us know how it goes & if you encounter any problems.

Cheers

Hi parmstrong3 -

Thanks for taking the new wolfSSL PlatformIO support for a test drive!

Yes, it's true there's currently a lot of room for improvement in the Espressif examples for wolfSSL. See:

https://github.com/espressif/esp-idf/issues/13966

In particular, the esp-tls layer not only adds complexity, but today when selecting wolfSSL using:

idf.py menuconfig

the examples such as esp_http_client do not work properly, as you've seen.

A fix is currently in the works, and more importantly: a vastly superior method of integrating wolfSSL into the ESP-IDF using Managed Components from the ESP Registry. You'll see in the #13966 thread, that Ivan has an excellent solution for allowing the ESP-IDF to "see" a component installed in the local project. There's a partially working example here:

https://github.com/gojimmypi/esp-idf/tree/wolfssl

(the https WIP example is in a different repo)

In the meantime, my best advice is to use wolfSSL directly instead of using the esp-tls layer. See the examples:

https://github.com/wolfSSL/wolfssl/tree … F/examples

I realize these are only using the TLS layer, but the read & writes should be easily adapted to an HTTPS example.

Here's a blog on using the Managed Components:

https://www.wolfssl.com/wolfssl-now-ava … -registry/

If you *really* want to use the eps-tls, the esp-wolfssl needs to be installed manually. As you noticed, it is no longer included in the ESP-IDF. Also note the version there is really quite stale. There's also an unintuitive setting needed, as seen in the esp-tls Kconfig file:

        config ESP_TLS_USING_WOLFSSL
            depends on TLS_STACK_WOLFSSL

So be sure to click the `Include wolfSSL in ESP-TLS` settings to enable the TLS_STACK_WOLFSSL. This too is currently being improved.

I'm completely confident we can get wolfSSL HTTPS working robustly, even though the Espressif examples and the ESP-IDF itself need a little bit of TLC.

Hi Adam,

Oh, I see. One more change is needed. I will append the pull request.

That place where you edited the "FOUND_WOLFSSL"... add these two lines in the "if" that you just edited (the "set" and "return"):

        if( FOUND_WOLFSSL )
            message(STATUS "Found WOLFSSL_ROOT via Environment Variable: ${CURRENT_SEARCH_DIR}")
            set(${OUTPUT_FOUND_WOLFSSL_DIRECTORY} ${CURRENT_SEARCH_DIR} PARENT_SCOPE)
            return()
        else()

I had not noticed that even when finding the environment variable, the logic kept looking anyhow. In may case, it would find wolfSSL, but not because of the environment variable, rather where it was in the parent directory tree.

The problem was the missing "return()" once the environment variable setting was confirmed to be a wolfssl directory.

The log should now look like this:

-- USERNAME = gojimmypi
-- THIS_USER = gojimmypi
-- ************************************************************************************************
-- wolfssl component config:
-- ************************************************************************************************
-- Starting FIND_WOLFSSL_DIRECTORY
-- Found WOLFSSL_ROOT via Environment Variable: C:/test/adam/wolfssl
-- NEW Found wolfssl directory at: C:/test/adam/wolfssl

Let's see if that works for you. Thank you so much for your patience. and persistence.

Cheers

Jim

Hi Adam -

I'm so sorry to hear you are still struggling with the setup. I'll make the instructions more clean on GitHub.

I'll also check the setup script later today.

Can you tell me the exact error you are seeing?

In the meantime, I think the best method is to use the existing examples.

I suggest:

1) Remove the wolfSSL compoenent that was installed to the ESP-IDF with the script.

2) Copy the sample project component directory tree and all files to your `[project root]/components/` directory:

https://github.com/wolfSSL/wolfssl/tree … ts/wolfssl

3) Set an environment variable called WOLFSSL_ROOT (or edit the CMakeLists.txt variable of the same name) to point to the wolfssl source.

For example if you've git-cloned wolfssl from a d:\workspace directory and used the default repo name:

WOLFSSL_ROOT="d:\workspace\wolfssl"

Or see cmake examples:

https://github.com/wolfSSL/wolfssl/blob … ts.txt#L53

Your wolfSSL user_settings.h file would then be in your:

[project]/components/wolfssl/include

Like this one:

https://github.com/wolfSSL/wolfssl/tree … sl/include

Let me know how that goes.  If you still see errors, please post them here or open a GitHub issue.

Best Regards,

Jim

Hi Adam -

Indeed! That's definitely an awesome feature of wolfSSL.

The odd build problems are not a surprise. The source on PlatformIO is not official, and I cannot even confirm it is genuine wolfSSL source. Without seeing your source code, it is hard to say for sure what's going on. I'd like to help.

I'm certain the hardware random number generator is implemented for all of the ESP32 devices. I suspect he problem you are encountering is related to the user_settings.h values.

Is there a serious and compelling reason to use the Arduino platform? I'd like to again emphasize the robustness of the Espressif ESP-IDF. I noticed at project creation time that PlatformIO will use either Arduino or ESP-IDF. If you use the ESP-IDF, we'd be able to help you much more. I'll be working on improving Arduino integration, that's admittedly not great at the moment.

I'd also like to invite you to open any issues on GitHub as appropriate, including one regarding your request for Arduino support:

https://github.com/wolfSSL/wolfssl/issues

Regarding your migration from OpenSSL: we have several engineers on staff that have a great amount of experience with that. Professional engineering and consulting services are available to help you with your implementation.

I'm glad you are making progress on your evaluation and look forward to learning more.

Best Regards

Jim