Ordering a cert for wildcard and root together requires two DNS challenges

Hi,

I am working on the integration and we need to order a cert on behalf of our users. The problem I am facing is when ordering a cert for both wildcard and root domains, e.g. "*.example.com, example.com", we receive 2 challenges:

[{"type"=>"dns",
  "record_name"=>"_acme-challenge",
  "record_type"=>"TXT",
  "record_content"=>"HsKWhBUDqOuL7t_DZdt_0f9zqXad1SofUkDm93k20Ao"},
 {"type"=>"dns",
  "record_name"=>"_acme-challenge",
  "record_type"=>"TXT",
  "record_content"=>"jZKfRDYzgRDpwi9uRciHF6FOm71TW_3SoB23XOJhUBQ"}]

The values are different but the record_name is the same and I can't create two TXT records. I have to make a tricky implementation that first inserts one record, then checks for the DNS propagation, then requests the validation from Let's Encrypt, and then repeats this procedure.

That would make perfect sense if we were requesting a cert for the root domain and/or exact subdomains, but what's the point when requesting for the wildcard and root? In this case, will it be enough to only do the challenge for the root domain? Doesn't that prove the ownership?

Thanks in advance!

1 Like

Welcome to the community @heaven

Why not? This is commonly done. Who is your DNS provider?

No. Let's Encrypt walks the authoritive DNS tree so is not subject to TTL propagation. If you do a pre-check just check the authoritive servers directly. See https://unboundtest.com for testing tool.

Those names control different scopes of domain names. One is discrete and the other a wildcard.

It is not about proving ownership but proving control of the names being requested.

5 Likes

@heaven , welcome to the community!

Why can't you create multiple records? By the DNS specification it is standard. As you are doing the integrations, you can prepare for that case.

5 Likes

@MikeMcQ, @bruncsak hi, and thank you for the answers.

We create hosted zones in AWS Route53 and whenever I try creating a second TXT record with the same host (e.g. _acme-challenge.example.com) the request fails telling me the record already exists. I would assume when ordering for subdomains I could do _acme-challenge.subdomainN.example.com, but in the case with root and wildcard, the host is the same in both cases or am I missing something?

I've just tried to create the second record manually from the UI:

We implement a pre-check, so we put the TXT record and then wait for it to appear in the Domain's primary nameserver response. And only then ask Let's Encrypt to validate the challenge. Just to avoid order failures when checked too early.

1 Like

I use Route53 too. In the console you just add additional record values in the same record. See pic below.

In the api I think you just add separate values for the record. I use the api but not for TXT like that.

This pic is a partial from a very large acme-challenge test record

That's probably fine. Route53 usually syncs its name servers in less than a minute. I think there is an API call to check if a change has sync'd. Which is probably best.

7 Likes

That saved my day, thank you!

I tried creating separate records and did not realize we could just group the values under just one. Phew, what a relief!

Thanks again!

4 Likes

Great. There is a way to check when the Route53 API request is complete. Better than checking just one of the auth servers.

6 Likes

Don't beat yourself up for not knowing. The UX (and APIs) for this varies widely between DNS providers. Many do it this way where there is only a single FQDN/Type combo allowed with multiple values. Others allow you to create separate "records" for as many unique FQDN/Type/Value combos as you want and the back end takes care of serving them properly. Some even allow for both. It's kind of a mess.

5 Likes

Thank you, everyone, for the help. Honestly, I did not expect this much attention, really pleased.

it could be really handy to mention in the docs somewhere, that Let's Encrypt is fine if the tokens are aggregated under a single TXT record. Probably that's dumb from my side and this is obvious to those who deal with this daily but I did not figure that out after going through the docs :man_shrugging:

Cheers!

2 Likes

Wasn't convenient for me either using two records, I use putty to copy the record from the command line and CTRL+C to copy exits the certificate request before I can get to the next record.

First, you should really look into updating the ACME challenge DNS recrds using an automated method so you aren't having to copypasta.

Second, you don't need to press CTRL+C to copy from PuTTY. Highlighted text is automatically copied to your clipboard.

4 Likes

It turned out that was just me not getting used to how Route53 works with those records. While other DNS providers just represent each record individually, as a single row, Route53 aggregates them into record sets. But when querying DNS they return separate records.

So my first confusion was creating two record sets with the same name and type, and each with just one record, which failed due to the uniqueness constraint.

The second confusion was thinking that if storing both tokens into a single record set, Route53 would create just a single record with two tokens (comma- or newline-separated). This isn't true but that's how their UI represents this.

The truth is, that Route53 aggregates records by name and type (or alias/traffic routing policy, but that's a different story), which they call a record set, and values go as separate resource records. So they in fact store both tokens as separate records and they are represented in DNS response as separate records.

2 Likes

Did you switch to using the getChange API rather than just checking one of the auth servers? It does the same thing as you see on the console about checking the status and reports when all the auth servers are in sync.

I just started using it myself since I mentioned it earlier in this thread. Is easy to use and works great. You just poll that api watching for INSYNC (from PENDING).
I used to just sleep for a bit lol

4 Likes

In our case, it is a bit more challenging. We create a hosted zone for the user automatically, allow them to transfer all the values from their previous DNS provider, and then ask them to change the nameservers. Once this change is confirmed, we allow them to order a certificate.

At this point, the user may roll back the nameservers and we'll lose control over the domain. That's why the preference was made in favor of checking the DNS directly. While doing this set up we perform this check quite often. Once it's complete we continue checking periodically.

If we check just Route53, the changes may be all set in there but not in the DNS response, and the order will fail once we request the validation.

UPD, I know this is not much better due to the TTL. Probably the biggest reason is we already have a DNS check in place which we use when the user transfers the domain to us, checking for our own challenge :slight_smile:

2 Likes