You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by hayden
Glad to hear it's working for you!
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,
Understood! No worries. In the future, if you would like to discuss support questions in a private channel, please email support@wolfssl.com. You're likely to get a faster response there, too. 
Thanks,
Hayden
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
However, in nginx/src/event/ngx_event_accept.c's ngx_event_accept() function I don't see any wolfEngine debug logs. I've even explicitly added some RAND_bytes() calls that should trigger wolfEngine debug logs, but there's none. I also try loading libwolfengine in ngx_event_accept() the same way I did in main(), but despite ENGINE_by_id, ENGINE_init, ENGINE_set_default, and ENGINE_ctrl_cmd all returning 1 indicating a success, no debug logs are shown.
I'm not familiar with all the details of how nginx is coded, but it's possible that the debug output is getting redirected somewhere (to a log file, or even to nowhere, e.g. using /dev/null).
How can I verify wolfEngine is working properly for nginx, and why aren't wolfEngine debug logs showing up in the nginx event loop?
Build wolfEngine with --enable-debug and then run nginx in the foreground under gdb. Set a breakpoint on we_rand_bytes, which is what should be called by RAND_bytes. If this function doesn't get hit, something's wrong and wolfEngine isn't being used.
Also note that you can change wolfEngine's logging behavior with wolfEngine_SetLoggingCb. In the callback you supply, you could have all wolfEngine logs go to a file, for example.
Thanks,
Hayden
And the wolfEngine user_settings.h.
Hi whloo,
I think there are some differences between the way you and I are building and running the tests. I'm not copying the wolfEngine DLL anywhere. In Visual Studio, you should be able to right click on the "test" project in the wolfEngine solution, go to Debug, and select "Start New Instance." That launches the test program, and all tests pass for me. This is using the wolfEngine and wolfSSL master branches and OpenSSL 1.1.1b.
I'm attaching my updated user_settings.h files for wolfSSL and wolfEngine, respectively, just to make sure we're on the same page. My apologies for leaving out HAVE_PUBLIC_FFDHE earlier!
Thanks,
Hayden
Forgot the attachment!
Hi whloo,
I've modified the user_settings.h you sent and attached it here. You need to remove all defines that aren't mentioned in README.md. Please let me know if this helps resolve the issues you're seeing.
Thanks!
Hayden
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,
Your test program isn't actually using the configuration file you've written, I think. I've attached examples.tar.gz to this message. It contains an example of how to use wolfEngine with a config file and some documentation. Specifically, you're missing this
OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_CIPHERS |
OPENSSL_INIT_ADD_ALL_DIGESTS |
OPENSSL_INIT_LOAD_CONFIG, NULL);and you need to make sure the environment variable OPENSSL_CONF points to your config file. Please refer to the attached examples for more details.
As long as you've built wolfEngine with --enable-debug and you've got
enable_debug = 1
default_algorithms = ALLin your config file, wolfEngine will be used for all algorithms it provides and debug messages should be printed to stderr, indicating that wolfEngine's being used. If you get the configuration file right, you won't need any of this
ENGINE *e;
ENGINE_load_builtin_engines();
e = ENGINE_by_id("libwolfengine");
ENGINE_init(e);
//ENGINE_set_default(e, ENGINE_METHOD_ALL); // so far wolfEngine only outputs logs if this is set
//ENGINE_finish(e);
//ENGINE_free(e);
// print wolfEngine logs
ENGINE_ctrl_cmd(e, "enable_debug", 1, NULL, NULL, 0);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
That's great to hear!
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.laiI 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,
I made an error in that last CMake PR I linked you to. I've fixed it with this new PR: https://github.com/wolfSSL/wolfssl/pull/4379 You'll probably want to pull that change in, too.
Thanks,
Hayden
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
Hey John,
Thanks for checking in. I haven't started work to add the new features we've recently discussed here. To get the ball rolling on that, I have asked our sales rep for your region to reach out about some consulting work. Feel free to reach out to him, too, at paul.dennison@wolfssl.com.
Have a great Sunday!
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.
Glad to hear it's working!
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.
Yes, but I also want the server to force retrieval of an updated response without having a client first request it. Therefore, when the internet becomes available, the server can generate its own OCSP Request and store the response.
Ok, that makes sense. You'd be monitoring the Internet connection in your application, and when it comes back, you want a way to tell the wolfSSL server to reach out to the OCSP responder. I'll have to look around our APIs and see if there's a way to do that. Stay tuned.
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.
My use case does require checking the status of all certificates in a chain, so I would very much like this functionality as part of TLS 1.3. Can you make this happen?
Also, my use case is such that my server may not always have an internet connection. This means that there may not be an OCSP Response when an OCSP Request is made. I would, when there is a connection, like to force sending an OCSP Request so that I can get and store an updated OCSP Response well before the currently stored OCSP Status expires. I do not see how to do that in the current implementation. How is this possible?
I'll talk with the team and get back to you, but yes, I'm quite sure we can add it, from a technical perspective.
As for the second part, if I understand correctly, you essentially want a way to extract the OCSP response from wolfSSL so that you can cache it in your application and check that in the event the internet connection isn't available, right?
Excellent! No problem.
I have confirmed that the zeros in the issuerKeyHash do ultimately stem from the fact that the certificate is self-signed, but I don't think that should matter. I made a change to the code to get around this, and when I run the relevant experiment again, I get a valid cert status back from the OCSP responder because the issuerKeyHash is coherent this time. I'll need to talk with the team and run some more tests to determine if this change can be merged, though. I'll let you know. If you're interested in trying the change out in the meantime, here it is: https://github.com/wolfSSL/wolfssl/pull/3618
wolfSSL - Embedded SSL Library → Posts by hayden
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.020 seconds (95% PHP - 5% DB) with 4 queries