1 Reply by embhorn

(5 replies, posted in wolfSSL)

So if you are not using the autotools configure command, then you should be configuring with a file called user_settings.h and passing WOLFSSL_USER_SETTINGS to the project building wolfSSL. In this case there will not be an options.h file used.

Go to forum: wolfSSL

2 Reply by embhorn

(5 replies, posted in wolfSSL)

Also, be sure that `WOLFSSL_DER_TO_PEM` is defined using a CFLAG when configuring wolfSSL:

./configure CFLAGS="-DWOLFSSL_DER_TO_PEM"

Go to forum: wolfSSL

3 Reply by embhorn

(5 replies, posted in wolfSSL)

Hi vainn48

Welcome to the wolfSSL forums. Try switching the includes so that the options.h comes before any other wolfSSL headers.

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

Is this for a personal project?

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

4 Reply by embhorn

(2 replies, posted in wolfSSL)

Hi Sunnysunday,

I have requested a review of this topic by our engineers.

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

5 Reply by embhorn

(4 replies, posted in wolfSSL)

With cmake, you want to use the `WOLFSSL_CRL` option:

add_option(WOLFSSL_CRL
    "Enable CRL (Use =io for inline CRL HTTP GET) (default: disabled)"
    "no" "yes;no;io")

Go to forum: wolfSSL

6 Reply by embhorn

(4 replies, posted in wolfSSL)

Hi Happy,

There could be a configuration issue. `HAVE_CRL` needs to be defined in user_settings.h (or `--enable-crl` if using ./configure).

Share your wolfSSL configuration if the issue persists.

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

7 Reply by embhorn

(1 replies, posted in wolfCrypt)

Hi Gabriel,

Thanks for pointing out this issue with the documentation. I've opened a PR here:
https://github.com/wolfSSL/wolfssl/pull/8102

Kind regards,
Eric - wolfSSL Support

Go to forum: wolfCrypt

8 Reply by embhorn

(4 replies, posted in wolfSSL)

Yes, the Zephyr port just builds against the main wolfSSL project, so it will be supported.

Go to forum: wolfSSL

9 Reply by embhorn

(4 replies, posted in wolfMQTT)

For the STM32, you should check out our STM32IDE CubePack for wolfMQTT:
https://www.wolfssl.com/files/ide/I-CUBE-wolfMQTT.pack

Go to forum: wolfMQTT

10 Reply by embhorn

(2 replies, posted in wolfSSL)

Hello Anna,

Welcome to the wolfSSL Forums. We do not currently support MLKEM. I would be glad to assist you in making an official feature request. Please send an email to support@wolfssl.com and I will help you get started.

Kind regards,
Eric - wolfSSL Support

Go to forum: wolfSSL

11 Reply by embhorn

(4 replies, posted in wolfMQTT)

Hi MO380,

FreeRTOS should work with the POSIX interface:
https://freertos.org/Documentation/03-L … 04-pthread

If you want to use the native API, you would need to set up those macros.

Thanks,
Eric - wolfSSL Support

Go to forum: wolfMQTT

12 Reply by embhorn

(2 replies, posted in wolfMQTT)

Hi iskim,

Welcome to the wolfSSL Forums.

The MQTT protocol uses a keep-alive message called a ping to sustain the communication channel between a client and the broker. During the client connect, the keep_alive_sec field is sent to broker, which uses that to determine if the client has lost it's connection. Some brokers use that value (in seconds) times 1.5 to finally disconnect the client. If your client is not sending the ping (or ping response) within the time frame negotiated, then the broker will disconnect the client.

> - Under what circumstances does WolfMQTT trigger a NETWORK error?

A network timeout can occur when the client attempts to read or write data to the network, but the operation takes too long. This is configurable with the timeout_ms parameter when calling MqttClient_NetConnect.

> - Are there any specific configurations or common pitfalls that I should look into to prevent this kind of disconnection?

A network error might not even be on client side. The application should handle network problems gracefully and allow reconnection attempts.


Could you tell us more about your MQTT project and your location for our support records? Feel free to email us at support@wolfssl.com for a more private conversation.

Kind regards,
Eric - wolfSSL Support

Go to forum: wolfMQTT

13 Reply by embhorn

(1 replies, posted in cURL)

Hi Andids

Welcome to the wolfSSL Forums.

Could you tell us a bit about your Curl project and your location for our support records?

Did you review the Cmake instructions?
https://github.com/curl/curl/blob/maste … L-CMAKE.md

Thanks,
Eric - wolfSSL Support

Go to forum: cURL

14 Reply by embhorn

(3 replies, posted in wolfSSL)

Hi Dwayne,

Thanks for sharing these details. AWS has several requirements for TLS versions and extensions. It might be worthwhile to try updating the wolfSSL version. The latest release is v5.7.2

If this is related to a commercial project, you should open a new issue by emailing support@wolfssl.com or through the zendesk portal at https://wolfssl.zendesk.com.

Go to forum: wolfSSL

15 Reply by embhorn

(3 replies, posted in wolfSSL)

Hi Dwayne,

Welcome to the wolfSSL Forums.

Could you tell us a bit about your project and your location for our support records?

There is not a clear error in the log you shared. It could be that the peer sent an alert, but I would have expected to see that recorded in the log. Are you able to generate a packet capture of the failing handshake?

We always recommend using the latest version of the library. Often we have already resolved issues that you may be experiencing.

Is this a new failure that was previously working? Do you know what changed?

Lastly, if you'd prefer, you can open a support ticket by emailing support@wolfssl.com

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

16 Reply by embhorn

(1 replies, posted in wolfSSL)

Hello Victor,

Welcome to the wolfSSL Forums.

We were excited to see ExpressVPN utilize some of our latest developments, DTLS 1.3 in particular:
https://www.wolfssl.com/expressvpn-is-t … a-wolfssl/

And in fact, the lightway-core is open source!
https://github.com/expressvpn/lightway-core

Could you tell us a bit about your project and your location for our support records?

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

17 Reply by embhorn

(3 replies, posted in wolfSSL)

I've requested our business director, Scott McClung, to reach out to set up a call with our engineers. Please keep an eye out for an email.

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

18 Reply by embhorn

(3 replies, posted in wolfSSL)

Hi wirediot,

Welcome to the wolfSSL Forums. Could you tell us a bit about your project using wolfSSL and where you are located for our support records?

The default cert verification logic in wolfSSL is more stringent (secure) than other SSL libs in that we require the root CA to be loaded, as opposed to verifying the peer cert based on any cert that matches. You can loosen this requirement by enabling the define WOLFSSL_ALT_CERT_CHAINS.

https://github.com/wolfSSL/wolfssl/blob … .c#L33-L37
* WOLFSSL_ALT_CERT_CHAINS:
*     Allows CA's to be presented by peer, but not part of a valid chain.
*     Default wolfSSL behavior is to require validation of all presented peer
*     certificates. This also allows loading intermediate CA's as trusted
*     and ignoring no signer failures for CA's up the chain to root.

So to answer your questions:

1. Is this implementation in accordance to RFC?  what part of RFC does this comply to that we need to absolute load "A"?

Yes

2. What changes are needed in embeddedSSL if we just need to validate using B or C?

See discussion above.

3. from a security perspective, I understand both are secure and loading A does not mean it is more secure, but isnt B or C more likely to be revoked rather than A?

Root certs are much less frequently revoked, but it can happen. Which is why things like OCSP exist.

5. if there are multiple flavors of B and C, wouldn't it be safer to just load A and let device validate B/C/D through chain validation?

Yes!

5. do we know if all the SSL clients operate same way (openSSL, mbedTLS, etc)?

They are definitely different.

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

19 Reply by embhorn

(1 replies, posted in wolfMQTT)

Hello valschroeder

Welcome to the wolfSSL Forums. Yes, wolfMQTT sounds like a great fit for your project!

We have lots of example projects in the library. I'm not sure what you mean by "manual work to handle incoming messages". The client subscribes to a topic and messages are received.

Could you tell us a bit about your MQTT project and where you are located for our support records?

Thanks,
Eric - wolfSSL Support

Go to forum: wolfMQTT

20 Reply by embhorn

(4 replies, posted in wolfCrypt)

Hi gabriel,

Welcome to the wolfSSL Forums. Could you tell us a bit about your project using wolfSSL and where you are from for our support records?

We have a benchmarking tool that will be of interest to you:
https://github.com/wolfSSL/wolfssl/tree … /benchmark

The ED448 sign operation does perform a hash also:
https://github.com/wolfSSL/wolfssl/blob … 448.c#L355

The "ph" is for pre-hashed, signifying that the message is pre-hashed before the signature calculation.

Thanks,
Eric - wolfSSL Support

Go to forum: wolfCrypt

21 Reply by embhorn

(9 replies, posted in wolfCrypt)

Is the compiler in the environment path? Can you invoke it from the command line right there?

Go to forum: wolfCrypt

22 Reply by embhorn

(1 replies, posted in wolfSSL)

Hi DDaugher

Welcome to the wolfSSL Forums.

Yes, AES-GCM is a good candidate. You can check out the wolfSSL crypto benchmarking tool to get a better idea of throughputs.
https://github.com/wolfSSL/wolfssl/tree … /benchmark

We also have several excellent examples in this other repository:
https://github.com/wolfSSL/wolfssl-examples
https://github.com/wolfSSL/wolfssl-exam … crypto/aes

Could you tell us a bit about your project? Feel free to email us at support@wolfssl.com for a more private conversation.

Thanks,
Eric - wolfSSL Support

Go to forum: wolfSSL

23 Reply by embhorn

(9 replies, posted in wolfCrypt)

Can you try using WSL to install the PPC compiler and build the wolfSSL lib there?

Go to forum: wolfCrypt

24 Reply by embhorn

(9 replies, posted in wolfCrypt)

I'm not going to say its impossible, but certainly it will be more straightforward on Linux.

Go to forum: wolfCrypt

25 Reply by embhorn

(9 replies, posted in wolfCrypt)

When you set up the cross compilation in the configure step, the tools will have that macro available.
https://www.wolfssl.com/documentation/m … ss-compile

Go to forum: wolfCrypt