I am trying to create a server SAN certificate with a SubjectAltName containing 2 hostnames, using the tlsserver profile.
I could not validate with dns-01 the first time because the TXT records for the second hostname could not be generated on the DNS server.
After making sure that the DNS server holds both TXT records (one per hostname), now it is impossible to validate because the challenge data keep changing.
So I cleared both TXT records on the DNS server since both tokens are invalid.
Why do the challenge data change while the request is still pending?
Is there a way to get the new challenge data right before validating the certificate?
I'm unsure what process you're using or what ACME client you're using, however if client indicated the challenge was ready, the server attempts to validate the challenge. If the validation fails, the challenge is not reused.
Typically ACME clients wait until after the challenge is ready to validate a challenge and could wait for days if necessary although the tlsserver profile reduces this time to 1 hour.
The ACME client I use is ansible acme_certificate and I run manually my own playbooks/roles.
Clearly in this case, the challenge remains pending on LE side but it seems that the validation data are rolled over at each try making the whole process impossible to validate on the client side unless there is a way to get the refreshed validation data before it expires.
Yes of course when trying to validate the certificate in phase II.
I regularly validate wildcard and SAN certificates for my domain.
The only issue I'm facing is when the SAN certificate SubjectAltName contains 2 hostnames, which is the first time I try that for a SAN certificate.
I retried from scratch today (new CSR/private key) and I was able to validate the certificate with a Subject Alternative Name containing 2 hostnames (without changing my workflow).
But the issue where the validating data change constantly once the first validation fails for whatever reason is not solved.
Like @MaxHearnden previously mentioned, challenges are not re-used after they have failed validation. With LE's Boulder implementation, a failed challenge fails the whole authz which fails the whole order. If your client is showing any of these as still pending after failing, that state is likely cached/stale and the client needs to refresh it.
Once a challenge has failed, you need to start a new order to try again.
OK then, but it used to be possible to try again to validate with the same validation data after a failed first validation for whatever reason.
I find this change harsh, especially for those using the classic profile where a new order can only be retried after 7 days.
I suppose it has been setup for security reasons to avoid rogue actors abusing the whole process.
And just to add to this. This is an LE specific (or anyone using Boulder) implementation choice and there are other CAs that do allow challenge retries (either automatically or client-triggered).