Hi rahuld3919,

If you are trying to connect to a server that has a self-signed certificate (server cert is signed by itself), you have two options:

1)  Load the same server certificate into the client as a trusted root certificate.  You can do this using the wolfSSL_CTX_load_verify_locations() API.

2)  Disable peer verification using the wolfSSL_CTX_set_verify() with SSL_VERIFY_NONE.  This will disable verification, and is not recommended.

Best Regards,
Chris

Hi Federico,

wc_PKCS7_EncodeSignedData() cannot currently hash the input content in a loop of smaller chunks.  That function (in ./wolfcrypt/src/pkcs7.c) is currently set up to call wc_HashUpdate() on "pkcs7->content" in to hash one block of size "pkcs7->contentSz".

To modify this function to hash smaller chunks, you would need to implement a loop around wc_HashUpdate() that loops over smaller sizes before setting the "contentDigest" array offsets and calling wc_HashFinal().

Are you able to share more details about the project you are working on?

Best Regards,
Chris

Hi Manoj,

Can you send us examples of the two public keys?  Looking at them may give us some clues as to the difference in formats.

Thanks,
Chris

Hi Ornelas,

wolfSSL falls back to including <sys/socket.h> when no other port layers have been enabled.  Last time we worked with wolfSSL on an Arduino, we created a define called WOLFSSL_ARDUINO.  Are you defining this when compiling wolfSSL?

Further instructions can be found in the following README:
https://github.com/wolfSSL/wolfssl/blob … /README.md

Best Regards,
Chris

Hi Sanjay,

The wolfSSL example client (./examples/client/client.c) uses the following files by default for those functions:

wolfSSL_CTX_use_certificate_chain_file() - ./certs/client-cert.pem
wolfSSL_CTX_use_PrivateKey_file() - ./certs/client-key.pem
wolfSSL_CTX_load_verify_locations() - ./certs/ca-cert.pem

Best Regards,
Chris

Hi Sanjay,

In client_test.c, you are disabling certificate validation when you call:

wolfSSL_CTX_set_verify(ctx,SSL_VERIFY_NONE ,0);

If you remove this line, your client will try to validate the server's certificate, using the root CA cert you have loaded with wolfSSL_CTX_load_verify_locations().  It looks like you have the incorrect CA certificate loaded (at least looking at the server certificate chain from my end.  When I look at your server's certificate chain, I see:

Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=demo.valuepaymentsystems.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

This means that in order to correctly validate the server, you would need to load the root most CA certificate with wolfSSL_CTX_load_verify_locations().  This would be "AddTrust External CA Root".  I have attached this certificate here for you to test.

When I run your test application using the attached certificate, my connection succeeds.  Can you capture a Wireshark trace of your connection and send me the .pcap file for analysis?

Thanks,
Chris

Hi Sanjay,

The wolfSSL example client can be used with the "-e" option to view what cipher suites have been enabled for the given build configuration.  For example:

$ cd wolfssl-x.x.x
$ ./configure <options>
$ make
$ ./examples/client/client -e
DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305-OLD:ECDHE-ECDSA-CHACHA20-POLY1305-OLD:DHE-RSA-CHACHA20-POLY1305-OLD

Do you see "DHE-RSA-AES256-SHA256" in that list?

Can you verify that "client.pem" exists in your immediate directory?  It could also be that "client.pem" includes algorithms or key sizes that wolfSSL has not been compiled to support.  Are you able to share "client.pem"?  If not, can you look and see what algorithms and key sizes are used by that certificate?

Thanks,
Chris

Internally wolfSSL uses the EmbedSend() and EmbedReceive() callback functions in ./src/io.c to send and receive data.  This is where we call the normal BSD send/recv functions by default.  It may help to take a look here and see what the normal socket function is receiving to better understand wolfSSL's error codes as well.

In EmbedReceive() for example, if recv() has set errno to SOCKET_EWOULDBLOCK, SOCKET_EAGAIN, or SOCKET_ECONNREFUSED, we return WOLFSSL_CBIO_ERR_WANT_READ which gets propogated back up to the application layer as SSL_ERROR_WANT_READ from wolfSSL_get_error().

Best Regards,
Chris

By default, our configure script only compiles a shared library, to enable compilation of a static library, use the "--enable-static" option:

$ cd wolfssl-x.x.x
$ ./configure --enable-static
$ make

Best Regards,
Chris

Hi andrey.ribalko,

Thanks for the report.  I'll make a note of this internally and see if we can look getting this resolved.  Are you able to get the rest of the hardware crypto integration working on your STM32F2?

Thanks,
Chris

Hi Nimesh,

It is helpful in cases like this to enable wolfSSL debug logging.  Are you able to do this?  You can enable debug messages by compiling wolfSSL with DEBUG_WOLFSSL defined, then calling wolfSSL_Debugging_ON() as the first wolfSSL API called by your application.

By default, log messages with print to stderr using fprintf().

Thanks,
Chris

Hi kanaziwok,

We are actively developing our TLS 1.3 implementation, but also maintaining and progressing our TLS 1.2 implementation.

There are a couple ways we can add features to wolfSSL and/or wolfSSL JNI.  I can add your request to our feature request list.  This is a list that we get to as our engineering team gets time.  There is no timeline associated with features on this list.

The second option is to add functionality as part of our consulting services.  Do you have a preference between these routes?

Thanks,
Chris