I have to renew Let's Encrypt certificates on my Debian server. By some reason the renew option doesn't works, and nor the certbot-auto script.
This below command works, but asking some questions:
sudo certbot --server https://acme-v02.api.letsencrypt.org/directory -d *.blogginger.com --manual --preferred-challenges dns-01 certonly
Questions while I'm running this command:
Would you like to redirect HTTP to HTTPS? I choose here option 1
Are you OK with your IP being logged?
and press Enter at the end.
How can I skip these questions? Which parameters should I use with certbot?
Thank you!
The solution was this below command to renew all certificate on the server, included the mentioned certificate as well:
sudo certbot renew
I insert this command in crontab for never forget to renew any certificates:
0 4 * * 0 sudo certbot renew
It will send a request at every early morning of Sunday.
Hide standard output and show only errors by addig "-q" parameter:
sudo certbot renew -q
It seems like letsencrypt have forgotten the options used when generating the certs originally.
If you manually run just certbot, with only the least possible options, and when asked, select the "don't alter apache config" option, I think the options will be saved for next run of certbot-auto renew
Related
I run Let’s Encrypt with this command:
./letsencrypt-auto-source/letsencrypt-auto certonly --manual \
--manual-public-ip-logging-ok \
--email john#example.com \
--agree-tos \
--domain example.com \
--domain www.example.com \
--rsa-key-size 2048
I get the following error message:
Skipping bootstrap because certbot-auto is deprecated on this system.
./letsencrypt-auto-source/letsencrypt-auto has insecure permissions!
To learn how to fix them, visit https://community.letsencrypt.org/t/certbot-auto-deployment-best-practices/91979/
Your system is not supported by certbot-auto anymore.
Certbot cannot be installed.
Please visit https://certbot.eff.org/ to check for other alternatives.
So, how to tell Let’s Encrypt to no be as perfectionist as he is? Am just in a test project and no need all this suspicious behavior. Also, there is no need to do all the annoying stuff asked.
So, basically, how to telle Let’s Encrypt “Just let it go. I know what I am doing”?
According to the official ACME.SH documentation link, issuing a certificate is as simple as running the following command:
$ acme.sh --issue --alpn -d example.com
However, I am getting the following error
Error, can not get domain token entry example.com for `tls-alpn-01`
The supported validation types are `http-01` `dns-01` , but you specified: `tls-alpn-01`
I have tried switching from the default ZeroSSL.com to BuyPass.com, but that does not help. It seems that these providers do not allow tls-alpn-01 validation method, but it could be related to something that I am missing.
PS:
To preemptively answer some questions:
I have a valid domain that I replaced with "example.com"
The site is functional on a 443 port, but port 80 is blocked by ISP, hence tls-alpn-01
I am stopping Nginx, and then checking with netstat that port 443 is not bound to a service.
When I run the script with --debug 2 parameter, I get the following value for _authorizations_map variable
_authorizations_map='example.com,{"identifier":{"type":"dns","value":"example.com"},"status":"pending","expires":"2021-08-18T22:53:50Z","challenges":[{"type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/wYehJ8kQjUDiDadBJ12qKw", "status":"pending","token":"Sfga2N2KwV-2hg3wo1gYAoyFvqV87dRvG2sHw4I6ups"},{"type":"dns-01","url":"https://acme.zerossl.com/v2/DV90/chall/CkrMQdEJthf-TmWvllW-Bg", "status":"pending","token":"_AlgMGzIfSQs7673Su-njnpieba_zLpSYxiUdXDEFnz"}]}'
Same problem, I switched from ZeroSSL to Let's encrypt CA and now it works without problems.
https://community.letsencrypt.org/t/the-acme-sh-will-change-default-ca-to-zerossl-on-august-1st-2021/144052
Edit: oops, sorry.
To tell acme.sh to use Let's encrypt CA
use:
acme.sh --set-default-ca --server letsencrypt
and then try to issue again the certificate in tls-alpn-01 mode
I am trying to obtain an SSL certificate with certbot and the --webroot setting. My current command is:
sudo certbot certonly --webroot -w <path> -d <URL> -d <*.URL>
Every time I run the command I get this error:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
I tried every similar command I found. Please share some help.
I am using ubuntu 18 with the newest certbot version. I also tried certbot-auto
I figured it out: with the http verification (webroot) it is not possible to obtain wildcards (<*.url>).
But it is possible with a DNS challenge (Reference).
Here is an example command for a manual / DNS challenge wildcard certifiat request:
sudo certbot certonly --manual -d *.<domain> -d <domain> --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server acme-v02.api.letsencrypt.org/directory
I want to provide some further reading on this for anyone else struggling - and I'll explain why every solution still didn't work!
Great advice from Letsencrypt ...
https://community.letsencrypt.org/t/client-with-the-currently-selected-authenticator-an-authenticator-script-must-be-provided-when/153921
https://letsencrypt.org/docs/challenge-types/ - see DNS-01. Basically Certbot has to connect with your DNS provider/api to create temporary records to verify your domain.
BUT ... not all providers allow this ...
https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438
And it turns out mine (Namecheap) doesn't. So in short Wildcards + Certbot + Namecheap are not physically possible!
certbot was installed and version is 0.32.0. It was working fine, but certificate is expired recently. I want to renew it by using this command
certbot-auto renew
but got command not found issue. Tried 'sudo', same problem.
Any idea on the root cause?
Thanks a lot!
For the auto renew to work, you need to add this renew command to crontab.
To edit the crontab:
crontab -e
This will open a file with crontab configurations.
To configure the cron to execute this command every 12 hours, add the following line:
0 */12 * * * root certbot -q renew --nginx
To know how to configure a different time to run the command, check the crontab references.
For auto renew certbot certificate, the following command working with me.
sudo certbot renew --dry-run
You can check certbot instructions.
I have a working setup where Let's Encrypt certificates are generated with certbot. I wonder how you effectively test whether the renewal will work in production.
The certificates last for 90 days. Is there a way to reduce the lifespan to, for instance, 10 minutes, to see if the renewal works? (Using the staging system for that is fine.)
If you have an alternative approach how to make sure that your renewal code works (without having to wait for 90 days), it would also be appreciated.
You use the --dry-run option. E.g.:
$ sudo certbot renew --dry-run
From certbot -h:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
...
--dry-run Test "renew" or "certonly" without saving any certificates
to disk
This ensures that the certbot can validate your domain with your current configuration.
If you really want to save the certificates to disk and see if your system is using the new cert, then you can also use the --force-renewal option. In that case, you should visit your website and check that the active certificate is the new one. If it isn't, you likely need to adjust your cronjob to restart your web server. E.g.:
certbot renew && service apache24 restart
You can use "certbot renew --force-renewal"
https://certbot.eff.org/docs/using.html#configuration-file
--force-renewal, --renew-by-default
If a certificate already exists for the requested
domains, renew it now, regardless of whether it is
near expiry. (Often --keep-until-expiring is more
appropriate). Also implies --expand. (default: False)