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

Hi Scott,

Thanks for all the information you provided. Since you have commercial support, please open a support ticket by sending a message to support@wolfssl.com using an email account associated with your organization.  In that message, please reference this forum posting.  We look forward to helping you there.

Warm regards, Anthony

Hi MMI_101,

Thanks for using wolfSSL and reaching out to us here on the forums.

In order to be able to use wc_InitCert, you must have the macro WOLFSSL_CERT_GEN defined. I don't know what macros you have defined in your user_settings.h and/or compiler flags, but my best guess is that this is not defined.  If it is defined, please let me know what other macros are defined.

Here at wolfSSL we love knowing how our code is being used.  Can you tell us a bit about yourself and your project?

- Where are you located?  Country and nearest large urban area should suffice.
- It this project out of personal interest, an academic project or commercial in nature?
- Is there an institution or company associated with your work?

Any other details about yourself and your project would be greatly appreciated.

Warm regards, Anthony