Certbot wildcard certificate invalid for base domain


My domain is:

I ran this command:
sudo certbot certonly --manual -d “*.tentacom.net” --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Using certbot 0.23.0.dev0
(from git, commit b6afba0d64c7d0798afb8df609ca2ba4233b0816, Date: Wed Apr 4 14:33:41 2018 -0700)

It produced this output:
(certbot processing all normal)

The resulting wildcard certificate comes up valid in Firefox/Chromium/Chrome for a subdomain (such as www.tentacom.net), however it comes up as INVALID for the base domain (tentacom.net)
Firefox reports:
tentacom.net uses an invalid security certificate.
The certificate is only valid for *.tentacom.net

My web server is (include version):
nginx 1.10.3-1+deb9u1

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

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

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


Yes, that’s correct. *.tentacom.net does not include tentacom.net.


You need to request the wildcard AND root on the same cert, and validate challenges for both.

certbot certonly --manual  -d “*.tentacom.net” -d tentacom.net --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

beware that some DNS systems will cache the first TXT record for the life of the TTL, so I suggest waiting a few minutes after setting the second challenge before continuing.


Thanks for your very quick reply!

I’ll take your point in the context of Let’s Encrypt certificates, however I do note that I have other wildcard certificates that appear to do exactly that?

So how is this resolved in Let’s Encrypt?
If I request using
-d tentacom.net -d “*.tentacom.net”
then certbot’s DNS-01 verification process runs as follows:

Plugins selected: Authenticator manual, Installer None

You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/tentacom.net.conf)

It contains these names: *.tentacom.net

You requested these names for the new certificate: tentacom.net, *.tentacom.net.

Do you want to expand and replace this existing certificate with the new
(E)xpand/(C)ancel: E
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for tentacom.net
dns-01 challenge for tentacom.net

Please deploy a DNS TXT record under the name
_acme-challenge.tentacom.net with the following value:


Before continuing, verify the record is deployed.
Press Enter to Continue

Please deploy a DNS TXT record under the name
_acme-challenge.tentacom.net with the following value:


Before continuing, verify the record is deployed.

So then it effectively asks me to have two different TXT records for the same domain.
The DNS server is fine with that, but will the ACME system be ok and check beyond the first TXT record?

Also, which should be specified first, the base domain or the wildcard?
I believe this affects which name gets put in to the common name of the certificate.


It’s how certificates work, not a specific limitation of Let’s Encrypt. Your other certificates evidently include both example.com and *.example.com.

A lot of CAs automatically add extra names to certificates, like adding “www.example.com” to a non-wildcard certificate, or adding “example.com” to a wildcard certificate. Let’s Encrypt doesn’t.

Yup! :slightly_smiling_face:

For most purposes, it doesn’t matter – modern clients check all the names in the SAN list, not (just) the CN.

If you put tentacom.net first, the certificate will be a couple bytes smaller.

If you care about super old clients, I guess you should pick whichever one you need to work more.


Awesome, thanks for the clarification.

From observation, most blog articles posted on “how to get a wildcard certificate with Let’s Encrypt” are thus incomplete and incorrect…


I can confirm that the extended process as described in this thread indeed works.
Thanks all!


Hmm one more pondering, what happens around renewal - do the TXT fields remain valid for a renewal, or do they need to be updated?
Do I need to adjust settings in the letsencrypt configs after the initial certificate is retrieved, because the process used --manual. Will the renewal process be happy running without user input?


Hi @arjen,

The current TXT records won’t be valid, you will need to update them.

If you issued your certificate using the manual option then you will need to renew it the same way, certbot won’t renew it without user input. The only way to renew it automatically is providing a hook script to automate the creation of TXT records for your domain(s). Seems you are using linode dns servers so you could use lexicon to automate the process, take a look to this guide https://id-rsa.pub/post/certbot-auto-dns-validation-with-lexicon/



Hi @sahsanu,
k clear, thanks.

Only (some of) the DNS slaves are Linode, we run our own primary.
I was looking at RFC 2136 (lexicon-dns doesn’t support that generic approach yet, it focuses on hosting providers) but haven’t worked through the details of that yet.



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