To fill in the details of what @mcpherrinm @aarongable and @petercooperjr noted:
- The CAA record can limit Certificates to specific CAs
- Certain CAs will respect an Account bind in the record, so only a specific Account can be used to provision a Certificate
- DNSSEC can be helpful, but it is not something that can be relied upon. While LetsEncrypt always verifies DNSSEC, not all CAs do so (see Lets Encrypt and DNSSEC verification - #5 by mcpherrinm). DNSSEC also has outages.
Combining (i) DNSSEC and (ii) CAA records with account-binding will successfully address the OP's concern with a limited number of CAs - including LetsEncrypt - when the state doesn't control the TLD (or DNS Servers). LetsEncrypt supports the RFC extensions and implements the CA/B Forum Baseline Requirements in a manner that supports this goal, but not all CA's do. Because this type of safeguarding hinges on newer extensions and protocols, there isn't a universal or "machine-only" approach to the solution. A Subscriber must ensure the CA of their choice is compatible with these goals, and their DNS Servers + TLD are also immune to compromise by state actors.
Last year there was a somewhat notorious story of this type of attack happening in Germany. TLDR, it is believed that DNS was modified by court order to allow a LetsEncrypt certificate to be issued and that certificate was used in MitM wiretapping for several months: