Issue Descreption:
The R11 certificate has been phased out and expired by Let's Encrypt, making it impossible to bind my customer's server certificate to R11. This discrepancy results in a mismatch with the certificate in the device, thereby our devices can not use anynmore.
Need your help:
Is there any way to resume R11 in Let's Encrypt?
It sounds like you have something very broken in your setup, and/or you are confused about how the public WebPKI works.
Your server should be sending its own certificate, along with the intermediate(s) that it needs. It looks like your api.rezocare.fr is in fact doing that correctly, currently sending a certificate signed by R13 and that intermediate. (And if you look at your certificate history, it has used at least 6 different intermediates in the past couple years.)
Any clients would get getting its intermediates via what the server sends. What the client needs in its trust store are the roots. If wanting to trust Let's Encrypt, that should include ISRG Root X1 and ISRG Root X2. Ideally your client's trust store would include more than that; there's no guarantee that Let's Encrypt will be around forever (though I certainly hope they are!). For embedded-device-type-things that can't store many roots and can't be easily updated, probably one of them should be your own custom root, just as a backup.
Intermediates change regularly, and even for the past year there would be no guarantee that you would have been issued a certificate from R11. That certificate is now retired, and they are not planning on issuing more from it. But wouldn't be a problem unless you somehow used R11 as a root in your devices, which would be a very unusual thing to so. Can you describe more about what software is running on these devices, and how their trust stores were set up?
R11 intermediate certificate is not going back. You should reconfigure your devices to not expect any specific intermediate certificate (they can be changed anytime).
In general, certificate pinning is a bad idea, and you should abandon it. What you should do instead, is provide root CA certificates to your embedded platform (methods vary).
At the very least, you should embed X1 and X2 (Chains of Trust - Let's Encrypt), but it would be a good idea to add a backup CA in case Let's Encrypt gets into any problems (technical or policies), e.g. Google Trust Services (Google Trust Services | Repository).
Let's Encrypt does not have an official support team; this is how we are able to operate for free. The kind folks who reply in this forum are volunteers and community members.
It is not possible to resume issuance from R10 and R11; those intermediates have been retired.
Your systems should not care which intermediate was used to issue your certificate -- this is why we rotated randomly between R10 and R11 for the past year, why we switched from those to R12 and R13 recently, and why we now rotate randomly between those two. You should not rely on a particular intermediate being used.
As suggested above, you should instead rely on specific roots being used. For Let's Encrypt, those roots are (currently) ISRG Root X1 and ISRG Root X2. You can find their details on our certificates page: Chains of Trust - Let's Encrypt
However, we currently have a batch of older devices that cannot transmit data. This is because, initially, we programmed R11 into these devices, and now Let's Encrypt no longer uses R11. The server is unable to support R11, resulting in a certificate mismatch between the devices and the server.
Is there a way for Let's Encrypt to provide a special version of R11 specifically for our use?
We really need the help.
The R10 and R11 certificates are publicly available. Their private keys are not and likely never will be publicly available (unless the staff decides otherwise, which I strongly doubt will happen).
Again, can you be really clear on what software they're running, and exactly how you "programmed R11 into" them? It may be that someone might be able to help you figure out what the full list of roots in their trust store in order to help you figure out what CAs might be able to work for your server to have the devices connect to your systems again.
What did you do when R3 stopped being used a year ago?
No. But the cert that you acquired on June 17 that used the R11 intermediate doesn't expire for another couple weeks; can you roll your server back to using that certificate, and then use that to update your devices to use a more reasonable trust store?
This is the most likely way to get this going again.
If for some strange reason this isn't viable (e.g. private key of this older end leaf cert is not available any longer, not in backups, nowhere), then you should use your backup CA.
If, for some very strange reason, you don't have a backup CA configured on the devices, you probably need to physically update the devices.
And, in the future, do this correctly.
Please appreciate that Let's Encrypt issues more than 6 million (!!!) certs every day with just a limited team and limited funding. While technically almost everything might be possible (and I'm not even sure they can reinstate retired intermediates), you can't expect the LE team to somehow reinstate these retired intermediates just for a single user that made a mistake, how costly that might be.