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.
It produced this output:
It issues certs among R10 or R11
My web server is (include version): NA
The operating system my web server runs on is (include version): NA
My hosting provider, if applicable, is: NA
I can login to a root shell on my machine (yes or no, or I don't know): NA
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): NA
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): terafform provider vancluever/acme 2.15.1.
In our setup we want to have a fix subCA R11, but when we run terraform apply it actually selects randomly between R10 and R11.
Is there a provision in lets encrypt using which we can do that.?
Welcome to the Let's Encrypt Community, @ashuec90!
The short answer to your question is: no. You should not "pin" a particular intermediate certificate (e.g. R10, R11). You should be expecting trust in ISRG Root X1 instead.
I understand that we should not pin the intermediate certificate, but in our setup we have a server which uses lets encrypt cert and we have to ask other teams to put that intermediate certificates in their devices also.
It was fixed till now but because of the latest changes we have to put the CAs again in our devices between R10 or R11 and the problem is while updating the certificates, it is randomly picking between those R10 or R11 intermediate certs, because of that the devices communication will go down if it randomly picks between those CAs while updating the certificates.
And also since the nature of updating the certs in 90days it is not possible to go and update the CAs into the devices.
Instead of ISRG Root X1 in preferred_chain we used R11 also but it didnt work.
Let's Encrypt changed to using alternating intermediates on purpose partly because it would flush out systems with broken intermediate trust. [in this community we are particularly seeing an impact in IoT devices where trust logic has been custom developed]
Intermediates are stunt issuers which could change tomorrow. You should only have the self-signed roots (ISRG Root X1 and ISRG Root X2) in your device trust store and you should trust any intermediate (or intermediate1 > intermediate2) signed by those.
As a temporary workaround you could change CA to one that uses a single intermediate (if there is one, I'm guessing BuyPass etc do).
Why? The chain is send by the server. Clients connecting to the webserver should not have anything to do with the intermediate certificates from within the chain.
Thats how it is configured in the devices, and we cant do much here, the setup was like that only from starting,so we wanted some workaround to tackle this situation as we are blocked and cannot move forward.
So please suggest some way, using which we can pin the CA to R11.
You can't. As said earlier, intermediates can and will change in the future, either planned or as an emergency.
The system apparently required by your devices is inherently broken and we/a CA can't do much about that.
Also, I'm not convinced there isn't an option to not pin intermediates, but obviously I'm not familiar with those "devices", so I can't advice you with regard to that. Maybe talk to the manufacturer/developer?
I just want to repeat and emphasize this. Any system that relies on intermediates not changing is not suitable for using the public WebPKI. It may be that whatever these devices are doing is expecting you to be running your own private PKI?
A way you can stick to only using R11 is to request your certs repeatedly until you get one issued by R11, then store that in a secrets store (e.g. hasihcorp vault or a file store), then deploy to your environments from there. That's obviously a hack, but it would work.
What you do not seem to understand is that R10/R11 are the current intermediates, and they will randomly cycle to R12/R13/Rxx in the future.
By trying to pin the certificates, you are assuming technical debt and investing engineering resources in a band-aid that is making your system(s) more broken over time. Pursuing this option will only ensure you returning here and posting about more problems from your team's bad design decisions in a few months.
You should be working on an internal solution that can handle intermediates that can change with no notice, because the "Service Level Agreement" from LetsEncrypt (and pretty much every CA) is that intermediates can and will change at any moment.
Sometimes intermediates cycle due to planned maintenance and infrastructure changes, like the recent R10/R11 switchover. However, they are designed and expected to change without any notice whatsoever.
I think the point that you are missing in @rg305's reply, is that the server should always send the full chain and not rely on the client having intermediate certificates inappropriately located in their trust store.
