Hi sean00mcc,

You need to include the "-lm" for the std math library or use internal DH math using `WOLFSSL_DH_CONST`.

Thanks,
David Garske, wolfSSL

Hi Scotty2541,

The manual is wrong/out of date. If WOLFSSL_TLS13 (--enable-tls13) is set then `wolfSSLv23_server_method` will try TLS v1.3 first and allow downgrade. If you want to disable SSLv3 and TLS 1.0 then make sure these are not defined `WOLFSSL_ALLOW_TLSV10` and `WOLFSSL_ALLOW_SSLV3`.

Thanks,
David Garske, wolfSSL

Hi vysocan76,

It looks like you are using the Standard Peripheral Library, which means you would not define WOLFSSL_STM32_CUBEMX. You might consider switching to the Cube HAL, which is still supported by ST. The SPL is end of life.

Thanks,
David Garske, wolfSSL

Hi vysocan76,

When you updated to the latest wolfSSL release did you pull latest master?

There have been some STM32 fixes after v4.5.0 here:
https://github.com/wolfSSL/wolfssl/pull/2996
https://github.com/wolfSSL/wolfssl/pull/3169

This error "AES_GCM_AUTH_E     = -180,  /* AES-GCM Authentication check failure */" is resolved with those PR's.

For the second issue with DH performance.... Those are complex math operations. You have three options.
1. Normal math (interger.c) don't define USE_FAST_MATH. This uses heap and is the smallest and slowest.
2. Use Fast math (tfm.c) define USE_FAST_MATH. This uses stack and is slightly faster.
3. Use Single Precision (sp_int.c) math. Define WOLFSSL_SP_DH. If you want to leverage CortexM speedups also define WOLFSSL_SP_ARM_CORTEX_M_ASM and it will use the sp_cortexm.c which is your fastest option.

SP build options are documented in the code here:
https://github.com/wolfSSL/wolfssl/blob … _int.c#L42

Thanks,
David Garske, wolfSSL

Hi ykuz,

Make sure you add "WOLFSSL_API" to the header definition of the API, so it is available. Let me know if that doesn't help.

Thanks,
David Garske, wolfSSL

Hi Scotty2541,

There are a few types of session resumption.
1. Session cache on the server side, client uses a session id to determine which resumption. This requires server to store / cache session information.
2. Session tickets where server encrypts blob that client retains and presents it in the TLS session ticket extension. This one uses no resources on the TLS server.

For session ID its on by default unless "NO_SESSION_CACHE" is set. To use it here is an example.

/* Do TLS connect, read and write. */
/* Before shutdown or socket close call... */
WOLFSSL_SESSION* session = wolfSSL_get_session(ssl);

/* On next connect set the session before the TLS connect (wolfSSL_connect). */
wolfSSL_set_session(ssl, session);

For Session Tickets you must enable and optionally set a callback:

static int sessionTicketCB(WOLFSSL* ssl,
                    const unsigned char* ticket, int ticketSz,
                    void* ctx)
{
    (void)ssl;
    (void)ticket;
    printf("Session Ticket CB: ticketSz = %d, ctx = %s\n", ticketSz, (char*)ctx);
    return 0;
}

wolfSSL_UseSessionTicket(ssl);
wolfSSL_set_SessionTicket_cb(ssl, sessionTicketCB, (void*)"initial session");

Here is an example for TLS client resumption:
https://github.com/wolfSSL/wolfssl-exam … s-resume.c

Thanks,
David Garske, wolfSSL

Hi Octopus01,

After the call to `wc_InitCert` you need to set subject, serial number, sigType and key usage for "keyCertSign". See example here: https://github.com/wolfSSL/wolfssl/blob … t.c#L12504

If you are using a self-signed certificate for the client mutual authentication then the server side needs to load this same certificate using `wolfSSL_CTX_load_verify_buffer`.

Thanks,
David Garske, wolfSSL

Hi Octopus01,

Perhaps double check the use of `wolfSSL_CTX_trust_peer_buffer` on the client side. You should be using `wolfSSL_CTX_load_verify_buffer`. The -155 (ASN_NO_SIGNER_E) indicates the provided peer (server in this case) certificate could not be verified. If you want to bypass that check most users alter the `wolfSSL_set_verify` API call to use `WOLFSSL_VERIFY_NONE`, however this will bypass all peer certificate checking, so use it with caution.

Thanks,
David Garske, wolfSSL

Hi akhi_gangwar,

You can debug the certificates being sent using the verify callback.

1. Add build option: WOLFSSL_ALWAYS_VERIFY_CB
2. Set callback function

wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_PEER, myVerify);

3. Pull in code like this to show the certificates: https://github.com/wolfSSL/wolfssl/blob … st.h#L1755

Then you can pinpoint which certificate is causing it.

Another option is to locally test the AWS connection and use Wireshark to view the peer's certificates.

Thanks,
David Garske, wolfSSL

Hi akhi_gangwar,

Can you share the device certificate? Are you sure there are not other certificates in the chain presented that would expire then? AWS provides like 4 certificates in the chain.

Thanks,
David Garske, wolfSSL

Hi eli.hughes,

Thanks for sharing these findings. I also hope other folks on the Cortex M will see this. The SP WOLFSSL_SP_ARM_CORTEX_M_ASM option is quite impressive for RSA/DH/ECC math speedups because it uses hand written assembly.

I will suggest to marketing we make this into a blog post.

Thanks,
David Garske, wolfSSL

Hi srihari,

See section 3 of the user manual:
https://www.wolfssl.com/docs/wolfssl-manual/ch3/

3.6 ECHOCLIENT EXAMPLE
3.3 CLIENT EXAMPLE

These are calling the examples/echoclient and example/client here:
https://github.com/wolfSSL/wolfssl/tree/master/examples

The echo sends data and expects the same data back from echo server.

The simple client sends a Hello and expects a I hear you. It can also use the "-g" option to send a sample HTTP GET.

Thanks,
David Garske, wolfSSL