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:
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?
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.
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.
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.
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.
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
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.
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.
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
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
