I have implemented an ACME plugin in libwebsockets, which works well with both OpenSSL and mbedTLS backends, using tls-sni-01. And Let’s Encrypt is very nice once it’s working.
libwebsockets is very lightweight and works on many platforms, including ESP32. On normal platforms we use 4096-bit RSA keys, but on ESP32 we can only use 2048-bit.
On ESP32 platform, I met a problem using the staging server… ESP32 (which uses mbedTLS backend) is too weak to complete the TLS action in the ~1.6s that the staging server (connecting to us as a client) seems to allow before timing it out and making a new connection.
For comparison of the timing, here is a local browser making an http/2 connection to the ESP32…
[2017/11/28 11:34:34:2111] NOTICE: _realloc: size 544: new server wsi (free heap 172708) ssl_pm_handshake ssl ret 0 state 1 ssl ret 0 state 2 ssl ret 0 state 3 ssl ret 0 state 4 ssl ret 0 state 5 ssl ret 0 state 6 ssl ret 0 state 7 ssl ret 0 state 8 ssl ret -26880 state 8 (this is WANT_READ in MBEDTLS_SSL_CLIENT_KEY_EXCHANGE state) [2017/11/28 11:34:35:2663] NOTICE: lws_tls_server_accept: accept SSL_get_error 5 errno 11 [2017/11/28 11:34:35:2697] NOTICE: _realloc: size 996: ah struct (free heap 145280) [2017/11/28 11:34:35:2778] NOTICE: _realloc: size 1024: ah data (free heap 144252) [2017/11/28 11:34:35:2866] NOTICE: heap :144248 (-2684) ssl_pm_handshake ssl ret 0 state 9 ssl ret 0 state 10 ssl ret 0 state 11 ssl ret 0 state 12 ssl ret 0 state 13 ssl ret 0 state 14 ssl ret 0 state 15 ssl ret 0 state 16 [2017/11/28 11:34:36:0596] NOTICE: _realloc: size 208: h2n (free heap 146856)
You can see the connection is noticed at 11:34:34:2111 but it does not complete SNI and the TLS handshake until 11:34:36:0596, which is like 1.7s later. What we see when we are getting the SNI challenge from your server is it gives up and connects three more times at ~1.6s intervals; that is too fast for us to complete the handshake.
The timeout situation may also be exacerbated by our being in Taiwan, so there is a significant RTT on top.
Can I gently request that the challenge timeout be extended to 3s or so, making Let’s Encrypt compatible with a new class of weak devices? Thanks for your consideration.