Is it expected behaviour that if using a pipe and grep to filter out the list (I've got about 100 SSL's on this server) that it would output the FQDN i'm looking for, but then error out and delete all SSL's?
My domain is:
test.domain.tld
I ran this command:
sudo certbot delete | grep "test.domain.tld"
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
128: test.domain.tld
Skipped user interaction because Certbot doesn't appear to be running in a terminal. You should probably include --non-interactive or --force-interactive on the command line.
Deleted all files relating to certificate test.domain.tld.
My web server is (include version):
Apache 2.4.41-4
The operating system my web server runs on is (include version):
Ubuntu 20
My hosting provider, if applicable, is:
N/A
I can login to a root shell on my machine (yes or no, or I don't know):
Yes
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 2.7.4
InvalidDomain
FATAL
"test.domain.tld" is not a valid domain name that Let's Encrypt would be able to issue a certificate for.
Domain doesn't end in a public TLD
The issue is there does not exist a top level domain .tld.; you have no domain name.
Thus you need to own and have control over the Domain Name (or have a subdomain under an existing domain name, for example pointed to your server by your employer or school) you wish to obtain a certificate for, from an ICANN Accredited Registrar.
Since these are Domain Validation (DV) certificates the Domain Name System (DNS) is used extensively in the validation process as well a allowing us to assist here on Let's Encrypt community.
DNS Queries need to give consistent results from any location on the Internet, all your authoritative DNS Servers for the Domain need to also give consistent results as well.
Testing and debugging are best done using the Staging Environment as the Rate Limits are much higher. Rate Limits are per week (rolling).
And to assist with debugging there is a great place to start is Let's Debug.
This is the format sudo certbot delete --cert-name example.com;
the | operator takes the output from the left side's stdout and feeds it in to the right side's stdin.
thanks guys, I believe this to be a bug so I will submit the bug report to them.
and yes, I agree a vary valuable lesson learned, thankfully I have backups of my /etc/letsencrypt folder to recovery was easy and downtime was minimal but still.
I didn't, I was wondering why certbot deleted all of my certs with no prompts or warnings.
the output I got was the grepped line I wanted, followed by the "skipped interactive..." message followed by a message that it deleted all certs related to the one I entered.
No where in the output does it indicate that all certs were deleted.
It sounds like the intension of the grep was to feed back the input required by the certbot command.
But grep's output shouldn't go to the standard input.
So, at best, it only reduces certbots output to only a line that contains the grep string.
But without certbots' instructions...
How is anyone supposed to know what to do next?