Hi naveen,

Thanks for your interest in our library. The project sounds interesting. Overall its pretty easy, since its all c code and GPLv2.

See these resources:
* wolfSSL Porting Guide: https://www.wolfssl.com/docs/porting-guide/
* wolfSSL FAQ: https://www.wolfssl.com/docs/frequently … tions-faq/

Let us know if you have any issues or questions.

Thanks,
David Garske, wolfSSL

Hi pm_vnct,

Your steps for certificate and key generation look correct. The DER format should be loaded with the `WOLFSSL_FILETYPE_ASN1` option as you are doing. The -4 option is `WOLFSSL_BAD_FILETYPE`, which would happen if the format was invalid.

Here is how the use private key buffer call should look:

wolfSSL_CTX_use_PrivateKey_buffer(ctx, buff, (long)sz, WOLFSSL_FILETYPE_ASN1);

For the connection to work you also need the peer to load the CA as trusted using the wolfSSL_CTX_load_verify_buffer API. You will also need to load the client certificate using wolfSSL_CTX_use_certificate_buffer.

Thanks,
David Garske, wolfSSL

Hi coco21,

Make sure:

1. Your Makefile/build script defines the `WOLFSSL_USER_SETTINGS` macro (CFLAGS="-DWOLFSSL_USER_SETTINGS"). This will make sure the user_settings.h configuration is included and the same build configuration is used.

2. You include <wolfssl/wolfcrypt/settings.h> in your application code prior to any other wolfSSL headers.

Thanks,
David Garske, wolfSSL

Hi pm_vnct,

You are on the right track. If you register IO callbacks using `wolfSSL_CTX_SetIORecv` and `wolfSSL_CTX_SetIOSend`, then return `WOLFSSL_CBIO_ERR_WANT_READ` or `WOLFSSL_CBIO_ERR_WANT_WRITE` it will go up to the original caller wolfSSL_connect, wolfSSL_read or wolfSSL_write. This allows you to check for the return code, do other work and call again.

Here is an example for using the callbacks with want read/write:
https://github.com/wolfSSL/wolfssl-exam … callback.c

Here is an example for non-blocking:
https://github.com/wolfSSL/wolfssl-exam … ing.c#L136

Thanks,
David Garske, wolfSSL

Hi harish.reddy,

We have a good AES CBC example here, which can be adopted to GCM:
https://github.com/wolfSSL/wolfssl-exam … -encrypt.c

Our AES GCM wolfCrypt test is here:
https://github.com/wolfSSL/wolfssl/blob … st.c#L7225

Thanks,
David Garske, wolfSSL

Hi Kit,

The call to generate an ECC shared secret uses an encrypted channel with requires a paired encryption key. The default wolfSSL examples use `atmel_get_enc_key_default`, which is all 0xFF's. You should override this function with your own implementation and key. This can be done at build-time using `ATECC_GET_ENC_KEY`.

If you'd like to use a different slot for the ephemeral key generation you can override at build time with macro `ATECC_SLOT_ECDHE_PRIV` or at runtime by registering a slot allocator using `atmel_set_slot_allocator`.

You can test if its the encryption key by replacing the `atcab_ecdh_enc` with `atcab_ecdh` in `atmel_ecc_create_pms`.

Also the ATECC chips have a watchdog that will occur if the chip isn't put into idle state when done. You'll notice calls to `atcab_idle` in our wolfcrypt/port/atmel/atmel.c to resolve this.

Feel free to email us directly at support@wolfssl.com with your user_settings.h and logs. These emails get directed into our ZenDesk system and I'll make sure and grab the incoming ticket.

Thanks,
David Garske, wolfSSL

Hi faberge,

Thanks for your interest in wolfSSL! It sounds like you are 99% of the way there.

The call to read 5 bytes is to get the TLS header, which indicates the total size of the TLS packet. So the next read will be the remainder of the TLS packet. Perhaps you can share a bit more about the code used in your read and write callbacks? You can find our default IO callback functions here: https://github.com/wolfSSL/wolfssl/blob … io.c#L194.

Make sure you are properly handling a non-blocking case, which you would need to return `WOLFSSL_CBIO_ERR_WANT_READ`.

Another common pitfall (depending on your transport layer) is some stacks require getting the entire packet in which case you'd need to cache the remainder of the TLS packet for the read after the 5 byte header.

If you still need help debugging this please provide debug logs, wireshark trace and code snippets for review. If you'd like to keep those private you can email us directly at support@wolfssl.com and reference this forum link.

Thanks,
David Garske, wolfSSL

Hi Paul,

We will look into supporting this feature. I've started an email thread with another engineer. Your code may be valid, but wolfSSL doesn't yet support the serial number as part of the multi-attrib.

Thanks,
David Garske, wolfSSL

Hi ePaul,

We've pushed an example for using large data with PKCS 7 sign/verify here:
https://github.com/wolfSSL/wolfTPM/pull/32

Thanks,
David Garske, wolfSSL

Hi Paul,

The CSR should not contain a serial number. The serial number is assigned by the CA when it gets signed.

I will however take a look at your example and see if there is an issue that needs fixed around CSR gen with serial number provided.

Thanks,
David Garske, wolfSSL

Hi ePaul,

Thanks for the bug report. I was able to reproduce your issue and identiy the cause. I've pushed a wolfSSL fix for this issue here (https://github.com/wolfSSL/wolfssl/pull/1805). It was a new issue that happened after we added some additional fields to support BusinessUnit.

I'm located in PDT (UTC -7).

Thanks,
David Garske, wolfSSL

Hi ePaul,

To build you'll need to use:

Thanks,
David Garske, wolfSSL