Going down the list:

• NTP isn't an option.

• Using WOLFSSL_LOAD_FLAG_DATE_ERR_OKAY allows the CA to load, but the verify still gives an error -150 because the time is still outside the Certificate window.

• Overriding the verify until the server tells the device what time it is opens up to allowing anything to validate, because the CA won't load, unless the above step is also done.

• Setting NO_ASN_TIME_CHECK opens it up for all time, since it's a build setting

The time functions used by this build of WolfSSL are mapped from "time()", which is the "Unix" function.  To set that, the C function clock_settime() is supposed to be used.

In the environment I am using, it is TI SYSBIOS on Sitara chip (which TI has completely walked away from any support including baremetal...  "Sucks to be you" is their attitude), the clock_settime() library is not present. The header is there, but no lib to link to.

Also the Unix C function "time()" doesn't get or set by the RTC functions that their SYSBIOS/RTOS/XDC API environment has. Nor does setting the Unix time do anything to the RTC registers.  So the RTC registers in the CPU are never in line with the Unix time.  The RTC registers power up as 01 Jan 2000, while the Unix time() is still 01 Jan 1970.

I don't know what is incrementing the Unix time, since it's not coupled to the RTC registers or to any timer interrupt I am aware of.

Regardless,  I discovered that I can set the Unix time with Seconds_set(now) which is a SYSBIOS/XDC function, where "now" is a time_t value.  Although it still remains different from the RTC registers that the CPU uses. 

Then when the Wolf library calls time(), it gets the value I injected into it.  So I can forcibly set it to a value which is within the CA validity window and it loads.  And it can also make the first connection to the server and not have any issue with the certificate time either. 

Then the server tells the device what time it really is, so I can set both the RTC registers as well as the Unix time, and everyone is happy.

-Scotty

There are a couple of ways to resolve this. You could

• Use NTP to set the time prior to connecting to the server.

• Disable time verification during runtime by loading certs using _ex version of load API with WOLFSSL_LOAD_FLAG_DATE_ERR_OKAY flag

• Use a verify callback to override the date errors during the first server connection.

• Configure no date checks ever - define NO_ASN_TIME_CHECK

Let us know if that helps.

Thanks,
Eric - wolfSSL Support

But only in my embedded project.  Not on my PC.

The issue:   The SERVER tells the unit what the time is. There is no battery backed RTC.   
We can't get to the server to tell us the time because the CAs cannot be loaded.

The CAs I am testing are from DigiCert
       Validity
            Not Before: Mar 30 00:00:00 2021 GMT
            Not After : Mar 29 23:59:59 2031 GMT
        Validity
            Not Before: Aug  1 12:00:00 2013 GMT
            Not After : Jan 15 12:00:00 2038 GMT

I tried setting our internal clock to 2022 01 01 00 00 00 001  (Jan1 2022) BEFORE even calling

m_sslCtx = wolfSSL_CTX_new(meth);

But it is still failing to load the CAs.

And to verify it is set, I display the time immediately AFTER calling

wolfSSL_CTX_load_verify_buffer()  

and getting a failure.

So, how/where is the Wolf lib getting the time that it decides to reject the CA's?

How can I force it to load the CA file before the time is set?