How to issue ACMEv2 Wildcard with Certbot 0.22.0?


According to Seth from letsencrypt, the TXT string will need to be changed each time certbot needs to renew, which is why having a plugin for your domain host provider is a good thing to have, so that the TXT field update can be automated as well.


That is why I was asking the question. We have installed LetsEncrypt manually and know the txt file changes for each install/renew. Works great as a once off. It is the renewal’s that we would want automated.
Wanting to understand so that I know how to implement the right process approach a solution.



You would need to have a DNS hosting service that either 1. is supported by the letsencrypt dns plugins 2. has an API that allows you to change TXT records programmatically. Not many consumer-level services do.

Assuming you find a service that does, you would need to use the script hooks that will take the parameters from certbot, set the TXT record, then let certbot finish the DNS-challenge


Would mean we would need to use one of the listed DNS management systems. Will need to consider this as not as simple as moving.

Thanks for reply


If you are using tinydns running on the same server as Apache, the following works well for me. This assumes you already have a virtual host already configured for your domain. This is on Centos 7.

I have logged into my server, via ssh, as myloginusername, then su root. (Of course, for security, ssh is configured to not allow ssh connection as root.)

On command line

certbot certonly -d -d *

In /etc/letsencrypt/cli.ini

server =
rsa-key-size = 4096
preferred-challenges = dns
manual-auth-hook = /path/to/
manual-cleanup-hook = /path/to/


cd /etc/tinydns/root
cp -f data data-good
echo "'_acme-challenge.$CERTBOT_DOMAIN:$CERTBOT_VALIDATION:120" >> data
# Sleep to make sure the change has time to propagate over to DNS
sleep 25


cd /etc/tinydns/root
head -n -1 data > tmp; mv -f tmp data

Note: I have tinydns running on a second server. The file in /etc/tinydns/root is a bash script that runs “make” to update the data.cdb file, and uses rsync to copy data and data.cdb to the other server. How to do that is another topic. (If requested, I can upload detailed instructions on how to set it up.) If you are only concerned with the one instance of tinydns, replace “./” with “make”

However, for interest’s sake, here is the content of

rsync -avz -e "ssh -i /home/fredmc/rsync_key/ws1-rsync-key" /etc/tinydns/root/data.cdb myloginname@ws2:/etc/tinydns/root
rsync -avz -e "ssh -i /home/fredmc/rsync_key/ws1-rsync-key" /etc/tinydns/root/data myloginname@ws2:/etc/tinydns/root

I have the IP address of ws2 in /etc/hosts

I tried using -i apache to have the Apache plugin install the certificates, but it didn’t do anything that I can find.

I had to manually update my Apache virtual host entries. I keep a separate file for each virtual host. This is what it looks like after my update:

<VirtualHost *:80>
	DocumentRoot /path/to/http/www
	ServerAlias *

	# To automatically redirect to HTTPS
	RewriteEngine on
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

<IfModule mod_ssl.c>
	<VirtualHost *:443>
		DocumentRoot /path/to/http/www
		ServerAlias *

		Include /etc/letsencrypt/options-ssl-apache.conf
		SSLCertificateFile /etc/letsencrypt/live/
		SSLCertificateKeyFile /etc/letsencrypt/live/
		SSLCertificateChainFile /etc/letsencrypt/live/

You probably have other lines in these entries.
This is for Apache < 2.4.8.
For Apache >= 2.4.8 change the lines starting with SSLCertificate… to

		SSLCertificateKeyFile /etc/letsencrypt/live/
		SSLCertificateFile /etc/letsencrypt/live/

Do not include SLCertificateChainFile

The files,, and must be executable.

I hope this helps someone.



That is backdoor marketing for DNS they support. And since LE is effectively the only free certificate (was DNS before edit, mental freudian slip) provider…
ugly and infuriating.
So essentially you’re forced to use expensive DNS providers.
Might as well pay for a proper cert then.
Seriously why would you do that?

Why isn’t one TXT record enough to verify the validity of your claim?
And I mean why do you need to change the content of this TXT record every time you renew?
I just KNEW it was too good to be true. Free certs. Yeah. Pipe dream.


The requirement to continually demonstrate control of the domain is the only way to deal with automated issuance in a safe way.

ALL CAs have this requirement, because it’s baked into the common rules they have to follow. Both paid and free CAs (AlwaysOnSSL is another free provider you can check out) are subject to this.

There are plenty of reputable free DNS hosting providers that provide API control. You are also welcome to hook your own scripts to update your DNS records at any provider, not just using the ones listed in Certbot or Lexicon or wherever.


Thanks Fred,

Managed to get wildcard cert on our staging /testing environment through manual We had previously installed ACME V1, but found we needed to revoke those certs before we could use the the new ACME v2 and wildcard.

This is the command that worked for us
certbot certonly --agree-tos --manual --preferred-challenges dns --server -d *

We cannot automate the renewals with our current DNS as they do not support API to allow management of TXT files…etc required the auto renewal process. So will need to consider one of the supported options moving forward. Renewing one of two domains is ok short term.

LE creates domain name reference files in the Live directory EG “”. On renewal does it create a new reference file or updates the existing reference file? Does it create a “”


Well, Cloudflare provides DNS hosting at no cost, and has a well-supported API. So much for that argument.


You can get if you request a certificate with overlapping domain name coverage under some circumstances. Most of the time this behavior is not quite what people wanted and maybe we should have been more cautious about it. (Most often, it occurs if you request a new certificate that lacks coverage for at least one name that was part of the prior certificate, without specifying via --cert-name that the new certificate is meant as a replacement for the previous one.)

Normally, renewals will cause new files to be saved in /etc/letsencrypt/archive/ and the symbolic links in /etc/letsencrypt/live/ to be updated to point to those files. So, if you use the names in /etc/letsencrypt/live in your server configuration, you won’t have to change that configuration in response to the renewal. The original file names and paths will point to the versions corresponding to the renewed certificate.


Revoking it shouldn’t have been necessary. Deleting it… also shouldn’t be necessary, but may be convenient.


Thanks That makes a lot of sense. For our staging/testing not a big issue and we have documented in our doc area. Good knowledge as we deploy to production…

Thanks for the reply and explanation


Not sure why I got the error and only appeared to work after we removed…! May have done something in that did not make it work the first time. Why we are testing on our staging site.
Thanks for the reply


It’s so easy man :slight_smile:
Just one note: when you issue a wildcard cert
sudo ./certbot-auto certonly --server --manual --preferred-challenges dns -d * -d
First write the wildcard and next the base domain. You HAVE to write the base domain as well otherwise the base domain will error.
If you switch them, all domains/subdomains will work, but the webbrowser will only display the base-domain on the certificate.
First wildcard, next base-domain will display it correctly *

I hope that other certificate authorities will now realise they’ve been filling their pockets for many years and will now have a very hard time keeping their heads up.

May Let’s Encrypt live long. Thanks for this amazing initiative.

I just have one question concerning renewal. Will we have to issue
certbot-auto or certbot-auto renew
again each 3 months? (not that it’s much of a hassle, but just for information…)


You’ll have to renew the certificate every three months. Normally we recommend that you run certbot-auto renew twice a day, every day, from a cron job. certbot renew only tries to renew certificates that are less than 30 days from expiry, so most of the time it will take no action at all.

However, certbot-auto renew is unable to renew certificates that were issued with --manual because those require manual intervention in order to renew. So, you should re-run the complete certonly command again (or investigate a way to automate the issuance process with a DNS authenticator plugin or authentication hook script).


4 posts were split to a new topic: DNS-01 Wildcard Policy Feedback


For the new wildcard domain support… I do something like:

$cmd = “/opt/certbot/certbot-auto --server {$SERVER}
–cert-name {$domain}
-d *.{$domain}
-d {$domain}
–email {$email}
–preferred-challenges dns-01

to get my certs. This is in a script and there is no user input required.

I end up with ( on testing )

Waiting for verification…
Cleaning up challenges

  • The dry run was successful.

Prior to doing the wildcard txt stuff. I would renew my domains using something like:
$cmd = “/opt/certbot/certbot-auto renew”;

and it would renew all of the certs from my /etc/letsencrypt directory.

Since I am doing the wildcard txt entries now with:

can I still do

certbot-auto renew

or can I / should I do


to still do everything automatically? I have 100+ domains and don’t want to have to do anything manually.

Thanks - jack


@jacksnodgrass When you’re using --manual-auth-hook, you can use “certbot-auto renew”. The manual auth hook command is remembered in the renewal configuration file and will be executed (non-interactively) when it’s renewing.


Thanks for the info. That is excellent news.


Don’t want to hijack the thread and I think this question is mostly related… there is a cleanup hook:

Are we supposed to use this to REMOVE / DELETE the DNS TXT records what we add to verify the domain with this hook. I assume so… but want to double check. I don’t want to validate the wild card cert and then remove the DNS TXT keys that it used and have my cert invalidated.

Some sites ( google ) that have you add DNS TXT records want them to stay around. Just making sure that the Letsencrypt auth records can be removed when the script completes.

Thanks - jack