April 18, 2026, 12:04am 1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: whizmann.com

I ran this command:

certbot -v certonly --manual --preferred-challenge dns -d 'whizmann.com' -d '*.whizmann.com'

It produced this output:

Please deploy a DNS TXT record under the name:

_acme-challenge.whizmann.com.

with the following value:

x3fg8NY6aDVSBPgbn3ZJeZiZyesKKL6pcmzggPqXQjc

[ ... etc. ... ]

Waiting for verification...
Challenge failed for domain whizmann.com
dns-01 challenge for whizmann.com

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: whizmann.com
Type: unauthorized
Detail: Incorrect TXT record "x3fg8NY6aDVSBPgbn3ZJeZiZyesKKL6pcmzggPqXQjc" found at _acme-challenge.whizmann.com

Hint: The Certificate Authority failed to verify the manually created DNS TXT records. Ensure that you created these in the correct location, or try waiting longer for DNS propagation on the next attempt.

Note that certbot itself specified the following value:

x3fg8NY6aDVSBPgbn3ZJeZiZyesKKL6pcmzggPqXQjc

... but then certbot itself said that it indeed found this exact _acme-challenge value (see above), but certbot then rejected it.

Why did certbot find and then reject the exact,same _acme-challenge value that it specified?

My web server is (include version):

Lighttpd 1.4.79-2 (but I stopped lighttpd before running certbot and had certbot use its own web server).

The operating system my web server runs on is (include version):

Debian 13

My hosting provider, if applicable, is:

Directnic

I can login to a root shell on my machine (yes or no, or I don't know):

Yes. And I was logged on as root when I ran the above certbot command.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

No

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

certbot-5.2.2

1 Like

The command you gave didn't do that; it used DNS validation. There was no reason to stop your web server, nor did certbot start its own. Now, why you did that, I have no idea--the --manual flag will make automated renewal impossible. Do you actually need the wildcard cert?

4 Likes

I'll pile on a bit ... Certbot is the ACME Client and Let's Encrypt is the ACME Server. Certbot is not saying it saw that record and rejecting it, the LE Server is.

Certbot gives you the instructions to prepare for the Challenge (since you used --manual) and then it requests the cert from Let's Encrypt.

The LE Server is the one rejecting the request because it can't find the expected record. As @MaxHearnden already noted there should have been two values and LE Server is only finding one "wrong" one when it is validating the second domain name.

I mention this only to help you understand how these work together.

As @danb35 noted maybe the DNS Challenge isn't needed. But, if you continue with that you should use this site to verify the proper TXT records are in place before pressing Enter to proceed: https://unboundtest.com/

3 Likes

(1) I stop my web server because it's always a complicated PITA to configure the various web servers that I've used to work properly with certbot. For years I've gotten certs by choosing the certbot-started web server, and I never had headaches nor any web server problems.

(2) Actually, I don't need any subdomain in this case, I just have an unthinking, knee-jerk habit over the years of always running certbot by requesting subdomain certs. I just got rid of that "-d *.whizmann.com" parameter, and now everything works.

This a more than good enough solution for me.

Many thanks to all!

That's of course fine.

But, using the DNS Challenge like you are does not require you to stop your Lighttpd server.

Certbot has a --standalone option that starts a local server just for handling an HTTP Challenge. But, it does not start its own server of any kind for any other challenge type.

For the DNS Challenge, Certbot instructs or prepares the DNS records and then requests the cert from the Let's Encrypt Server. The LE Server validates the TXT record(s) and, if successful, issues the cert. Certbot then retrieves it. There are (currently) five LE Server farms across the world that do the validation but I digress.

A new challenge type called dns-persist-01 is planned to be out this quarter by Let's Encrypt. I don't known when the EFF plans to support it in Certbot. But, this would simplify your manual requests considerably. See: DNS-PERSIST-01: A New Model for DNS-based Challenge Validation - Let's Encrypt

1 Like

Thank you very much for this explanation.

I wrote my script which runs certbot (with whatever arguments I decide to pass to it) to always stop my local web server before the certbot invocation and then re-start it afterwards.

This is simply a convenience for me, because then I don't need to remember for which cases this web server shut-down and re-start are actually necessary.

Stopping my local web server for a couple minutes at most does not interfere with any of the things that I do on my local machine.

2 Likes