And you are using commit 87eb3ad from the GitHub repository?

Correct, you only need the root CA. The other intermediate signers should be in the certificate chain with the peer certificate.

For OCSP stapling, the client should be getting the OCSP response record, signed by the root CA (or its delegate), during the handshake. The OCSP response should be for the server's certificate. (And the response should be the same blob of data you would get if you requested the status directly from the OCSP service listed in the peer's certificate.)

You'll need to supply a custom verify callback function. The verify callback is passed the error type and it gives you a chance to force a success or failure depending. See our API manual for the functions wolfSSL_set_verify() or wolfSSL_CTX_set_verify().

This was due to a misreading of RFC 6347 section 4.2.2. This has been recently fixed in our GitHub repository, commit 6d520e0.

For the first case with the wolfSSL based server and OpenSSL s_client, this is exactly what I expect to happen. The OpenSSL client is telling you that it doesn't like the certificate the server gave it, but since it is a test client it continues with the connection. Note the verify errors:

depth=0 /C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
verify error:num=21:unable to verify the first certificate
verify return:1

As to the second case with the wolfSSL based client and OpenSSL s_server: According to Note 1 in our README file, "wolfSSL also no longer supports static key cipher suites with PSK, RSA, or ECDH." In your example, you are using the cipher suite AES128-SHA, which is a static RSA cipher suite. To get it to work you need to "#define WOLFSSL_STATIC_RSA" in your build.

Billy Bob:

In your callback for pcap_loop() are you accounting for the size of the ethernet header?

Our sniffer test code main function we have a variable called frame. It is normally set to 14, which is the size of the Ethernet frame header. (Or 4 if using a no-link interface.) The first thing that happens after receiving a packet from pcap_next() is the test adjusts the packet pointer past the ethernet frame header to the IP header (and adjusts the packet size accordingly) and then calls ssl_DecodePacket().

If the header isn't skipped, then the IP version number will be wrong as it is looking at part of the ethernet hardware address.

Billy Bob:

It kind of looks like the filter isn't working on the PCAP loop. Since it is working with pcap_next(). The sniffer is assuming that the data passed to it starts with the IP frame, not with any link local headers.

Can I ask about your project? How are you using the sniffer?

--John

Deepti:

I see that you also sent in a message to support@wolfssl.com. My colleague is helping you via that message chain.

Commonly, when we see and error -188, it is because the correct CA certificate for the peer wasn't loaded. For example, you can't use our CA certificate that is included with USE_CERT_BUFFERS_2048 to contact Google's server. (And I've seen a couple different certificate chains from Google that required different CA certificates.)

wolfSSL has two PRNG functions that can be selected at build time: ARC4 using the entropy source (GenerateSeed() function) to provide a key or a SHA-256 Hash_DRBG (described in NIST SP 900-80A) seeded with the entropy source. If you are using "configure" to set up your build, the Hash_DRBG is enabled by default. If you are building through Visual Studio, the ARC4 PRNG is used.

The entropy seed for either PRNG is obtained with the GenerateSeed() function. There are several GenerateSeed() example functions in file random.c, most of which can be used depending on your environment. On Linux or Mac OS X, "/dev/urandom" is read for the seeding. On Windows, the equivalent source is read. Some of the embedded processors have their own built in hardware entropy sources and we call their API. If we don't have an example that suits your needs you have to provide your own GenerateSeed(), and we can help with that.

For QNX you could set the flag "HAVE_HASHDRBG" and use the Linux-style GenerateSeed() reading from /dev/urandom.

I hope this helps.

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?