support domain alias mode now

Use the alias branch:

export BRANCH=alias --upgrade

First set domain CNAME:  

Then you can issue a cert like: --issue  \
  -d \
--challenge-alias \
--dns dns_cf

The Letsencrypt CA server checks the txt record of original domain to validate your domain, but you have set the CNAME in step 1, so it goes forward to the aliased domain to check.

And knows that, so it just added the correct txt record to

So, it’s done. you will get a cert for, but you don’t need to give the domain control out.

More usage here:


The CNAME target doesn’t have to also be _acme-challenge, does it? If not, do you think you could also add a mode where the alias record has an arbitrary name?

I hope I don’t start infinite bikeshedding, and I don’t use with DNS-01 anyway, but I name my targets something else too. 3600 IN CNAME

1 Like

Yes, it could be any arbitrary name, but not supported in current’s implementation.

For now we implicitly uses _acme-challenge, since we want to make it clear and explicit that this CNAME is for acme validation. no other use.


Sorry, in current’s implementation, we implicitly use _acme-challenge prefix, so your cname should be like:

Well, that’s also quite a reasonable view. I guess we can see what users think of this issue over time.

I don’t have any statistics on where existing _acme-challenge CNAMEs are currently pointing, although maybe LE server-side logs or a DNS scan project based on Certificate Transparency could help clarify this. :slight_smile:

FYI I started playing around with this, and 1 of my 5 DNS hosts won’t accept a leading underscore for CNAMES.

other platforms may have the same issue, because underscores aren’t allowed in hostnames, and a lot of systems validate against hostname rules not domainname rules.

I recently got access to the Censys’ BigQuery database to study this precise problem (since it affects the viability of assisted-dns-01 as well). If anyone wants to help out let me know - requires some free time.

Yeah, same here.

Still, Let’s Encrypt is not compatible with every type of problematic DNS implementation, and clients shouldn’t be infinitely complicated.

There’s at least one other CA that also relies on CNAME targets that start with underscores. (Then again, that CA sells DNS services too. :wink:)

Cool! Do they already do DNS lookups related to these resources, or would a researcher need to ask them to start doing them?

@schoen @jvanasco @_az @mnordhoff

I just added another new parameter --domain-alias, to support any cname without _acme-challenge prefix.


Then issue cert like: --issue -d  --domain-alias   --dns dns_cf

More info:



same problem with --domain-alias as this also requires a CNAME entry with leading underscore.
Tested with the latest BIND.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.