At the moment, Let's Encrypt primarily issues certificates based on insecure, authenticated HTTP-based validation of domain control.
They validate DNSSEC but the HTTP-01 method by itself is insecure and the DNS-01 method requires giving servers DNS API access which isn't good.
Conversation
community.letsencrypt.org/t/acme-caa-val (accounturi) is a feature currently available on their staging server providing a solution.
The accounturi feature allows you to pin the ECDSA-based renewal account to provide a secure chain of trust from DNSSEC for issuing certificates via Let's Encrypt.
1
7
This feature isn't deployed on their production server yet.
It's implemented for all of the GrapheneOS domains/subdomains now and we've tested across all with the Let's Encrypt staging server.
Of course, you still trust every CA to validate CAA/DNSSEC and not be compromised.
Replying to
Our public keys for all our TLS-based services are pinned across all our services via DANE TLSA records.
If clients validated DNSSEC and enforced a tiny subset of DANE (public key pins for leaf certificates) it would solve the problem of needing to trust all CAs. Fix it already.
2
10
For email, DANE TLSA is already available and working well. It's widely deployed for secure transport between email servers in a lot of Europe.
You can use internet.nl/test-mail/ to check if your provider has it for inbound connections and havedane.net for outbound.
2
8
Essential for email since without it, connections aren't authenticated and transparently fall back to plain text.
Google is against it for political reasons so their alternative for email MTA-STS which is basically HSTS, but without preloading, to enable WebPKI, but without CT.
1
7
You would think that as the primary backers of MTA-STS, Google would have a decent deployment. Gmail only sets max_age to 1 day. Leading by example.
It's a messy feature, since while it depends on DNS security, it pretends not to by making you serve a TXT file with a web server.
6