Acme.sh support domain alias mode now

Client dev
1

Use the acme.sh alias branch:

export BRANCH=alias
acme.sh --upgrade

First set domain CNAME:

_acme-challenge.importantDomain.com  
   =>   _acme-challenge.aliasDomainForValidationOnly.com

Then you can issue a cert like:


acme.sh --issue  \
  -d  importantDomain.com \
--challenge-alias aliasDomainForValidationOnly.com \
--dns dns_cf

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

And acme.sh knows that, so it just added the correct txt record to _acme-challenge.aliasDomainForValidationOnly.com.

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

More usage here:

4 Likes
2

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?

3

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

_acme-challenge.www.mattnordhoff.win. 3600 IN CNAME www.mattnordhoff.win.acme-challenge.mattnordhoff.info.

1 Like
4

@schoen
Yes, it could be any arbitrary name, but not supported in current acme.sh’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.

5

@mnordhoff

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

_acme-challenge.www.mattnordhoff.win
=>     _acme-challenge.www.mattnordhoff.win.acme-challenge.mattnordhoff.info.
6

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:

7

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.

8

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.

9

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:)

10

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

11

@schoen @jvanasco @_az @mnordhoff

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

CNAME:
_acme-challenge.A.com  
   =>    myalias.B.com

Then issue cert like:

acme.sh --issue -d  a.com  --domain-alias  myalias.B.com   --dns dns_cf

More info:

3 Likes
12

@Neilpang

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

13

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