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.

Which "method" function are you using to make your CyaSSL_CTX object?

I can connect to Google with our example client using SSLv3 (0), TLSv1.0 (1), TLSv1.1 (2), and TLSv1.2 (3):

% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 0
% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 1
% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 2
% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 3

And I get the 404 response for each of those, decoded.

Could you capture the network traffic for the connection attempt using Wireshark?

TL;DR: You need to rebuild wolfSSL with MAX_CHAIN_DEPTH set to 12. Given your server's certificate chain, you need to load as CA certificates both the "GeoTrust Global CA" and VeriSign's "Class 3 Public Primary Certification Authority", not the Equinox certificate. And your server's certificate chain has a certificate named "Axeda Systems CA" which is expired.

Red herring. The function DecodeAuthInfo() is parsing the Authority Info Access extension which lists things like OCSP servers. We only parse out the URL for an OCSP lookup. The Certificate Policy extension string you are seeing is output by the function DecodeCertExtensions() when it sees the Certificate Policy extension. There is a SEP profile that uses that extension to put IDs for devices in it. Normally we ignore the extension.

When processing the peer’s certificate chain provided in the Certificate handshake message, we only process up to MAX_CHAIN_DEPTH certificates from the peer; by default that constant is set to 9. The cert chain is:

0: peer cert from Axeda Hosting, signed by GeoTrust SSL CA
1: VeriSign Trust Network, signed by Verisign’s Class 3 Public Primary CA
2: Axeda System CA, self signed
3 to 10: A bunch of VeriSign certificates
11: GeoTrust SSL CA, signed by GeoTrust Global CA

Certificate 11’s Authority Key Identifier is C0:7A:98:68:... which matches the GeoTrust Global CA’s Subject Key ID, not the Equifax certificate you are using as your CA.

When I use our example client to connect to your server with the command

% ./examples/client/client -p 443 -g -h nucleus-connect.axeda.com

I get error -368, Maximum Chain Depth Exceeded. I changed MAX_CHAIN_DEPTH to 12 and get error -188, No Signer. Then I use the GeoTrust Global CA,

% ./examples/client/client -p 443 -g -h nucleus-connect.axeda.com -A GeoTrustGlobalCA.pem

And I also got error -188, No Signer. That was because all the unused VeriSign certificates needed a CA as well. I grabbed VeriSign's “Class 3 Public Primary Certification Authority” certificate from my keychain and appended it to my local copy of the GeoTrust CA in a file called certs.pem. So,

% ./examples/client/client -p 443 -g -h nucleus-connect.axeda.com -A certs.pem

I get error -151, ASN Date Error, Current Date After. One of the certs in the chain has an expired certificate. It looks like certificate 2, "CN=Axeda Systems CA" expired on Jan 7, 2013.

I hope that helps.