Sunnysunday,

Can you please let me know a bit about what you are trying to do?  What are your goals?  Is this project out of academic, professional or personal interest?

Warm regards, Anthony

Hi Simone,

Can you try using the supported SSP version 1.7.0?  That is the version specified in the README.md file.
It seems this inquiry is out of professional interest. 
In order to protect your confidentiality, if you have further questions, please send them to support@wolfssl.com. 

Warm regards, Anthony

Can you try version 5.7.4 or the latest of the master branch on gitubhb?  I noticed there have been changes as line 30931 on master has the following:

        "LDR    r6, [%[a], #188]\n\t"

Warm regards, Anthony

Hi Isabelle,

https://datatracker.ietf.org/doc/html/r … tion-4.4.2 has the following pragraph:

Without WOLFSSL_ALT_CERT_CHAINS we expect the proper ordering and no other extra certificates.  With WOLFSSL_ALT_CERT_CHAINS we follow the guidance above.

Warm regards, Anthony

Hello Shinzo,

My name is Anthony and I am a member of the wolfSSL team.

Yes, you are correct.  You'll need to use  MakeCert/SignCert in order to use ECC.

Can you please let me know a bit about yourself and your project? What are you trying to achieve? Where are you geographically located? Is this question out of personal, academic or professional interest?  Are there any organizations associated with this work.  Any information is useful in helping us prioritize your request.

Warm regards, Anthony

Hi volga629,

In the past, we have seen this before, but it was because someone used --enable-fips instead of --enable-fips=ready.  Can you please try again, but this time double checking that you added the =ready ?

Here at wolfSSL we love to know how people in the community are using our code.  Can you tell us a bit about yourself and your project?  Where are you located? What are you goals?  Is this project personal, academic or professional in nature?  Also let us know anything interesting.

Warm regards, Anthony

Hi toni992,

My name is Anthony and I am a member of the wolfSSL team. The short answer is that it happens during the TLS  handshake.

The longer more nuanced answer follows.  From RFC 8466 (TLS 1.3)  https://datatracker.ietf.org/doc/html/rfc8446#section-2 you can see the following:

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*       -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                            + pre_shared_key*  v
                                        {EncryptedExtensions}  ^  Server
                                        {CertificateRequest*}  v  Params
                                               {Certificate*}  ^
                                         {CertificateVerify*}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

The certificate and certificate verify messages are where it happens.

The Certificate message is where the certificate chain is sent to the peer.  The CertificateVerify message is where the signature of the TLS handshake transcript is sent.  The peer verifies the chain and the signature of the TLS handshake transcript.

Please let me know if you would like further clarifications.

This is a great question and here at wolfSSL we love to know about the community member and what they are doing. 

Can you please let us know about your interest in wolfSSL and protocols?  Can you let us know about yourself and your projects?

For example, where are you located?  Can you let us know your goals.

Warm regards, Anthony

HI jlewis,

My name is Anthony and I am a member of the wolfSSL team.

I noticed that the issuer and subject are the same making this a Root CA certificate.  I think you might need a basic constraints extension that states that this is a CA certificate. 

Warm regards, Anthony

Hi ,
My name is Anthony and I am a member of the wolfSSL team.  I'll be helping you on this topic.  Please stay tuned as I will need to ask my wider engineering team.

Warm regards, Anthony

Hi db,

My name is Anthony and I am a member of the wolfSSL team. From what I understand, sigpipe means  the peer closed the socket when there was data still available to read.  This is generally resolved by, on both sides, doing a shutdown (for example, calling wolfSSL_shutdown() ) , checking for WOLFSSL_SHUTDOWN_NOT_DONE, and then doing wolfSSL_shutdown() again.  You can search for WOLFSSL_SHUTDOWN_NOT_DONE in wolfssl/examples/server/server.c and wolfssl/examples/client/client.c to see what I mean.

Warm regards, Anthony

Hi bganjl,

You are correct, we do not have support for that. Can you please email support@wolfssl.com so we can get started on a feature request?  Please reference this forum post when you send the message.

Warm regards, Anthony