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.

• authIn in a pointer to additional plaintext that is to be authenticated with the plaintext being encrypted

• authTag is a pointer to the authentication tag output

The authTag is the "MAC" authentication tag output for the encrypt function, and it is the "MAC" authentication tag input to authenticate with for the decrypt function. The authIn in both encrypt and decrypt functions is the plaintext that included in the authentication tag with the encrypted data.

In TLS, the authentication tag is the MAC of the plaintext data being encrypted, with the sequence number, TLS record type, TLS record version, and record length.

In the function aesgcm_test(), p is the plain text, a is the additional data to authenticate, c is the expected cipher text, t is the expected authentication tag. t2, p2, c2 are the buffers capturing the output of the encrypt and decrypt functions.

To do the handshake benchmark, you need to use the echoserver and the client with the -b option. And DTLS has to be disabled in the build. (Enabling DTLS forces the echoserver to be DTLS only.)

We don't support DTLS handshake benchmarking at the moment. (But it is on our list.) The problem is that the echoserver won't wait for a new incoming connection until it receives a "break" message from the existing session, or the socket is closed cold. In the TCP benchmark, the sockets are just closed and reopened.

You have to load your own CA certificates. We do not distribute any beyond our own test certificates.

Are you looking at just the exports from the library? Or is your application failing to build? Our compatibility layer is a set of #defines that map the OpenSSL function names to wolfSSL names, like "#define SSL_read wolfSSL_read".

Could you add a print statement to the EmbedReceive() function in file io.c, right after the RECV_FUNCTION() command to print out the value "recvd" and "errno"? (I'm pretty sure it should go into line 243.) It should be working like you expect. Knowing those values would help. Thanks!

The echoserver tutorial will listen() on the TCP socket. When you are using UDP, you don't listen() on the socket ever. Normally on UDP, you just recvfrom() on the socket and process the datagrams as they arrive. If you look at the wolfSSL echoserver, it has this implemented. (Note, the wolfSSL example echoserver is more complicated than the tutorial version.)

The validate date function being used is the one for certificates that is checking for notBefore and notAfter in certificate validity. The one-second window is there for OCSP responses. This detail is on the list of things to address at some point.

Thank you for the suggestion. I agree that should be changed. The newer OCSP configuration functions parallel the CRL configuration functions. I didn't think to move them outside the NO_FILESYSTEM fence. I have this on my list of things to change.

wolfSSL_CTX_OCSP_set_options() and wolfSSL_CTX_OCSP_set_override_url() are better seen as WOLFSSL_CTX functions supporting OCSP, not OCSP functions.

If you look in the header file ocsp.h, you'll see the standalone interface for OCSP. You'll need to include wolfssl/ocsp.h and wolfssl/internal.h (unfortunately, but there is an update planned to merge OCSP in with the stand-alone CertManager with CRL). You'd use it:

{
    int result = 0;
    WOLFSSL_OCSP ocsp;
    
    WOLFSSL_OCSP_init(&ocsp);
    WOLFSSL_OCSP_set_override_url(&ocsp, "http://otherResponder.example.com:8080");
    result = WOLFSSL_OCSP_Lookup_Cert(&ocsp, &dCert);
    WOLFSSL_OCSP_Cleanup(&ocsp);
}