So basically, you can use a free https://www.duckdns.org/ domain to solve DNS challenges, for your domain which may be managed by any other DNS provider.
I do this with my domain I have registered with Google Domains, because they have no API at all right now.
Without me having to deep dive through several RFCs... Is it a secure protocol, or is this BGP style we trusted everyone in the beginning and now have to layer security atop it?
Kind of curious then, why there isn't any way to do the Wildcard challenge without API Access for DNS. Using this kind of delegation would make it possible to signal in DNS that there should be a special http challenge somewhere that would allow for a wildcard certificate. A DNS/HTTP challenge hybrid
For several years now, the Baseline Requirements set out a list of specific methods (the "Ten Blessed Methods") for how a CA may validate that the applicant is entitled to receive the certificate they've requested for a DNS name. It is not permissible for a CA to just do something else, even if there's an ACME feature that would enable it, unless it's listed as one of the Ten Blessed Methods (there are not in fact today ten of them) they mustn't use it for certificates in the Web PKI. In fact they're required to explicitly list which methods they use in their mandatory paperwork as a public CA.
To use a hypothetical automated DNS/HTTP hybrid, you would need to do all of (possibly proceeding in parallel) the following:
* Write up technically how it works. You likely want a complete ACME challenge method through the IETF process (ie you're writing an RFC probably with the ACME working group)
* Get both groups at CA/B (the public Certificate Authorities, and the Browser vendors) to vote in favour of a change adding this new method to the Ten Blessed Methods (section 3.2.2.4) with a condition allowing wildcards.
* Get at least one publicly trusted CA to actually offer your new method to subscribers for wildcard certificates.
This isn't at all impossible, but any two of those alone aren't enough to make it happen, you need all three. Personally I don't think this hybrid seems safe, and so I wouldn't support it, but I don't decide any of this.
I shared the same sentiment for a while, but then I thought about it a bit more. How would you implement a HTTP-based validation that really proves that you have control over all subdomains? You might think that you just have to extend the existing validation method to pick a random subdomain, but that won't work:
1. For many domains, you cannot just pick any random subdomain and expect that you can reach a server there.
2. For services where users share the same domain (e.g. *.github.io), proving ownership of a single random subdomain won't be enough, because you could just create that domain as a response to the ACME challenge. But that doesn't prove that you have complete ownership over github.io.
I cannot come up with any HTTP-based validation scheme that would prove ownership of all subdomains for a domain.
Either (a) no one thought of cross-protocol validation signalling, or (b) they thought of it and concluded that it was too convoluted and easy to screw up.
As to why no HTTP check, an observation from another recent thread on LE/ACME:
> For example, `nrmitchi.com` is pointed at Netlify. Netlify can obtain a certificate for `nrmitchi.com` (and `www.nrmitchi.com`, which is also pointed at them). It does not allow Netlify to obtain a cert for `.nrmitchi.com`, nor should it.*
You can have a CNAME _acme-challenge.example.COM point to _acme-challenge.example.ORG or a sub-domain like _acme-challenge.DNSAUTH.example.com.
At work we use the sub-domain method and just have a small non-HA VM with some scripts that allow ACME clients to update particular TXT records. Each ACME client is given an individual key and allowed to only update a particular record.
Folks have specifically written DNS servers to do just this:
I use the NS approach too at the moment, it does feel like the natural way to do it with DNS. One downside is if your cloud provider charges per zone you end up paying for twice as many zones.
You can use sub-domains as well: _acme-challenge.example.com -> _acme-challenge.DNSAUTH.example.com, _acme-challenge.foo.example.com -> _acme-challenge.foo.dnsauth.example.com.
You can then have a small VM handle answering DNS queries just for dnsauth.example.com. Folks have written servers to do just this:
That’d be no different with the CNAME alias technique, right?
I’m not seeing any reason for the CNAME technique; seems like the NS technique should be every bit as good, without needing another domain name (which costs money and is another moving part). I’d like to know if I’m misreading anything.
Yes. That's how I handle acme verification for quasseldroid.info, I just have NS records for the acme-challenge subdomain pointing to my own powerdns server.
That.... Might solve an issue we have at work where a client's DNS provider is... Extremely janky, I tried for the CNAME record but it only allows internal ( to that zone) CNAMEs.. didn't look at the NS records..
This sounds great, although I haven't tried it myself. I have a few domains where I want/need wildcard certs and even though my registrar has API access, it's basically a god mode token that can do anything my logged in account can.
So my only choices are, take the risk and save that API token on my server, or just manually run a script that renews the certs on my own computer every three months.
If this works, we can create a new account on the registrar with just the one (not so important) domain, and create an API token for only that account.
However, it still doesn't seem like a perfect solution to me. For example, if that API token does get leaked, someone else could still create a certificate for your domain. But I guess that's still a lot better than using your token to transfer the domain to another person.
It would be great if registrars provided more fine grained control over the access an API token is granted.
>it's basically a god mode token that can do anything my logged in account can.
If you add cloudflare you can use their DNS challenge. Most of the tutorials out there reference the global API key, but the more restricted one works too.
You can make a Cloudflare API token that allows editing all DNS records for a specific zone, but I don't see a way to make a token that is restricted to updating a specific record.
Setting up a subdomain as a separate zone within Cloudflare is only available to Enterprise customers.
But yes you could register a separate challenge domain for the trick described in this article, add it to Cloudflare, and then use a token scoped to only that challenge domain, and it'd be a reasonably safe thing to do.
Yes you can do all of this on AWS with Route 53, AWS CLI/API and AWS fine-grained policies. You can integrate it with the Lets Encrypt pre/post hooks and setup domain-specific keys for each specific update server.
Does anyone know of a good resource on how to ramp up onto DNS? I'm afraid DNS is one of those things that everyone learns what's an A record and CNAME record, but once that's set it's just abandoned and forgotten.
I think the Wikipedia article is quite good, and I'd also encourage you to experiment with the "dig" tool, it shows very valuable low-level information, which goes well with the theoretics on Wiki.
You can also play with DNS by registering a domain name and running two VPSs as nameservers. I also run my own mail server and find this setup amazingly convenient.
"... if you're concerned about security problems from giving the DNS API access to your main domain..."
Tying the security of the dns records of your website and the security of TLS certificates of your website into one shared fate setup is a terrible idea.
I have this implemented (with help) for the libdns plugin for DuckDNS, which can be used with Caddy. https://github.com/caddy-dns/duckdns#challenge-delegation
So basically, you can use a free https://www.duckdns.org/ domain to solve DNS challenges, for your domain which may be managed by any other DNS provider.
I do this with my domain I have registered with Google Domains, because they have no API at all right now.