OK I need to know EXACTLY how to renew my certs. I have two. I run directly in command line. I installed git in order to do this and I have the following:
/etc/letsencrypt
accounts acme-v01.api.letsencrypt.org
directory
(randomthing)
meta.json
private-key.json
regr.json
archive
(mydomain1)
cert1.pem
chain1.pem
fullchain1.pem
privkey1.pem
(mydomain2)
(same filenames as for domain 1)
csr
0000_csr-certbot.pem
0001_csr-certbot.pem
keys
0000_key-certbot.pem
0001_key-certbot.pem
live (I get, there are the ones I am using in there so won’t specify it fully)
renewal
(domain1).conf
(domain2).conf
I issued some kind of command like ./letsencrypt-auto certonly --standalone – email (my email) -d (subdomain1) -d (subdomain2) etc. to generate the certs.
EXACTLY what command should I issue FROM WHERE in the ubuntu command line to renew my certs. Does Apache have to be stopped in order to do it? I am not an expert on this and I shouldn’t have to be. I just need a recipe. It would be nice if they had better info or more easy to find info on the main website. THANK YOU
When you first obtained your certificate, Certbot would have printed a message starting with “Congratulations!”. This message includes two suggestions for how to renew the certificate, one of which is to run the exact same command again, and another of which is to use ./letsencrypt-auto renew.
For certificates that were obtained using --standalone, normally Apache does need to be stopped during the renewal process. There are some exceptions to this if Apache happens to be listening only on one port instead of two, but the normal case is that the web server should be stopped in order to use --standalone. This can be considered an argument against using --standalone if you don’t absolutely have to.
You’ll want to be in the same directory that you were in when you previously ran ./letsencrypt-auto, which would be the same directory that you downloaded ./letsencrypt-auto into. If you don’t remember where that is, you can probably find it out from your command history (run history) or by running locate letsencrypt-auto.
The letsencrypt program was renamed to Certbot more than a year ago, so your use of ./letsencrypt-auto suggests that you may be following an old and possibly out-of-date tutorial, rather than the documentation on our web site at https://certbot.eff.org/. (The ./letsencrypt-auto command still works in the same way, and nothing bad will happen as a result of using it.)
Thank you. Yes I was following a tutorial that was about a year old. I
will do it the certbot way next time. I think I got it done by taking a
wild guess that if I just did the same thing again that I did last time
(I had detailed notes on it) that it would just make all new certs. It
seems to have worked. The harder part of this process was twerking all
the virtual host configs for apache, and that is done and I didn’t have
to change anything there. I’ll just put it in a cron. Would there be
any advantage at all to using --standalone? I did, but I was just
following the direction. What is the difference?
The --standalone method is mainly intended for people who are not running a web server on the computer where they obtain the certificate (for example, if they intend to use it for an e-mail server or some other kind of service). If there’s a tutorial out there suggesting using it for some other reason, it’s almost certainly giving bad advance.
Certbot remembers what authentication method you used when you obtained the certificate, and uses that method again if you run certbot renew. So if you got your certificate with --standalone, it will also be used for renewal.
You can change the authentication method by running certbot certonly --force-renew --cert-name your-certificate-name (filling in the appropriate name in place of your-certificate-name, as listed in the output of certbot certificates), plus the authentication option(s) that you want to use, plus -d flags for each domain name that the certificate should cover. For example, if you wanted to use --apache instead, you could run
Usually --apache and --nginx are best for people who are running those servers, and --webroot for people who are running a different web server, or who can’t get --apache or --nginx to configure their servers appropriately. (Until recently, --webroot was recommended for all Nginx users, but now we suggest trying --nginx instead.)