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

Hi renminbi,

This is a very interesting case.  These servers are sending a huge certificate message during the SSL/TLS handshake that exceeds the maximum TLS record size.  The TLS RFC states that the maximum TLS record size should be 16k.  For example, looking at the certificate message sent by www.pcmag.com:443 (IP: 192.33.31.80), it is 19097 bytes.

To work around this with wolfSSL, you will need to do two things:

1) wolfSSL limits the maximum certificate chain depth using the MAX_CERTIFICATE_SZ define.  By default this is set to about 18k.  You can increase this by defining it to a larger value at compile time using CFLAGS.  For example:

$ ./configure CFLAGS="-DMAX_CERTIFICATE_SZ=19456"

2)  Increase our internal define which limits the maximum TLS record size to 16k.  This is called MAX_RECORD_SIZE and located in <wolfssl_root>/wolfssl/internal.h.  You can increase this to something larger than the certificate message received by the server.  19k should be good (19456 bytes).

Keep in mind that increasing MAX_RECORD_SIZE creates a non-conformant build which allows records larger than the max allowed size.  A correct TLS implementation should fragment the large certificate message across multiple TLS records instead of stuffing it into a single record that exceeds the max allowed record size.

Best Regards,
Chris