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 embhorn
Hello AkhiG,
The error message "Not ECDSA cert signature" indicates that the signature check failed on the cert that was being verified. This could happen from a driver issue, a buffer overrun, etc.
Are you able to capture the packets with wireshark when the failure occurs?
Thanks,
Eric @ wolfSSL Support
Hi n_jusic,
I'm not finding much. Here is a mystery post on the openssl forum:
http://openssl.6102.n7.nabble.com/RAND- … 78233.html
You can also implement your own random function and use it to seed wolfSSL.
https://github.com/wolfSSL/wolfssl/blob … main.c#L71
Thanks,
Eric @ wolfSSL Support
Hello ss2009ahnu,
Is this using the wolfCrypt test?
https://github.com/wolfSSL/wolfssl/tree … crypt/test
Could you please post the output from running the test?
Thanks,
Eric @ wolfSSL Support
Hello,
The server uses a callback to set up a session ticket, which will then be sent to the client (if requested using `wolfssl_CTX_UseSessionTicket` API, which is only relevant to the client). You can review the example code.
`wolfSSL_CTX_set_TicketEncCb` API:
https://github.com/wolfSSL/wolfssl/blob … er.c#L2076
example callback:
https://github.com/wolfSSL/wolfssl/blob … st.h#L4052
Kind regards,
Eric @ wolfSSL Support
Hi Scott,
There is some logic in SP to try and determine the type sizes. They depend on the system checking the *_MAX values. Please try adding define
#undef ULLONG_MAX
#define ULLONG_MAX 18446744073709551615ULLGreat, can you please double check that the wolfssl.dll that is being linked with the application was generated using the same configuration headers that you are including with the application?
Hi Scott,
Does the source file include `wolfssl/wolfcrypt/settings.h`?
Does the wolfssl DLL get created? Do the wolfSSL examples build correctly?
Hi Chris,
I'll ask the team to review this for you...
Hello Ashwini,
The VS project uses the user_settings.h from the IDE/WIN folder by default:
https://github.com/wolfSSL/wolfssl/blob … settings.h
Your application should be including the following headers
#include <wolfssl/wolfcrypt/settings.h>
#include <wolfssl/ssl.h>Please share the user_settings.h file that is being used.
Hello Ashwini,
Could you please confirm that the application is including the same options.h header (or settings.h, if using the user_settings.h method)?
Also please share your configuration and the actual error as printed from the linker.
Thanks,
Eric @ wolfSSL Support
wolfSSH does not currently support FreeRTOS. If you are interested in opening a feature request to have us add support, please send an email to facts @ wolfssl.com
I can't recall if the platform you are using is able to produce debug logs. If so, that could help us determine what is happening when the crash occurs.
Another tool to help determine the stability of wolfSSL is to run the wolfCrypt test application:
https://github.com/wolfSSL/wolfssl/tree … crypt/test
This sounds like insufficient stack space. The 4096 RSA math uses a lot of stack memory! Have you tested using with the RSA_LOW_MEM option configured?
Hi yass007
Certainly it is possible, just not currently implemented. You would need to add functionality for all the operations in order for standardized clients to connect properly. Alternatively, you could integrate a ramdisk that already has filesystem support.
Hi Scott,
From the webpage you linked...
define the preprocessor macro “WOLFSSL_USER_SETTINGS” in your project
So in the project file that builds the wolfSSL library code, you should add a preprocessor macro for WOLFSSL_USER_SETTINGS. I clarify because you stated
define WOLFSSL_USER_SETTINGS in the APPLCATION...
The settings.h header will include user_settings.h, and those values will override anything in settings.h.
Hello Scotty
The wolfSSL configuration is used to enable / disable support for features (including cipher suites) of the library. In the Win VS build, the configuration is handled by this file:
https://github.com/wolfSSL/wolfssl/blob … settings.h
Are you using a user_settings.h for the embedded system?
When building for embedded devices the best way to configure the wolfSSL library is to create a header named `user_settings.h`. Then at the global level in your application define `WOLFSSL_USER_SETTINGS` (or `./configure --enable-usersettings`) so that when `<wolfssl/wolfcrypt/settings.h>` is included throughout the library the `user_settings.h` header is also pulled in. The application should include `<wolfssl/wolfcrypt/settings.h>`, BEFORE all other wolfSSL headers. A good example `user_settings.h` for getting started on an embedded project can be found in:
https://github.com/wolfSSL/wolfssl/blob … settings.h
That example is well commented and provides a good starting point for any embedded project, even non-ARM based ones!
EDIT: Thanks, David, for answering!
Hello Chris,
I've asked Sean to review this post.
Thanks,
Eric @ wolfSSL Support
Hi brunomarcoux
Please send an email to facts@wolfssl.com ands we can help you get started.
Hello ddnr,
What curve are you specifying with wc_ecc_export_x963_ex()?
The API wc_ecc_import_x963() only supports the default curve for a key size.
That is, the import could be creating a key with the wrong curve.
The API wc_ecc_import_x963_ex() allows the caller to specify the curve ID.
The curve ID can be obtained by calling:
wc_ecc_get_curve_id_from_name("BRAINPOOLP160R1")Thanks,
Eric @ wolfSSL Support
Thanks for contacting wolfSSL Support. NIST is currently selecting the next round of post-quantum crypto algorithms:
https://csrc.nist.gov/Projects/post-qua … yptography
The existing NTRU integration will not be maintained. We are aware that the NTRU library we tested with is no longer available:
https://github.com/NTRUOpenSourceProject/ntru-crypto
wolfSSL is working on support for the successor to NTRU:
https://github.com/open-quantum-safe/liboqs
You are welcome to send an email to facts@wolfssl.com to request more information.
Kind regards,
Eric @ wolfSSL Support
You can use the verify callback to over ride the cert signing errors. The example I shared earlier will accomplish what you are trying to do.
Hi sapi01
Need to clarify a couple points from your post:
> When I try to connect to my wolfSSL server, I'm getting `-188` on `wolfSSL_connect()`
Is this error in the client? Both peers will need the self-signed cert. You are basically doing a shared secret when doing mutual authentication and using self-signed certs.
Alternatively you could write a verify callback to override the cert failures for particular servers.
https://github.com/wolfSSL/wolfssl-exam … back.c#L55
Thanks,
Eric @ wolfSSL Support
Hello yass007
Thanks for contacting wolfSSL Support. Are you calling `wolfSSH_shutdown` before attempting the reconnect?
https://github.com/wolfSSL/wolfssh/blob … nt.c#L1140
Thanks,
Eric @ wolfSSL Support
Hello a940153,
The `SSL_VERIFY_CLIENT_ONCE` flag is regarded as unsafe and is ignored in wolfSSL. You can use session tickets to securely reconnect a peer.
wolfSSL - Embedded SSL Library → Posts by embhorn
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.029 seconds (84% PHP - 16% DB) with 4 queries