Hello Juan,

Thanks for reaching out. Great to hear that you are back to using wolfMQTT.

Could you enable DEBUG_WOLFSSL in the configuration and add a line to the application to call to wolfSSL_Debugging_ON(). This will enable debug logging for wolfSSL.

Thanks,
Eric @ wolfSSL Support

Hello Scotty,

The callback is being triggered for each error encountered. There are checks for "valid-from" and "expiration", each could be triggered if the system time and date are invalid.

You can override the date errors like this:
https://github.com/wolfSSL/wolfssl/blob … st.h#L2829

Or is you know the time will always be invalid, you can bypass cert date checking in the wolfSSL config by defining `NO_ASN_TIME`.

I'll review the CA signer issue with the team tomorrow. I suspect it could be the order that the certs are loaded. Could you please enable debug logging and share the log showing the signer error?

Thanks,
Eric @ wolfSSL Support

Responding in ZenDesk ticket

Hello Anika,

Thanks for joining the wolfSSL Forums. If you do not require support for TLS protocol, you can greatly reduce the size with

--enable-cryptonly

This should also alleviate some of the component dependencies you were seeing.

Let us know if there are further questions.

Thanks,
Eric @ wolfSSL Support

Hi Davide,

This is a bit more complex problem than what should be supported in a forum post. Could you please open a formal support ticket by emailing support@wolfssl.com?

Thanks,
Eric

Hello zyhaha,

Thanks for joining the wolfSSL Forums. It sounds like the server is expecting the client to use a session ticket to renegotiate the connection. Could you please share a pcap of the first and second connections?

Kind regards,
Eric @ wolfSSL Support

Hello cachristiansen

Thanks for joining the forum. In order to provide highest priority support, we recommend emailing support@wolfssl.com with your questions.

The default implementation of wc_RNG_GenerateBlock will use the TSIP RNG via the seed operation. You can implement you r own block RNG function by defining CUSTOM_RAND_GENERATE_BLOCK.

Thanks,
Eric @ wolfSSL Support

Hello Malik,

Thanks for joining the wolfSSL Forums.

The -322 code corresponds to the following error in wolfssl/error-ssl.h

    DOMAIN_NAME_MISMATCH         = -322,   /* peer subject name mismatch */

The error code DOMAIN_NAME_MISMATCH would make sense if you are using a certificate issued for one domain with a different domain.

Could you please provide some more details such as the domains in question, the cert(s) in question and how we might reproduce on our end?

Do you have a site accessible that we can test against and a copy of the certificate in question?

Kind regards,
Eric @ wolfSSL Support

Hello celov65111

Welcome and thanks for joining the wolfSSL Forums. I moved this topic to the wolfTPM section, under the assumption that you are using wolfTPM to access the TPM device. Please correct me if I am mistaken.

Here is an example of reading a key from nvram:
https://github.com/wolfSSL/wolfTPM/blob … ram/read.c

Let us know if there are any questions.

Kind regards,
Eric @ wolfSSL Support

Hello Manaury,

We have an excellent PKCS12 example that parses out the key and cert:
https://github.com/wolfSSL/wolfssl-exam … pto/pkcs12

(I replied to your support ticket, but I am copying the response here for posterity.)

>  lws cannot find wolfSSL_X509_VERIFY_PARAM_set1_host

This is quite odd. The macro `OPENSSL_EXTRA` is the only define gating the definition. Maybe try with

-DWOLFSSL_OPENSSLEXTRA=yes

instead of using the CFLAG value.

Hi Angelo,

We do have some newer documentation that is prerelease. I can share this with you if you can send a request to support@wolfssl.com