In contrast, HTTP based verification often has built-in support with your webserver (Caddy) or only requires copy-pasting a few lines to your docker compose file.
There are edge cases, but they're also widely exploited so you won't run into them if you follow best practices.
for 99.99% of cases when a domain is pointed at me and I want to serve an SSL certificate for it, I can answer an HTTP-01 challenge. Needing to orchestrate a DNS challenge will always be a more complicated external thing.
HTTP challenge (and TLS-ALPN) are in-band, DNS is out-of-band.
It's about proving /control/. If a domain name is pointed to me (my IP/CNAME) I control it and it is reasonable to allow that person to issue an SSL certificate for a domain (or subdomain) under their control. If you, as the domain owner, want to restrict that, CAA exists as your tool to do so.
But the reason for HTTP is pretty simple - it's extremely easy to implement. You only need to tell your ops to redir a subdomain to your app and you're done, you don't need DNS with API that have narrow enough permission to allow that one team in whole company to generate ACME stuff; most providers ACLs on DNS end at "this client have acesss to that domain via API".
Honestly, that's a feature, not a bug.
http verification proves you temporarily control IP space relative to a viewer. dns verification proves you temporarily control name resolution relative to a viewer.
Both are trivially hacked, multiple ways. By the time someone finds out you did it (if they closely monitor CT logs, which nobody does) you've already had hours, days, weeks to run a MITM on any domain you want. The attack only has to work once, on any of 130+ CAs.
The solution is registrar-level proof. Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true, it's sent to the CA who can see the registrar signed it. Now you know for a fact the domain owner asked for the cert. The only possible attack is to steal all three of the owner's private key, the registrar's private key, and a CA's private key.
I have been shouting about this for 10 years, none of the industry incumbents care. The internet is run by morons.
You're not wrong (ignoring how easy it is to hack DNS), but at the same time it's hard enough to get people to buy their own domain name, nevermind understand the system well enough to add a TXT record.
It's a strategy that's fine to implement when your target audience is server admins. It's a terrible strategy when your target audience is everyday users who you hope own their own domain. Doubly so in a world where owning your own domain is so rare for individuals.
> Both are trivially hacked, multiple ways.
I'm genuinely curious how it is trivial to "control [authoritative] name resolution relative to a viewer".
One problem I see is the extra overhead for the registrars. Now they have one more thing to do: verify (sign) certificate requests. That extra work is probably enough to get registrars to push back against such a system.
The registrar would be assuming some of the functions of a CA. This would make it easier for a single entity be both registrar and CA. That would threaten the business model CAs and thus they'd push back against such a system.
If the CA were responsible for getting the registrar's verification for a certificate request then that'd add extra work for CAs, and thus the CAs would push back against it. If the domain owner was responsible for getting the registrar's verification for a certificate before submitting it to a CA, then the domain owners would be against it.
And this is all assuming that people could agree on a common set of protocols or data formats for this new system.
Or maybe, just maybe, hear me out on this... maybe your proposal is not as smart as you think it is.
For one thing:
> Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true
What exactly does the registrar verify, and how?
Whereas, if that required a signature from a private key, with a counter or other log of use in the TPM, it'd be caught by an audit without having to notice the symptoms.
I know that in security design that I've been involved with there's a lot more scrutiny given to each use of a privileged key than there is to making sure that all website logging lists each file in the directory at each request, or logging the full public state of your DNS every minute. Requiring a signed request makes the attacker come in through the front door.
I suppose I only take issue with "more" - as it stands don't registrars do effectively nothing today besides print money? It seems like the kind of business that doesn't require much that isn't already automated, and where the only reason I don't have a successful registrar business is that the contracts with whoever owns the actual TLDs are difficult to get. Perhaps they need to look out for DMCA letters? Idk maybe I'm way off, feel free to correct me if anyone knows it's a difficult job.
There's nothing preventing you from making the DNS record a CNAME to something under a zone that you're allowed to modify.
This is how one of my setups works; _acme-challenge.someservice.example.net is a CNAME to someservice.acme.example.net, and acme.example.net is served by a bind9 that allows dynamic zone updates based on TSIG-signed DNS update requests over WireGuard.
So the machine that hosts someservice has a DDNS key that signs DNS update requests for someservice.acme.example.net, and bind9 is configured to allow that key to change that record.
The domain owner creates a CSR and signs it using their private key. Sends it to the registrar. The registrar uses the public key the user uploaded to validate the signature. This happens millions of times a day on shitty computers, this is completely old boring technology.
Now the registrar sends the Registrar-Signed-CSR back to the user. The user sends the RS-CSR to a CA. The CA uses the Registrar's public key to validate the Registrar's signature (exact same process as before). Now the CA can see the Registrar signed it, so it's legit.
Easy to automate. Boring old technology. Same flow millions of computers use every day, just with one extra party in the middle.
The BGP attack requires knowledge of internet routing and the DNS attack requires knowledge of DNS server exploits, but either of them can be executed with very minimal network access that any consumer can get. Target the nameserver account admin with a phishing attack, account reset attack, lateral password bruteforce, etc.
You'd be surprised how incredibly stupid the admins of some of the largest computer networks are. It's really not hard to get access to some accounts. It should require more than just a username and password to hijack a domain, but usually it doesn't.
In any case, if all you want is a valid cert, you can do it a number of ways that nobody will notice. Again, this only has to work once, on any one of 130+ different organizations. Not all of them have stellar security.
And I'm not even talking about social engineering either the CA, Nameserver, or Registrar's support people, which I consider cheating because it's so much easier.