ESP8266 Community Forum

- Wed Aug 01, 2018 2:35 pm #77529 I have been working with the ESP8266 Huzzah Feather module trying to develop an app to connect to a server using the TLS API. I have the Server CA Cert and Client Cert and Key in DER form loaded in the flash. When I make the call to load the CA Cert:
bool res = client.setCACert_P(CACert, CACertLen);
there is a parsing error for the "Not After" date. The date should be:
"Not After : Jan 23 14:55:26 2054 GMT" <** NOTE: this is the GeneralizedTime format **>
but the debug display shows:
"Not After: Tue Dec 18 08:27:10 1917"
I have looked at the binary data in the array created to hold the DER certificate and it is correct. The DER certificate was converted from the PEM version "root.crt" (which was downloaded from the server) using the OpenSSL tool. I have also used the OpenSSL tool to display the PEM and DER version and they both show the date correctly.
During the handshake the same problem occurrs for all the certs in the CA Cert Chain. The Debug output gives the following error:
Verify: Cert has expired
ssl_verify_cert returned -517
Error: Cert has expired
Certificate verify failed

I am using the 1.8.5 version of the Arduino IDE with the following options in the TOOLS menu:
Generic ESP8266 Module
Flash Mode QIO
Flash Size 4M(1M SPIFFS)
Debug Port "Serial"
Debug Level "SSL+TLS_MEM+HTTP_SERVER+HTTP_CLIENT+CORE+WIFI+HTTP_UPDATE+UPDATER+OTA+OOM" (everything set)
lwIP variant: "v2 lower memory"
Reset Method: "ck"
Crystal Frequency: "26 MHz"
VTables: "Flash"
Flash Frequency: "40 MHz"
CPU Frequency: "80 MHz"
Builtin Led: " 2"
Upload Speed "115200"
Erase Flash "Only Sketch"
Port: "COMM 2"

I dont know if this is a bug in the SSL code or something I am doing wrong but would appreciate help from someone that knows the code to determine what is happening. I will include a copy of the relavent sketch code, the certs, and the debug output for your reference. Thanks very much for any help.

I have seen a lot of really good support comments/help from the moderator of this forum (@igrr). I would really appreciate some help here. I have put a lot of work getting to this point, much of which was helped by comments in these forums and I think I am just inches from getting a workable solution. I would not mind digging through the code myself if someone can point me to the source where this parsing is done and would not mind sharing what I find. Thanks.

Rex

You do not have the required permissions to view the files attached to this post.

- Thu Aug 30, 2018 11:29 am #78029 I have determined the problem and sent a message to the author of the axtls code however, this information is related to code that is no longer being used by Arduino as far as I can determine. The problem is in the Ax Tls code that tests the validity of the date, especially the "not after" date for certificates.

In my application the "Not After" date is in the year 2054 which requires the use of the generalized time format. The mechanism used by the ssl module in the code uses the mktime() function to create the date stored in the SSL Context structure. The problem is that the "time_t" variable used is 32 bit and is only able to hold an integer number big enough to represent seconds approximately up to the year 2038. The result is a negative number returned that is then interpreted by the other time functions as a date in the year 1917 which is then interpreted as an invalid date.

- Fri Aug 31, 2018 2:35 am #78037 Good find.
Although very frustrating at first, these kinds of gotcha's are always fun when found.

Assumption is the mother of all f*ckups. At least: that's what I'm assuming.

- Fri Aug 31, 2018 6:53 am #78039 Reminds me of the year 2000 problem. An extra two bytes for dates would have saved millions of dollars but coders actually believed saving bytes was more important and kicked the can down the road. This second ticks from a selection of origins as the basis for dates needs to be internationally regulated to a single origin and 64 bit ticks,