Supported cipher-suites on the ESP8266

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
Posts: 8
Joined: Wed Jan 08, 2020 10:10 am

Supported cipher-suites on the ESP8266

Post by andydrizen » Mon Dec 21, 2020 12:38 am

The latest updates to certbot from Let's Encrypt have presented a problem for my micropython-powered esp8266 due to the incompatibility of cipher suites, which now supports the recommended set listed here: ... default.29

After my server update, I noticed that my device was no longer connected. Looking at my logging, I saw many reconnection attempts all terminating in "ssl_handshake_status:-40".

Looking at the forums, I found this post which looks very similar to my issue (for someone connecting to the telegram API).

From my reading of this, it seems like the core TLS library (axtls) only supports these cipher suites:
  • AES128-SHA
All of which are listed in the "should be used only as a last resort" backwards compatibly section of Mozilla's list.

To resolve my issue, I had a few attempts:

1. I investigated using something other axtls (e.g. but that solution is only partially formed, and completing it is a little outside of my wheelhouse.
2. It's possible to just add these denounced cipher suites to the let's encrypt configuration. I'd be willing to do this for my toy IoT device, but issue is that I have other sites on my server that would be impacted, and I don't feel great about that.
3. Removing the SSL connection from my IoT device to my server.

Ultimately I went with option 3, reluctantly.

I hope I've summarised the situation correctly, and if so, the ESP8266 micropython port cannot connect to servers using the default Let's Encrypt certificates.

I appreciate all the work that people do here, and understand there are many conflicting interests/priorities, but my hopes for this post are:

1. Someone can point out why I'm wrong, and present an option I didn't see
2. This bumps up the priority for implementing a more fully featured TLS library
3. It helps someone else understand why they're seeing ssl_handshake_status:-40
4. It informs someone of the limitations of using this setup before they invest.

Post Reply