the itch: dns-01 is the only way to get a wildcard, and getting one means putting a dns provider api token into your load balancer's config. that token doesn't just prove control of one name — it can rewrite every record you own, and now it's in the config, and in the backup of the config. i kept deciding not to think about that.
so, the usual cname trick, but as a service you don't have to run:
you publish one cname, by hand, once: _acme-challenge.example.com -> <alias>.acmealias.com
we're authoritative for that zone, so let's encrypt follows the cname into ours
your acme client tells us the challenge value over http when it's issuing or renewing, we serve it as a txt record for the duration, then drop it
that's it. every renewal after the first is invisible to you, and your dns credentials never leave your dns provider, because we never ask for them
on the client side it speaks two things: lego's httpreq provider (so traefik, and anything else built on lego, is a couple of env vars), and the acme-dns /update protocol, so acme.sh, certify the web, cert-manager and the certbot plugin work without anything new being written.
credit where it's due: this is acme-dns's design (GitHub - acme-dns/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. · GitHub), straight up. what i added is the part i kept building by hand around it — a console, domains grouped into projects, an api key per load balancer instead of a credential file per domain, wildcard and apex sharing one alias and one cname (they validate at the same challenge name anyway), and a view of which certs actually got issued and when they expire.
honest state of it: it runs and it issues real certificates. there's pricing on the site — free personal accounts, 39 ct per challenge answered for team accounts, capped at 199 eur a month — but no payment processor wired up behind it and no self-signup, so nothing can be bought today. the numbers are there to cover the nameservers and the database rather than to make anyone rich. if it looks useful, tell me what would break for you and i'll take that over guessing.
One general note (especially to folks who are interested in this or similar services): if you don't use CAA Account Binding, you allow the operator of the DNS alias service to obtain certificates for your domain (in particular wildcard certificates) and use them to perform person-in-the-middle attacks on your users. Once you use CAA Account Binding, though, you're safe*.
yes, great point. i have a CAA check - but i will add some documentation on how to actually do it.
my initial version of this was going to be open source, t oself-host - do you think this would be interesting? currently, i think it would mostly benefit bigger players that can set this up. for a smaller situation ... i think it might be a bit too fiddly to set up all the small pieces to run this - hence the SaaS approach ...
acmealias is the acme-dns pattern, hosted. it isn't a better (or very differnet) idea than acme-dns, it's the same idea with somebody else holding the nameserver. it speaks acme-dns's /update,
so acme.sh, cert-manager's solver, certify the web and the certbot plugin work against.
what's different is the operational half, for a lot of people that's a bigger commitment than the api token they were trying to get out of their proxy config in the first place. this is that box, run by someone else. that's the entire pitch. you're probably right - i should have said this more clearly.
there ARE a few differences, downstream of that one:
POST /register is not open. in acme-dns anyone who can reach the endpoint mints an
account and a subdomain; here the account exists first and registration is
authenticated. that's a genuine incompatibility with clients that self-register.
alias labels are 80 bits of random base32 by default rather than derived from the
domain. our nameservers are public, and a derivable label would turn the zone into a
membership oracle — ask whether shop.example.com is a customer, get a free answer.
a wildcard and its apex share one alias and one cname, since the *. label is stripped
before the challenge name is formed. one action, not two, and no collision discovered
at renewal.
there's a console on top: domains grouped into projects, one key per load balancer
instead of a credentials file per domain, and a view of what was issued and when it
expires.
but if you're already running acme-dns and it's up, i have nothing for you - genuinely,
don't switch. but this probably isn't for everyone.
yes, absolutely. although - with a smaller blast radius, and we would have to ALSO mess with a user's DNS to actually impersonate someone. also - and i will try to improve this a bit - we ARE checking the CAA records at the moment to see if they are present and configured correctly - i am working on implementing a CAA check that ALSO checks for a limitation to one account - this would stop me completely from impersonating you:
As an aside, Certify DNS has offered this type of thing (basically cloud managed acme-dns) commercially for the last 5 yrs or so, very inexpensively.
It's not exactly a money spinner and I think folks are increasingly wary of services that have obviously been AI generated, so it's a tough sell but you might have some luck. The upcoming dns-persist-01 will hopefully make it (and other dns challenge methods) redundant.
@webprofusion hi. thanks for that - i didnt know this. overall - i agree, and i would normally publish this as a self-hostable tool .... here, i wasn't so sure - there multiple moving pieces that have to line up, and for a small environment, it is kind of heavy to run - hence the SaaS approach. do you think this might be useful for people to self-host? i am definitely not in it for the money .... it's more the itch that needed scratching ....
