Hi Marvin,

Can you re-test with the current wolfSSL version?  It looks like you were getting an ASN parse error.  We recently fixed an area which had been causing a parse error with some optional constraints.

Thanks,
Chris

Hi Cyberrobot,

Yes, wolfSSL requires that the root CA certificate be loaded in order to verify the peer's certificate.  If there are intermediate certificates in the chain as well, but the peer doesn't send them, wolfSSL will need to have those intermediate certs loaded as well (in order to verify the integrity of the cert chain).

For example, if you have a cert chain that looks like:

RootCA -> IntCA -> Peer

If you only load RootCA into a wolfSSL server, and the peer only sends "Peer", wolfSSL won't be able to verify the chain unless "IntCA" is loaded as well.

It looks like https://www.microsoft.com is signed by the "Baltimore CyberTrust Root".  It looks like you may have the wrong root CA for the microsoft server.  Maybe they updated it after your cert bundle was created?

I usually use the "openssl s_client" command to view the certificate chain for a given server.  For example, to view the cert chain for microsoft.com, you could do:

openssl s_client -connect microsoft.com:443 -showcerts

Which shows the cert chain and the root CA as the "Baltimore CyberTrust Root".

Best Regards,
Chris

Hi,

Can you verify that you have the correct CA certificate loaded for Google?  I have attached the one which works for me.

Thanks,
Chris

Hi Alex,

In Visual Studio, you'll need to add the HAVE_AESCCM define to the list of preprocessor defines in your project properties in order to enable AES-CCM support.

Best Regards,
Chris

Hi Stanleyman,

At the moment, we have only tested it under Linux/Unix and OS X environments.  You may be able to use a unix-like shell for Windows such as Cygwin.

Best Regards,
Chris

Hi pcu,

STM32F2_CRYPTO doesn't have the same problem with multiple block cipher contexts since the functionality of each call is stored into the respective wolfCrypt structure (ie: Aes, Des, etc.).

I don't think a mutex would solve the issue, since the limitation isn't necessarily just with access to the hardware hash module, but more with the internal state of the hash module.

Best Regards,
Chris

Hi Brian,

We have not yet added support for secure renegotiation to wolfSSL embedded SSL.

Best Regards,
Chris

Hi Cache,

We recently updated our SSL Tutorial code.  Can you try again using our most up to date version, available here:

http://www.wolfssl.com/documentation/ss … al-2.1.zip

Thanks,
Chris

Hi zhbn,

See the example referenced in the response to this post:

http://www.yassl.com/forums/topic548-i- … -code.html

Best Regards,
Chris

Hi zhbn,

For an example of using CyaSSL key and certificate generation, you can reference the rsa_test() function in <cyassl_root>/ctaocrypt/test/test.c, specifically the code inside of the CYASSL_KEY_GEN and CYASSL_CERT_GEN #ifdef blocks.

CyaSSL will need to be compiled with --enable-certgen to enable certificate generation and --enable-keygen if you want to do RSA key generation.

Best Regards,
Chris

Hi cyberrobot,

If you define KEEP_PEER_CERT when compiling wolfSSL, you should be able to use the following function to get the CommonName from a CYASSL_X509*:

char*  CyaSSL_X509_get_subjectCN(CYASSL_X509* x509)

Best Regards,
Chris