Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command:
The certificate on the IIS server renewed automatically as it has done for several years every 3 months. This time clients with certificates that are supposed to expire next year can no longer connect over SSL. Updating the client certificate to the new one fixes the problem, but the clients need to connect in to update their certificates. Possibly need a compatible certificate on the server to allow the old one in or some other solution such as allowing all certificate authentication requests to be valid on the server. Any direction to temporarily allow the clients in with the old cert would be most helpful.
What have client certificates to do with the Let's Encrypt certificate? And why are you using the Let's Encrypt intermediates as "client.pem"? I'm very confused what you're doing.
Usually one uses their own private root and intermediates for client authentication. Or is that not what you mean by "client certificates"?
On Sunday the 23rd, the server certificates auto renewed like they do every 3 months.
The clients are devices that are connecting to the webserver using TLS. The old client.pem no longer authenticates although it is not expired.
The devices using the new client.pem connect just fine. This is found using:
openssl s_client -showcerts -connect https://www.feeder-bot.com:443
The devices in the field need to connect into the server using the old client.pem to update to the new client.pem. This was to be scheduled sometime in the next year.
What can I do to temporarily allow the old unexpired client.pem to continue to authenticate?
Not sure. We can possibly try that later. My thought is that the client will be looking for an authentication response from the server and won't get it, so the client will then be rejecting the server.
looks like you binded client CA certificate and server certificate's issuer together:
only configs I think you are useing **IIS Client Certificate Mapping authentication
I think it's much more likely clients doesn't trust r11 in their config: do you have list of what ssl lib client uses?
Client is an esp32 using mbed_tls. Not sure about what list of ssl lib you are looking for. Pretty sure problem is not with client as changing the .pem file to new one allows it to connect just fine.
The bindings you are talking about are on the server? That was auto renewed/generated all by itself.
nah now I'm sure that's client's trust store for verify server certificate against, if it were client certificate esp32 must have it's private key, which you wouldn't have for any of LE's intermediates
roll back your server to use old certificate (that signed by R3): and deploy update to use https://letsencrypt.org/certs/isrgrootx1.pem as client.pem (but actually ca-cert)
I would append few more root certificate there, like your own CA certificate as fallback and some other free CAs
What is client.pem? That's not a typical certificate filename I'm familiar with. How is it used on the clients?
I'm a little bit worried you have configured your ESP32 devices to trust the intermediate certificates of Let's Encrypt. THAT IS AN ENORMOUS ERROR!
You should NEVER trust intermediate certificates, as they can and will be replaced regularly or spontaneous. You should rely on the root certificate(s), in case of Let's Encrypt ISRG Root X1 and/or ISRG Root X2.
And always, ALWAYS include a backup CA, as CAs can suddenly go out of business. You can see an overview of free ACME CAs here: ACME CA Comparison - Posh-ACME.
Hi Osirus,
The client.pem is a text file of the certificate in PEM format. It is an easy way to incorporate the certificate onto the ESP32. It can be embedded into the firmware at compile time or as a separate file that can be stored in the file system and updated as needed without re-flashing the firmware.
Thank you for your info and concern. The root certificates will be used in the future and backup CAs included, as well.
The ESP32 doesn't natively download a bunch of trusted CAs, unlike a web browser. You have to provide the certificates manually to keep memory usage down. In this case, the devices connect to only one web server, so only need one certificate housed in the client.pem file to connect to the server through TLS.