76

(5 replies, posted in wolfSSL)

Hello avlec,

Yes, this is expected.  As part of certificate validation, we ensure that the current system time falls between the notBefore and notAfter dates from the certificate.  To perform this check, the system time must be set correctly before running wolfSSL.
We get the current system time using gmtime_s, gmtime_r or gmtime, depending on which is available on the system.  It's possible that glibc supports a gmtime call which musl does not, which is causing the behavior difference you are seeing.
You can run strace on your application to confirm which time call we are using, and whether it is returning a valid date.

Thanks,
Kareem

77

(5 replies, posted in wolfSSL)

Hello avlec,

Please retry with our latest release, 5.6.0, and let me know if it helps.
If not, please enable debug logging in wolfSSL and attach a debug log here.  To enable debug logging, build wolfSSL with --enable-debug and run wolfSSL_Debugging_ON() at the start of your program.
Please also include your build config (./configure line).

Thanks,
Kareem

78

(1 replies, posted in wolfSSL)

Hi Tom,

Version error/-326 means the client and server were unable to match TLS versions.
Most likely, your server needs a TLS version you are not building with.  By default, we only enable TLS 1.2 and 1.1.
I would start with TLS 1.3, which you can enable by defining WOLFSSL_TLS13 HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES in your user_settings.h.
If instead you need TLS 1.0, you can define WOLFSSL_ALLOW_TLSV10 to enable this.

If you still have issues, please confirm how you are setting up your wolfSSL context, for example ctx = wolfSSL_CTX_new(wolfSSLv23_client_method()).  Try using wolfSSLv23_client_method() if you aren't already, as this allows us to select the TLS version at connect time.

Thanks,
Kareem

79

(6 replies, posted in wolfSSL)

Our date check is failing: Date BEFORE check failed
This normally happens when your system time (RTC) is not set correctly, are you confident this is set correctly on your system?
Note that, on Zephyr we use clock_gettime with a clock ID of CLOCK_REALTIME.  I would confirm this is returning the correct time for you.  See z_time in wolfcrypt/src/wc_port.c.

80

(6 replies, posted in wolfSSL)

Hi,

Please enable wolfSSL debug logging by defining CONFIG_WOLFSSL_DEBUG/DEBUG_WOLFSSL and attach a debug log here.
Please also attach the cert you are trying to register.
If this is sensitive information, please contact us at support [AT] wolfssl [dot] com.

81

(2 replies, posted in wolfCrypt)

Yes, if you want cURL to use FIPS crypto, it needs to be built against wolfCrypt FIPS.

82

(6 replies, posted in wolfSSL)

Hi ajmal,

Yes, that is certainly a valid approach.  But of course, you should not need any workarounds ideally.
Can you please confirm which wolfSSL version you're on, and what toolchain you're using?  This will assist us in fixing this upstream.

Thanks,
Kareem

83

(4 replies, posted in wolfSSL)

Scotty,

I can assist you with bringing up net-SNMP with wolfSSL, but I'm afraid SNMP itself is outside of our support, as we do not directly support this protocol.  wolfSSL is only providing cryptography to net-SNMP.

Thanks,
Kareem

84

(4 replies, posted in wolfSSL)

Hello Scott,

We provide SNMP support via a net-SNMP patch: https://github.com/wolfSSL/osp/blob/mas … .9.1.patch
You will find instructions on how to use the patch at the top of the patch file, in the comment block.
You will need a utility like "patch" or "git apply" to apply the patch file.

Thanks,
Kareem

Hi Bassem,

wc_KeyPemToDer is meant for private keys, you're getting -162 (ASN_NO_PEM_HEADER) for your public key as it specifically checks for private key headers only.  For public keys, you can use wc_PubKeyPemToDer.  You can also use wc_PemToDer as a general PEM to DER conversion function.

Thanks,
Kareem

Hi mamonetti,

Thanks for sharing and for your patience.

Your wolfSSL build settings look good to me.  The problem is Harmony is shipping an outdated wolfSSL release.  I do recognize the wolfSSL_read issue you are seeing, it should be fixed by this PR: https://github.com/wolfSSL/wolfssl/pull/4203  However, rather than cherry-picking it, I would strongly recommend you upgrade to our latest release, 5.5.3, for the best security and functionality.  You can find our latest release in our Github repo: https://github.com/wolfSSL/wolfssl/releases

You will need to register the appropriate CA certificates on startup for our verification to succeed, please retry after adding your CA certificates.

Yes, you can toggle our CA checking at runtime using wolfSSL_set_verify.  Set the second parameter to SSL_VERIFY_PEER to enable validation, SSL_VERIFY_NONE to disable it.  We strongly recommend against using SSL_VERIFY_NONE in production, as it removes a lot of the benefit of SSL.  You can find more information on wolfSSL_set_verify here: https://www.wolfssl.com/documentation/m … set_verify

Please let me know if you have any further questions.

Thanks,
Kareem

Hi mamonetti,

Sorry to hear about this issue.
Please share your build configuration (configuration.h/user_settings.h), and your target platform.  Please also confirm if you are registering any CA certificates, and if so which function you are using.

Thanks,
Kareem

Hi Frederik,

When using a post-quantum algorithm, only the client needs to do keygen, as opposed to both sides for typical algorithms.  This explicit call helps us enforce this, and prevent doing keygen on the server-side.
In addition, having keygen in its own call allows us to speed up connection time by doing more work during initialization.
Since some post-quantum algorithms such as Kyber have multiple levels, our current approach also lets us prevent generating and sending excess keys for all levels, when only one level was requested.

Thanks,
Kareem

89

(2 replies, posted in wolfCrypt)

Hi m_u_h,

How are you building the wolfSSL you are using with wolfEngine?  You will need to build with debug enabled, either with --enable-debug or by defining DEBUG_WOLFSSL.

Thanks,
Kareem

Hi Frederik,

This is indeed expected behavior, as we do not generate an ephemeral key until you call wolfSSL_UseKeyShare.

May I ask what project you are using our post-quantum support for?  Are you working on a personal or commercial project?  Feel free to contact us at support [AT] wolfssl [DOT] com if these details are sensitive.

Thanks,
Kareem

91

(3 replies, posted in wolfSSL)

Hi albmont99,

If you only need to debug a memory issue, I recommend using our memory debug features instead.
To activate this, build with the following flags: USE_WOLFSSL_MEMORY WOLFSSL_TRACK_MEMORY WOLFSSL_DEBUG_MEMORY WOLFSSL_DEBUG_MEMORY_PRINT  You can find more information about this feature in wolfcrypt/src/memory.c.

Thanks,
Kareem

92

(2 replies, posted in wolfCrypt)

Hi m_u_h,

You can call wolfCrypt_GetStatus_fips to get the current FIPS POST status, if it returns 0, POST was successful, non-zero means there was an error.
Yes, you can call wolfCrypt_IntegrityTest_fips to manually trigger a POST.

Thanks,
Kareem

93

(3 replies, posted in wolfSSL)

Hi albmont999,

Looks like you are using static memory, are you confident you need this feature for your platform?
If so, check out our static memory guide here for more information on how to set this up correctly: https://docs.google.com/document/d/1nST … k7gp4/edit

Thanks,
Kareem

Yes, please try updating to 5.5.3.
wpa_supplicant requires multiple build flags which you can find in configure.ac: https://github.com/wolfSSL/wolfssl/blob … e.ac#L1669
You will need to define all of them.  The main flag is WOLFSSL_WPAS.

Hi Himanshu,

Are you using the latest wolfSSL release, 5.5.3?  If not, please retry with 5.5.3.
If so, are you building wolfSSL with --enable-wpas?  Please attach your build config.
One special note with FIPS is it requires a minimum password size of 14 bytes (ie. 14 characters) due to the FIPS standard, shorter passwords will not work.

Thanks,
Kareem

96

(6 replies, posted in wolfSSL)

Hi Danny,

-188 is ASN_NO_SIGNER_E, this means we were not able to find a CA signer for your peer's certificate.
Are you registering CA certificates before connecting?  You can register CA certs using a _verify API such as wolfSSL_CTX_load_verify_buffer.  Are you confident your CA certificates include your peer's certificate?

Thanks,
Kareem

97

(6 replies, posted in wolfSSL)

Hi Danny,

-155 is ASN_SIG_CONFIRM_E, it means we were unable to confirm your certificate's signature.  Are you confident your peer's certificate is valid?  Are you registering CA certificates before trying to connect?  Can you provide your build settings? (user_settings.h or ./configure line)
Please also confirm you are using our latest wolfSSL release, 5.5.3.

Thanks,
Kareem

98

(3 replies, posted in wolfCrypt)

Hi swaroopk,

Did you install your distro's wolfSSL, or did you build it yourself?  If you built it yourself, please attach your build settings (user_settings.h or ./configure line).
It looks like you're missing SHA support (ie. --disable-sha or NO_SHA), please confirm SHA is enabled.  Please also confirm you're using the latest wolfSSL release, 5.5.3.

99

(1 replies, posted in wolfSSL)

Hi sc4l7dpz,

I would recommend using our XCODE project found here: https://github.com/wolfSSL/wolfssl/tree … /IDE/XCODE

Let me know if you continue to run into issues with it.

Thanks,
Kareem

100

(5 replies, posted in wolfCrypt)

Is your FIPS hash unstable?  Is it changing after you change it in fips_test.c and rebuild?
If so, make sure you are linking wolfCrypt FIPS in the right order, see our linker script here for an example: https://github.com/wolfSSL/wolfssl/blob … er_fips.ld  Specifically, wolfcrypt_first.o needs to come first, then the FIPS objects, and lastly wolfcrypt_last.o.