I've been using certbot for about 2 years with nginx.
At the time i used separate files for the blank/wildcard subdomain and www subdomain. Such that the nginx site conf file contains several server blocks with lines pointing to the files.
ssl_certificate /usr/local/etc/letsencrypt/live/example.co-0001/fullchain.pem; # managed by Certbot
ssl_certificate /usr/local/etc/letsencrypt/live/www.example.co-0001/fullchain.pem; # managed by Certbot
Is it possible to merge by either:
Use the certonly method which may mess up the present configuration. Ive seen conflicting answers for doing this. on stackoverflow
Not sure why the process is called certonly. Does one simply view the cert and copy/paste it.. what does install mean for this process?
Or the other alternative
Manually combine/alter the certbot conf files present in /usr/local/etc/letsencrypt/renewal/example.co.conf
and then run a renew dry run which seems like it will not mess up the current conf if its incorrect.
I would also like to get rid of the -0001 profile since its from a previous mess up so the latter method may work better. Not sure.
concerned about requesting too many certs. Is there a limit on renewals.
Unless I understand you incorrectly: it's not possible to have a wildcard cert and a subdomain which could also be "fitted" into that wildcard. E.g., it's not possible to have a single cert with *.example.comandwww.example.com, because the latter would be superfluous to the former.
The certonly subcommand does just that: it only gets a cert. I.e.: it does not install the certificate into the webserver. It can use the webserver to get the cert, but it's just that: only a cert -> certonly.
Also, I would not recommend using guides from more than 5 years ago, as Certbot has had quite a numerous amounts of releases since then.
it's not possible to have a single cert with *.example.comandwww.example.com , because the latter would be superfluous to the former.
wildcard is the incorrect term. I should say empty or none as in example.com
The certonly subcommand does just that: it only gets a cert . I.e.: it does not install the certificate into the webserver.
But it does insert a cert onto the server filesystem it would seem.
Install then means insert a line into the webserver conf file with the location of said cert file.
All right. Given the old guides in your opinion should i do the certbot certonly -d example.co -d www.example.co and simply alter my webserver conf file.
Also after that process, can one remove the older seperated /usr/local/etc/letsencrypt/renewal/** files with no issue at all.
In your experience have you found a limit to the certs provided during the learning process
Sure, it needs to save it to the filesystem obviously.
Correct, and if required make a HTTPS virtualhost using the relevant HTTP virtualhost as template.
Depending on how you got your certificate in the first place (also with certonly?) you might simply want to use certbot --nginx -d example.com -d www.example.com. I.e.: use the run subcommand (which is implicit when no specific subcommand is specified) instead of the certonly subcommand which is like certonly and install combined: get a cert and install it too.
Please don't manipulate any files in the /letsencryp/ manually.
You can get an overview of which certificates are known to Certbot with the certbot certificates command. Please notice the "Certificate Name:" in the output followed by, well, the name of the certificate.
Doublecheck your webservers configuration and make notion of which certificate is in use (the certificate name is equal to the folder name in the ......./letsencrypt/live/certificate-name-goes-here/fullchain.pem path.
You can delete any certificate NOT in use by running certbot delete --cert-name certificate-name-goes-here.
you might simply want to use certbot --nginx -d example.com -d www.example.com .
Does that look into the renew folder first in order to see if it's actually a renew. Or possibly creates a new profile named example.com-0002 with new certs?
Thanks for the assistance though. A lot of the issue is fear of screwing up a webserver that needs those current certs in place.
Modern versions of Certbot should recognise existing certificates and ask to update the best match. 2.8.0 isn't the newest, but fairly recent. It's also possible to use --cert-name to specify a specific name when issuing.
