New certificate (2021-06-01) cause communication errors

I have some IoT devices connecting to an nginx server periodically, using ssl.
The server is configured with a letsencrypt certificate and configured with:
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

This was running for years without a problem.
However my devices can't connect anymore since the server got the newes letsencrypt certificate today: 2021-06-01
If I change to an older certificate, it works again (OK i get a warning the certificate is not valid but the communication is working)
Any help ?
Thanks

1 Like

What SSL client are you using on your IoT devices and what version? e.g. OpenSSL.

Are you configuring that SSL client to trust any CA certificates in particular, or are you just using something like a standard ca-certificates package?

OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates is a thread that is probably relevant to you.

2 Likes

It is an embedded SSL library for the esp8266 that was available at that time and I have no details or specifications. The client is using ssl because that is wat the server is using , which means there is no specific security issues involved. however the same server is also supports desktop browsers so it is important that the certificate is up to date. The devices are using a slightly different domain name so I might be able to configure the server to use update certificates for desktop browsers and old certificate for the IoT devices. Not sure it is possible. the other option is to update the IoT devices to support the new certificate.
This will be lots of work.
What have been changed in the cert. between 2021-05-31 to 2021-06-01 ?
Do you have better ideas ?

1 Like

The default certificate chain that Let's Encrypt uses changed on May 4th (see here). If this is the first time your certificate renewed since that date, then I would guess your issue is related to that event.

I think, things depend on how you have programmed the SSL library on the ESP8266 device. From reading some documents, it doesn't look like these devices have a set of CAs that they trust. Would you be able to answer the question: what CA certificates do you have your devices set to trust?

2 Likes

No. No trust restrictions, It does not verify ca or fingerprint. It only being used because the server is running ssl

1 Like

Were you including the server cert yourself like in the https client example?

Also, are you able to recompile any test boards with some debug flags set like CONFIG_MBEDTLS_DEBUG and ESP_LOG_VERBOSE to get any logs out of it for the exact error you are receiving?

What was in the original sdkconfig.txt you used to compile the original programs? Specifically, were these two options set:

CONFIG_ESP_TLS_INSECURE
CONFIG_ESP_TLS_SKIP_SERVER_CERT_VERIFY

If these were set (ie, not commented out and with a suffix of =y), then it should have never verified any certificate it connected to and there might be other problems with the TLS library.

That is, assuming you used mbedtls and not wolfssl?

2 Likes

These IoT devices are using an old (ESP8266_NONOS_SDK_V1.5.3_16_04_16) espressif libssl.a
which is a close code so I have no way to debug it. Also I do not get any error message.My devices just reboot after emitting: client handshake start.
Next i get:
Fatal exception 29(StoreProhibitedCause):
and the device reboot

1 Like

It's weird that you would get a crash because of the chain change, if you are not even doing verification.

I wonder if the tiny memory on these devices is too little to deal with the 3 certificates in the chain. If you temporarily remove the last certificate in the chain on the webserver side (the "ISRG Root X1" one), do your devices still crash?

3 Likes

Ok well that throws a bit of a spanner in the works. My initial guess is that your new certificate chain is somehow too long for a buffer on the old sdk and is crashing. However, I can't find any sources for an that sdk or even one close to that old, so it's all just guess work.

How are you obtaining your current certificate, what acme client software are you using? You may be able to obtain an alternate chain path and try installing that on your web server to test a shorter chain.

1 Like

If you temporarily remove the last certificate in the chain on the webserver side (the "ISRG Root X1" one),

Not sure how to do it
The certificate used is fullchain.pem. There is also one caled chain.pem If I specify chain.pem I get an error
(SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
I havnet try to delete the last cert from the fullchain.pem file

1 Like

from the letsencypt log I can see that https://acme-v02.api.letsencrypt.org is being used

How to obtain alternative chain path ?

The file can be edited with any text editor.

  1. copy fullchain.pem file to any other name/location
  2. edit file and remove the last BEGIN/END section
  3. try using the newly edited file

OR
try just using cert.pem file instead of fullchain.pem file

2 Likes

This work: cert.pem file instead of fullchain.pem file
Thanks

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.