This is a thing that was originated in part by a partner of us hardcoding an intermediate on client side... which I know is BAD BAD BAD.... but well, here it comes the problem.
Our domain transitioned from R3 to R10, R11... even E5 and that was fine with us. But I wonder if there is any way I could reissue temporarly an R3 intermediate issued certificate. I have an expired R3-issued certificate, as well as the privatekey used to generate it. Is there any human way I could renew that R3-issued to continue using R3. So far my tries have made it transition from R3 to R10,R11 or E5 with no luck.
From my understanding, you cannot choose intermediates. Any bypass?
Yes you're correct. R3 has been retired in June this year and won't come back. The issuing intermediate is mostly chosen by Let's Encrypt and there's no way to override or change that. The only control you (the subscriber) have is the choice of key material (ECDSA vs RSA). This will control whether you receive an ECDSA intermediate (Ex) or RSA intermediate (Rx).
There is no way, but why would you do that? Rather modify the code originated in part by a partner of yours, to always use the intermediate certificate that comes together with the leaf certificate.
They hardcoded the intermediate R3 for https validation, which is weird since it's is neither the leaf nor the root. Now we have n devices unable to authenticate against non-R3 issued certificates. Bypassing https to http is not an option, neither reestablishing the old outdated cert. Big mess.
I see. The R3 is in the trust store of the clients. Is there any other certificate in those trust stores that you can establish valid certificate chain towards?
This type of issue has come up often. If you search the archives you might find some insight on how to transition the affected devices. Sometimes there is a commercial CA in the trust store that can be leveraged as a stopgap. Usually this requires the devices to be patched.
Let's Encrypt can't issue certificates "manually". Even the certificates they use for themselves are issued using their ACME server: even if they wanted to, they couldn't issue a cert "manually". This is by design, as the manual aspect of manual issuances is often the reason for mis-issuances. Thus, if you can't manually issue a cert, you also can't have that as a reason for mis-issuances. Thus, I'm afraid you need to forget about R3 entirely and somehow find a different solution. (As others also already have pointed at, but I wanted to add some extra clarification how Let's Encrypt works.)
Where we've seen a lot of this is in IoT devices, with enthusiastic and well-intentioned engineers doing their own version of chain validation, very possibly all copied from the same sample code some vendor has.
The only solution is to update your clients to trust any unexpired intermediate (or intermediate-intermediate) they see that's issued by a root they trust (e.g. ISRG Root X1 and ISRG Root X2, or other CA roots).
