Hi Hans-Jürgen,

The problem you are running into is being caused by the RSA key size.  root.crt uses a 4096-bit RSA key.

One of the less portable aspects of fastmath is the need for fixed buffers to reduce dynamic memory use.  By default, these buffers allow a 2048 bit X 2048 bit multiply into a 4096 bit buffer.  Since most sites are using 2048 bit RSA keys this is fine.  But for those sites that have a 4096 bit RSA key you'll need to increase the fastmath buffer size to 8192.  Since root.crt uses a 4096-bit RSA key, you'll need to increase the fastmath buffer size.  You can do this using the define:

FP_MAX_BITS

and setting it to 8192.  Unfortunately, this will also increase the runtime stack use since the buffers used in the public key operations are bigger.

So, try:

cd wolfssl-2.7.0
make clean
./configure C_EXTRA_FLAGS="-DFP_MAX_BITS=8192"
make
wget http://www.cacert.org/certs/root.crt
./examples/client/client -h www.cacert.org -p 443 -v 1 -A root.crt -g

Let me know if that works for you.

Best Regards,
Chris

Hi Amit,

wolfSSL embedded SSL doesn't currently support secure renegotiation, but you could always just set up a new connection and have the client re-connect with a new handshake if the existing connection becomes invalid.

Best Regards,
Chris

Hi Steffen,

I tested wolfSSL_CTX_load_verify_buffer() on my development machine (OS X) with the cert bundle you attached.  This seemed to work - the function returned SSL_SUCCESS.  Can you verify that the context pointer (ctx) you are passing to wolfSSL_CTX_load_verify_buffer() is valid?

Thanks,
Chris

Hi Rainer,

Thanks for taking a look at CyaSSL.  We have tried to make our error codes user friendly.  Typically many of the CyaSSL API functions will return SSL_SUCCESS or SSL_FAILURE, where subsequently the application can call CyaSSL_get_error(...) to retrieve the more specific error code.  Our documentation covers more details about error codes in Chapter 8 (http://yassl.com/yaSSL/Docs-cyassl-manu … gging.html).

In the case of certificate verification, CyaSSL handles all verification internally and will give a -155, ASN_SIG_CONFIRM_E (ASN sig error) if verification of a peer certificate fails.  Optionally CyaSSL allows the application to register its own verify callback which will be called when verification fails.  This callback will be presented a more detailed error code related to the failure reason (dates, signer, etc.).

Our OpenSSL compatibility layer maps roughly 300 of OpenSSL's most commonly used functions to the native CyaSSL API.  It was designed to make porting applications over from OpenSSL easier.  As OpenSSL has over 4,000 functions, it's only a subset and is continually growing as we do more ports into existing applications.  We encourage users to use the native CyaSSL API if possible, as footprint size is increased when enabling the compatibility layer.  I believe that error codes will be the same in either case.

Best Regards,
Chris

Hi Steffen,

wolfSSL doesn't currently support AES-ECB mode of operation.  We do support AES in CBC, CTR, GCM, and CCM modes though.  ECB (Electronic codebook) mode is not regarded as very secure.  If you take a look at the penguin image on the following Wikipedia page under the "ECB" section, you will see that it doesn't hide patterns very well:

https://en.wikipedia.org/wiki/Block_cip … _operation

Best Regards,
Chris

Hi syang,

All of our products, including CyaSSL and wolfCrypt/CTaoCrypt are dual licensed under both the GPLv2 as well as a commercial license.  If your product cannot tolerate the terms of the GPLv2, you would need to purchase a commercial license.

Individual crypto modules fall under the same license model, where you would need to purchase a commercial license if the GPLv2 did not fit into your project.  Please feel free to send us additional licensing questions at licensing@wolfssl.com.

Best Regards,
Chris

We have had many users run wolfSSL in a bare metal (no OS) environment.  Once your bare metal and LwIP environment was set up, wolfSSL should layer in on top of that, yes.

Best Regards,
Chris

Alphonsa,

We have had users compile wolfSSL with a large variety of compilers.  Code Composer studio hasn't come up yet though.  Generally wolfSSL is pretty easy to compile with new compilers, but let us know if you run into any problems.

Best Regards,
Chris

Hi Alphonsa,

I just sent you an email with the porting guide attached.

Best Regards,
Chris

Hi Ezequiel,

I just sent you an email with the porting guide attached.

Best Regards,
Chris

Nitay,

It sounds like you're on the right track with registering your own I/O callbacks.  The callbacks were designed to allow applications to control how they read/write data to/from wolfSSL.  For your Recv callback, you'll just need to pass the encrypted data buffer received over your transport medium to wolfSSL through the provided buffer, "buf", in your callback.  For an example, you can reference the EmbedReceive() function in <wolfssl_root>/src/io.c.

I'm not familiar with IOCP myself, so if I'm misunderstanding what you are trying to do, please correct me.

Best Regards,
Chris