Hi,

Can you please try applying the attached patch to the wolfSSL source code and see if it resolves the linker failures? I was able to reproduce the same errors locally on my dev machine, using the same files you used in your first message and toolchain. I resolved them with this patch.

Thanks!

Hayden
wolfSSL Software Engineer

Hi whloo,

That's great! I'm glad you're up and running now.

Would you mind sharing a bit about the project you're working on with wolfEngine? We're always interested to see how our products are being used in the wild.

Thanks,

Hayden

And the wolfEngine user_settings.h.

Forgot the attachment!

Hi,

Does your application support using an OpenSSL configuration file already? If so, then no changes to the code are required. Just write the config file and point to it with OPENSSL_CONF. If it doesn't support a config file, then I don't see a way to get wolfEngine support without touching the source code.

Thanks,

Hayden

Hi whloo,

Thanks for your detailed message. As a first step, I suggest we try to get wolfssl64.sln building without touching user_settings.h, as you initially tried. I'm not able to reproduce the errors you're encountering, unfortunately. Can you send me your user_settings.h? I want to make sure it's identical to mine. I would also suggest you start from scratch, download wolfSSL 5.0.0 from here https://github.com/wolfSSL/wolfssl/rele … .0-stable, and rebuild the wolfssl64 solution.

Thanks,

Hayden Roche
wolfSSL Software Engineer

Hi,

On Mac, the extension will be .dylib rather than .so:

haydenroche@Haydens-MBP:~/wolfEngine$ ls .libs
total 488
-rwxr-xr-x  1 haydenroche  staff   37624 Nov 16 11:26 bench
-rwxr-xr-x  1 haydenroche  staff  203288 Nov 16 11:26 libwolfengine.1.dylib
lrwxr-xr-x  1 haydenroche  staff      21 Nov 16 11:26 libwolfengine.dylib -> libwolfengine.1.dylib
lrwxr-xr-x  1 haydenroche  staff      19 Nov 16 11:26 libwolfengine.la -> ../libwolfengine.la
-rw-r--r--  1 haydenroche  staff    1075 Nov 16 11:26 libwolfengine.lai

I just ran the same demo from the webinar on my Mac, and everything appears to work correctly. I recommend configuring wolfEngine with --enable-debug so that you can see wolfEngine's being used.

Let me know if you have any further issues!

Thanks,

Hayden Roche
wolfSSL Software Engineer

Hi Raghu,

What you've discovered here is actually a defect in our CMake build. Thanks for pointing it out! With the autotools build, we parse the environment variables CPPFLAGS and CFLAGS for defines supplied by the user and add anything we find to options.h. The equivalent variable for CMake, CMAKE_C_FLAGS, wasn't being parsed for defines to add to options.h. However, I've just fixed this in this PR: https://github.com/wolfSSL/wolfssl/pull/4368

Could you try applying that PR as a patch to your copy of wolfSSL? Then, you should be able to supply arbitrary defines to the compiler that'll also be reflected in options.h by doing:

cmake -DCMAKE_C_FLAGS="-DYOUR_DEFINE_GOES_HERE" ..

The ".." at the end assumes you're in the directory wolfssl/build/ and the CMakeLists.txt is at wolfssl/CMakeLists.txt.

Thanks,

Hayden

I think the function wolfSSL_CertManagerCheckOCSP *almost* does what you want. The documentation appears to be a bit outdated, though. This results in calls to CheckCertOCSP --> CheckCertOCSP_ex --> CheckOcspRequest, which ultimately sends out the OCSP request to the OCSP responder. However, in CheckOcspRequest, if the status is already cached, no request will be made:

ret = GetOcspStatus(ocsp, ocspRequest, entry, &status, responseBuffer);
if (ret != OCSP_INVALID_STATUS)
    return ret;
...
...
/* code that reaches out to OCSP responder */

So I think we'd need to change this function to accept a new parameter, force, which reaches out to the OCSP responder regardless of whether or not a cached response status for the cert exists.

I've added another CMake option, WOLFSSL_CONFIG_H, to the PR I linked above. Add -DWOLFSSL_CONFIG_H=no to your cmake command to turn off generation of config.h and the definition of HAVE_CONFIG_H.

We strive to keep the CMake and autotools builds roughly equivalent, although the CMake build currently supports far fewer features than the autotools one. Enabling user settings in the autotools build still defines -DHAVE_CONFIG_H, hence why it's the same in the CMake build.

I can add an option to disable both generation of config.h and the defining of HAVE_CONFIG_H. It'll be off by default, for the reason stated above, but you can turn it on at the command line to get the behavior you want. I'll edit this post with the PR once it's up, as well as the command line option to use.

Excellent! No problem.