Is it expected to get two different challenge values for same domain with DNS validation for a wildcard cert?

My domain is: (in this example)

I ran this command:
certbot + some local custom hooks to handle the dns population
... --expand --verbose --cert-name -d * -d

It produced this output:

Renewing an existing certificate for * and
Reusing existing private key from /spirent/certmgmt/config/live/
Performing the following challenges:
dns-01 challenge for
dns-01 challenge for
Running manual-auth-hook command: /spirent/certmgmt/bin/
Hook '--manual-auth-hook' for ran with error output:
 2023-05-30 23:50:09 INFO     [:main:51] attempting validation for '' with '9BdGGaLB_B_jO3tVoTIPhxJXu0ecNQVGXvOM_Cfs3Cc' 
 2023-05-30 23:50:10 INFO     [:main:146] UPSERT: IN TXT "9BdGGaLB_B_jO3tVoTIPhxJXu0ecNQVGXvOM_Cfs3Cc" 
 2023-05-30 23:50:10 INFO     [:main:177] record UPSERT completed in background
Running manual-auth-hook command: /spirent/certmgmt/bin/
Hook '--manual-auth-hook' for ran with error output:
 2023-05-30 23:50:11 INFO     [:main:51] attempting validation for '' with 'GlVKmIjy1Q6tXshk2mzwvgrhRzgpSHPl6O41QrU9F8E' 
 2023-05-30 23:50:11 INFO     [:main:146] UPSERT: IN TXT "GlVKmIjy1Q6tXshk2mzwvgrhRzgpSHPl6O41QrU9F8E" 
 2023-05-30 23:50:17 INFO     [:main:162] checking if change is in sync (elapsed = 0) 
 2023-05-30 23:50:22 INFO     [:main:162] checking if change is in sync (elapsed = 5) 
 2023-05-30 23:50:27 INFO     [:main:162] checking if change is in sync (elapsed = 10) 
 2023-05-30 23:50:33 INFO     [:main:162] checking if change is in sync (elapsed = 16) 
 2023-05-30 23:50:38 INFO     [:main:162] checking if change is in sync (elapsed = 21) 
 2023-05-30 23:50:43 INFO     [:main:162] checking if change is in sync (elapsed = 26) 
 2023-05-30 23:50:44 INFO     [:main:175] record UPSERT completed
Waiting for verification...
Challenge failed for domain
dns-01 challenge for

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):


I'm mainly trying to determine if this is expected behavior or not, and if so, is the expected "validation" to have BOTH TXT records populated - i.e. a TXT record lookup for should return both the 9BdGG.... and the GlVKmI... content records?

If it is, it's purely something I need to fix in my local hook to tolerate the concurrency. If it's not, any idea what I'm doing to trigger the behavior?

Edit: Just noticed how horribly out of date certbot is, will update that regardless.


And the reason for that is: gets a TXT record
* gets some other TXT record


Is there some reason you need to do a custom hook for Route53?

Certbot has a Route53 plug-in as does another ACME client (link here)


In version?:


Pretty sure. 1.29 isn't all that old. But, even if not there is always

And, they didn't describe the O/S they are running Certbot. Might support snap install to get latest


Yes, it does snap; And 2.6.0 is the way to go [for Route53 plug-in and more].

I'm just thinking that they had to "do their own thing" because maybe there was no such plug-in available to them in version 1.29.0.

In review...
I think my :crystal_ball: is in high gear today!


What does snap? I didn't see their system mentioned.

But, 1.29 came out last summer. The Certbot history shows Route53 plug-in was available way before that


Lot's of things "snap"- LOL
I'm going on pure :crystal_ball: here.

Then someone likes to do things manually.
Which is fine by me.


Not so much in AWS world. AWS Linux 1 and 2 don't have Selinux for example.

Of course, they don't have to be running on AWS and EC2 could be anything doesn't have to be AWS Linux



Implies being able to snap OR compiling from code.


Or ignorance


Have a little faith man!


You are the one who always told me you never assumed anything ! :slight_smile:

I'm just making sure they are aware of all the tools available.


I didn't ...
I was my :crystal_ball:


This topic just went off the rails !!!


No, it's just you :slight_smile:


OMG, this really did go off the rails!

Thank you for the confirmation that it's expected!

To answer a few of the questions above:

  • Yes, know about dns-route53 plugin (it's even installed on this deployment, just no longer being used), but for multiple reasons it cannot be used directly.
  • Reason for the hooks - multiple accounts/different creds involved, and the plugin cannot currently cope with multiple "public" domains for the same domain (it doesn't know which one to use, and doesn't have any fallback like 'update every matching one').
    • Both of these are too much edge-case to accomodate in native certbot code.
    • Two public route53 registrations are used for split-zone support - 'private' route53 registrations come with a whole pile of behavioral baggage (like you can't delegate anything with NS records) that makes it hard to integrate into an on-prem dns hierarchy.)
  • Running on ubuntu 20 lts latest patches with certbot in a venv and (after I submitted) fully current.

So, the end summary is - I just need to make some tweaks to my hook. It's just hard to believe it's been "working" all this time by failing once (getting ONE of the validations right), and then working on the retry (getting the other). Time to fix that in my code.


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