First, the jabber.se certificate expired on May 1st.

Which version of wolfSSL embedded SSL are you using? I'm connecting with the latest commit from GitHub and the altName is not getting ignored. (By the way, add -g to your client command. It'll do an HTTP "GET /" message to the server.)

How are you configuring the library? There was an issue where the altNames were getting lost when you had KEEP_PEER_CERT enabled. (I believe the fix was released in version 3.4.8. It was commit 50e829e.)

Sorry about the delay in responding. That's a good suggestion. Please see commit fe303c97 in our GitHub repository.

On your platform, we're depending on the compiler to make the 64-bit data operations work using its 32-bit registers/math. I'm wondering if it is messing up. I made a little test application that did a couple rotations on my Mac.

#include "wolfssl/wolfcrypt/types.h"
#include "wolfcrypt/src/misc.c"
#include <stdio.h>

int main(void)
{
    word64 test;

    test = 1;
    printf("test = %lu\n", test);
    test = rotlFixed64(test, 33);
    printf("test = %lX\n", test);

    test = 1;
    printf("test = %lu\n", test);
    test = rotrFixed64(test, 5);
    printf("test = %lX\n", test);
}

The output was:

test = 1
test = 200000000
test = 1
test = 800000000000000

Can you try it out, or something like it, on your device?

Are you sure you really want to do that? That's what got a large video game console manufacturer in trouble.

Tangent: It looks like you included "misc.c" in your project. With the way your build is configured, that file is included in the other files that needs it. There is an option to compile it on its own, but you aren't using that, and it is a little faster to not do that. And all the warnings in internal.c shouldn't be there; we added the parens around the assignments that is supposed to hush those warnings.

Which version of wolfSSL are you using right now and did you download it from our website?

Could you try

#define CTAOCRYPT_SLOW_WORD64

OK. I see what's going on here. When running the wolfSSL client connecting to that server, you only need to add the root CA, AddTrustExternalRootCA. The server is sending its certificate, and the signing chain, including a copy of the AddTrust. When processing the Certificate message, wolfSSL ends up ignoring the AddTrust certificate and then checking the next certificate, COMODO RSA Certification Authority. That one is successfully verified and added to the CA pool. The next certificate, COMODO RSA Domain Validation Secure Server CA, is checked and is rejected because the signature fails.

This happens because by default wolfSSL is using fast math which uses preallocated buffers for the big integers, and the size defaults to 4096 to allow for the 2048x2048 bit multiply needed for RSA. The certificate COMODO RSA Certification Authority has a 4096-bit key, so the following RSA signature check fails.

I configured my local wolfSSL build to set FP_MAX_BITS=8192 which will allow for the 4096x4096 bit multiply. (Actually, first I used non-fastmath, then fastmath with with the bigger max bits.) The connection succeeded.

This doesn't answer why the SHA-384 and SHA-512 hash tests fail for you since those are known-answer tests that don't involve RSA or the big integer math. (I'll follow up on that later.)

For places to print out data, you could add prints of the digest at the end of Sha384Update() and run it both on your device and on the desktop and see when they start to differ.

For the "client" command you can only include one certificate with the "-A" option. The command line option processor saves the file name and loads the file later, so only the last file name is saved. If you

cat AddTrustCert ComodorRSACertAuth ComodorRSADomainValidSecureServerCA > combo.pem

and then -A combo.pem, all three will be loaded. (This assumes the certificates are in PEM format. We can't load DER certificates concatenated together.)

Back to the SHA-384 issue. Do you have 64-bit data types available on your platform? Could you do a

printf("sizeof(long long) = %u\n", sizeof(long long));

The SHA-384/512 uses type word64 (unsigned long long) in the internal state. And you deleted the "NO_SHA512" from the MBED settings? You are using the MBED block in settings.h with "#define CYASSL_MBED" uncommented? Setting SIZEOF_LONG_LONG to 8 should be enabling the typedef for word64 in types.h.

For SHA-384, you have to add the following to your settings.

#define CYASSL_SHA512
#define CYASSL_SHA384

Can you connect to the server using our example command line client using only your root CA? (For example, connecting to google.com with the GeoTrust Global CA certificate.)

When the client receives the Certificate message, it should be checking all the certificates in order from last to first. The last one is signed by the root CA, and the first is the peer's certificate. Each one is loaded into the certificate manager and used to verify the next certificate.

You're welcome.

To answer your questions:

It all depends on how fast your hardware is and what cipher suites you are using. The public key cryptography is slow. On a desktop PC you'd probably never see any kind of delay, but on an embedded device the RSA operation could take hundreds of milliseconds. The point in the handshake where your device was timing out was after the public key operations. I don't think Google is timing out; I added in a 3 second delay right before my client sends its Change Cipher Spec message and Google still finished the handshake.

There isn't a timeout on the handshake. If the socket closes then we'll get an error from the recv() and tear down the session.

Public web servers are commonly configured to use anonymous clients without their own certificates. The server would send a Certificate Request handshake message to the client in the non-anonymous case, and from your logs there wasn't any evidence of Google doing that.

This would be accomplished by setting a timeout on the socket, or using non-blocking sockets and calling select() on the socket. Or using custom I/O routines with CyaSSL (wolfSSL).

The wolfssl.sln VS solution wraps the wolfSSL (now wolfSSL) library, and the projects for our example server, client, echoserver, and echoclient, and some of our test tools. The solution builds the wolfSSL library and includes it into the other sub-projects automatically.

Attached is a screen capture of the solution browser on VS Express 2012. I opened the wolfssl.sln solution and it upgraded it from 2008 to 2012, but the layout is still the same. When I'm doing some testing, I'll build the server or client, and VS builds the library dependency first, and then the server, and handles the linking for me. If I were to open the disclosure on the Source Files under the "wolfssl" solution, the library sources would show up.