DNS-01 challenge for wildcard cert - explanation?

Can anyone point me to any article(s) that explain what a client does for a dns-01 challenge for a wildcard cert.
eg. a flow diagram
or an article like Let’sEncrypt’s “How it Works” but specifically for dns-01

Thx

Hi @jradxl

if you want to develop a client, then

[8.4]. DNS Challenge

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-8.4

is your first place.

The client has the token and have to create a Key authorization string:

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-8.1

Token - dot - base64url from the JWK_Thumbprint of the account key

Then compute the SHA256-hash, then the base64url - this must be saved as

_acme-challenge.domainname.tld

1 Like

Indeed reading the draft is the best way to go, as a “how-to” would basically be repeating what spec says anyway.

3 Likes

Thanks so much…
I was confused by the document saying acme-14, where I was looking for something that said acme v2
The flow chart is brilliant, thanks, as I’d not found that.

Is there only one TXT record, if subdomains or a wildcard are requested.
The doc only says, _acme-challenge.example.org. 300 IN TXT “gfj9Xq…Rg85nM”
ie. is an explicit TXT record required for every subdomains?

Thx

14 is the version of the draft, which will eventually become an IETF standard. ACME v2 refers to the protocol described by the draft (at the latest or any draft version).

When you create an order, the list of challenges you receive will approximately match the number of domains you requested in the order. You will need to respond to each challenge (e.g. by creating a TXT record) before finalizing the order.

Edit: I’ve somewhat misleadingly been calling everything “challenges” when there’s a little bit more complexity - there’s authorizations and challenges, but it would have blown the flowchart up to describe it fully. Read the spec :slight_smile: !

1 Like

Haha! Thanks! I am trying to read the spec… (and English is my only language, but its hard work!)

So there are multiple TXT records, in the case of subdomain requests
Should they exist one-at-a-time, thus only _acme-challenge.example.org key is needed.
The DNS spec does allow multiple TXT entries with same key, but don’t see how that can work.
So, just before the order is finalised, are there/can there be multiple TXT records all using _acme-challenge.example.org and LetsEncrypt server handles that??
Thx

1 Like

A sample:

If you want a certificate with two names

*.example.com example.com

you have to create two txt entries with the same name

_acme-challenge.example.com

and different values. Then send the POST, that the challenge is done. Letsencrypt picks the two txt entries.

2 Likes

The one thing to add is that those would be two separate challenges, so practically speaking it’s:

  1. Create both TXT records.
  2. Post #1 to update the challenge for *.example.org == _acme-challenge.example.org
  3. Post #2 to update the second challenge for example.org which also == _acme-challenge.example.org
  4. Post #3 to finalize the order

As step 2.5 or 3.5 you can remove the TXT records, doesn’t really matter when.

1 Like

Why wouldn't it work? If there are multiple TXT records, Let's Encrypt is okay with that (up to a certain point). But you don't often need multiple TXT records.

A lot of this is more about individual CA policy, rather than being inherent in the ACME protocol. For Let's Encrypt, if you were using DNS-01 validate to create a certificate for:

  1. example.com
  2. blog.example.com
  3. www.example.com

You would be required to create TXT records for:

  1. _acme-challenge.example.com
  2. _acme-challenge.blog.example.com
  3. _acme-challenge.www.example.com

But other CAs -- or even Let's Encrypt -- could handle it differently in the future. ACME clients can be more flexible about what challenges they'll expect from the CA.

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