Why am I getting this on a FQDN?
[Mon Jun 19 00:52:41 CDT 2023] invalid domain
[Mon Jun 19 00:52:41 CDT 2023] Error add txt for domain:_acme-challenge.
pfSense 23.05 and using Cloudflare DNS to validate.
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: nollicomm.net
I ran this command: nenew
It produced this output: see above
My web server is (include version): pfSense 23.05
The operating system my web server runs on is (include version): acme 0.74 on pfSense
My hosting provider, if applicable, is: cloudflare DNS
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):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
Is that the entire line?
If so, that's missing the FQDN.
No...was trying not to expose to the public the subdomain...that's the part about Let's Encrypt I don't like...to troubleshoot, one has to expose to the public. Here is the full subdomain that had been previously worked the same exact setup before I had to abort project due to war with ISP...
[Mon Jun 19 01:24:21 CDT 2023] Adding txt value: uQMhURuTG_A9DQYGqzAKHSr0CaxbeIyo1eJmYP28MSs for domain: _acme-challenge.nollivoipserver.nollicomm.net
[Mon Jun 19 01:24:22 CDT 2023] invalid domain
[Mon Jun 19 01:24:22 CDT 2023] Error add txt for domain:_acme-challenge.nollivoipserver.nollicomm.net
[Mon Jun 19 01:24:22 CDT 2023] Please check log file for more details: /tmp/acme/certvoip/acme_issuecert.log
Does that log file provide any more info?
The two more common reasons for that to fail is your system is 1) that your credentials are no longer correct to update your Cloudflare DNS and 2) that your system is not waiting long enough after creating the TXT record to ensure Cloudflare sync its authoritative servers.
It might be this since all else is legitimate...I believe the default is 2 minutes...I'll try and report back shortly.
There is no 2 min delay in the log you showed. It all happened within 1 second
I set it 3 minutes/180sec but it doesn't appear it working because the same results...using Acme 0.74
You could also use https://letsdebug.net/, read documentation, search for old forum threads with similar problems, or pay someone to help you privately. And if you're confident that a problem is a bug in your Let's Encrypt client application, you can also post an issue on its GitHub page.
The reason for this policy here on the forum is that people providing support here are doing so as volunteers, and an incredibly high fraction of issuance failure problems here involve either (1) DNS configuration errors [including mispointed IPv6 AAAA records] or (2) firewall configuration problems that block a challenge from succeeding. Both of those categories of problems could be detected quickly by an experienced volunteer, but many forum users adamantly deny that either of these problems could apply to their situations, while continuing to ask how to make the issuance succeed just by changing options in the client application (which will never work if the problem is in the DNS or firewall).
Well, got it resolved and it was the token (needed all zones instead of specific zone). Thanks everyone!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.