If I issue an SSL with ‘*.domain.com’ I know it will cover https://www.domain.com. But will it cover https://domain.com as well? I am sorry if this sounds like a silly question. Actually, I am new to wildcard SSL.
You need to initiate the order for both domains, complete the challenge for both, and submit a CSR with both domains as SANs.
Note that if you use DNS verification for both domains, you need to create two TXT records for _acme-challenge.domain.com (one for *.domain.com and one for domain.com).
I created two TXT records for both. But getting an error for the 2nd. (The 1st one was verified successfully.)
With https://www.whatsmydns.net I found that values for the two ‘_acme-challenge.domain.com’ getting merged.
Do I need to delete the 1st TXT record before adding the 2nd?
I wanted my client issue/renew in an automated process. But DNS propagation needs time especially if I want to add more than one TXT record (even if I add them through DNS API). This is a difficulty towards automation. What is the solution to this situation?
I switched over to the acme.sh client, and its solution is to just wait 2 minutes for the records to propagate out.
That depends on the DNS API working in real time though, I’m using Cloudflare DNS because Linode DNS only pushes out changes every 15 minutes. What provider are you using?
Yes, waiting before trying to validate the challenge helps. Maybe your DNS API allows you to wait until the values propagated to all nameservers (the Route53 API seems to allow that). For the DNS service I’m using, adding a simple delay helped (I think 15 seconds seemed to be enough for me, but YMMV).
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. crt.sh | 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:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
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):
For example, TXT value for first domain ‘_acme-challenge.domain.com’ ( for ‘*.domain.com’ ) was ‘NMP7unjG-QREl8zB-GXB6uhcP2awubfQccGaKsMq8WY’
and TXT value for the second ‘_acme-challenge.domain.com’ (for ‘domain.com’ ) was ‘m2Z1snmxsfZXPGxAnIT-sNGLTe4DAw1jPVj2q5ZdBC0’
When I searched with https://www.whatsmydns.net I got this value ‘NMP7unjG-QREl8zB-GXB6uhcP2awubfQccGaKsMq8WY
m2Z1snmxsfZXPGxAnIT-sNGLTe4DAw1jPVj2q5ZdBC0’
But you may not find those values now as I deleted them.
Maybe this is not an issue from Let’s Encrypt’s side.
Finally, I have used HTTP-01 method for the base domain (the 2nd one) and issued Wildcard SSL. So I used both DNS-01 and HTTP-01 method.
It produced this output: LE response was
Array
(
[type] => urn:ietf:params:acme:error:malformed
[detail] => Unable to update challenge :: The challenge is not pending.
[status] => 400
)
My web server is (include version): Apache 2.4.29
The operating system my web server runs on is (include version): linux
I seem to remember something about Wildcards can only work with the DNS-01 method.
I run my own (pre-CPanel) virtual web control panel system. My DNS is updated every 5-minute clock tick, so (I’m using “dehydrated”) I added a repeatable 60 second time loop to the script that after submitting the new DNS TXT records, check every 60 seconds to see if the records are active in the DNS and only then finishing off the process. Seems to work just fine, now.
If you want to setup a Wildcard certificate on your domain: sudo ./certbot-auto certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns -d *.musicdemons.com -d musicdemons.com
Notice to first write the wildcard, next the base domain. It doesn’t really matter, but if you do it like this, the webbrowser will actually show that the certificate is issued for *.musicdemons.com (the first domain in the list) instead of just musicdemons.com (without wildcard).
The script will ask you to create a DNS TXT record in your DNS.
Off course it may take a while before the DNS record is propagated but it doesn’t really matter. If you run the same command later on (like the day after) it will ask you to create the EXACT SAME TXT record.
When the first challenge succeeded (wildcard), you must also perform the challenge for the base domain. Just open your DNS mgmt again and edit the existing DNS TXT record with the second value. Then press enter again and the second challenge will succeed immediately.
This depends a bit on the circumstances. Users should be aware that the content of requested TXT record (not its name!) may also change over time, for example if the certificate issuance request fails or for a later certificate renewal.
Here also our suggested practice—if your DNS hosting environment supports it—is to leave both in place (you can have multiple TXT records with the same resource name!) until the whole process is completed. It's easy to get confused about when the different checks occur, and the details may change over time with different client applications and ACME protocol versions. I'm actually writing a Certbot change specifically to warn people about this (asking them not to remove the previous TXT record when adding a new one as part of the same certificate request).
Thanks for posting your advice—I hope people will find it useful!
Will Let's Encrypt API take the correct one if multiple TXT records exist with the same resource name?
I noticed that ACME V2 keep valid domains in memory for few days. So, as soon as one domain gets validated, I can delete the corresponding TXT record even if validations for other domains are pending?
I am not talking about Certbot. As I mentioned earlier, I am writing a client in PHP.
You can remove the TXT record immediately after updating the challenge and the challenge becoming valid. It is never checked after that point, even if the authorization is cached by Boulder for your ACME account.