Hello everyone. I have been using certbot-auto for years (Mint 18 Apache) up until October with no issues. I set up a shell file to edit my conf file to temporarily disable my apache rewriteengine on all my 14 domains so that the http tests can happen on all 14 domains (same server IP address with 14 domains using virtualNameServer 14 times in my http conf file), and then I issue autocert command:
sudo /etc/certbot-auto certonly --debug --webroot -w /home/home1/dir1 -d www.domain1.co -d domain1.co -d ico.domain1.co -d manage.domain1.co etc .... for 14 different domains. It writes the entire set of certificates to:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/ico.domain1.co/fullchain.pem
Your key file has been saved at:
.... etc ....
Your cert will expire on 2023-02-11
then the shell restarts the apache server.
My questions are, 1) why do I now see "your system no longer supports certbot-auto" and 2) if I change over to snap and --classic certbot wont that break my system for running multiple certs on mutlple domains? certbot classic seems to have no examples with qualifiers for multiple domains on one server. And 3) certbot-auto still works just fine for me, so why the warning message? and what does it mean to replace the --webroot and specifying exactly all the domains with -d -w and -webroot qualifiers with just a:
certbot -- command that seems not to have any qualifiers to specify the exact domains being certified.
Any help to mirror exactly what I am doing with certbot-auto without breaking my system would be appreciated. Thank you!
Hi @kensilverman, and welcome to the LE community forum
Because it's outdated and needs to be replaced.
No; It should continue doing the exact same thing as today.
Because it's outdated and needs to be replaced.
It means that you don't have to be explicitly detailed on the command line if nothing has changed.
You can just renew the previously issued certs via the same method [without having to detail it each time]. certbot renew
Note that certbot-auto was just a wrapper script around the same Certbot that is installed using snap. Please do NOT mess everything you already have by making new commands. It should be as simple as to replace certbot-auto renew with certbot renew. Nothing else is necessary.
I don't use renew I use "certbot-auto certonly -webroot -d ..... -w ...". Do all the same qualifiers work with certbot instead of "certbot-auto" simply take out the word auto? I am concerned because certbot will also try to write to my .conf file write?
How can "certbot renew" replace my having to mention the exact domain names with -webroot and -d (domain) and -w (workspace) qualifiers? How can it know all the domains I have set up? Or even the name of my .conf files which are different? Are you suggesting that it will scan all my .conf files and find all my virtualNameServer segments and find all the do0m0ains automatically? And then recruit my conf files to include the path to the cert and key files (for all those domains) when it is done? It is possible, but I highly doubt it.
Yes, except for perhaps a few certbot-auto script specific options. But looking at your example you're not using those.
How do you mean? As said, certbot-auto was just a wrapper script around certbot. Certbot already wrote to your .conf files, unless you told Certbot not to. There is absolutely no difference between running certbot-auto and certbot with regard to that. They are the same ACME clients.
Once you've run certbot-auto certonly blahblah, Certbot will store the required information in renewal configuration files. That way, if nothing changes, you can just run certbot renew and it'll do exactly the same as before for all stored certificates.
ahh ok, now i understand. I see. But no my certbot-auto never wrote to my conf files because I manually pointed each virtualnamespace domian to the cert file at /etc/letsencrypt/live/ .... etc ... The trick is to know where certbot puts those files (it uses the last -d -w designation for all of them) so I never needed to update my conf file again (except turning off and on the rewrite engine so certbot can do the http test.) I did all this in a shell script. So how do I specifically request not to write to the conf files? Is it the --debug qualifier which I use now? Otherwise it would be exactly nice to know what conf file it writes to and exactly what it pus there for apache. Probably just the cert lcoation that I already have set up. But ok, I guess I can use the snap cvertion if nothing wil change and I can be assured of the qualifier not to write to my conf files even though I don't think I specify such qualifier now. All I use is --debug --webroot -w and -d and certonly qualifiers. Are any of these the one that prevents writing to my apache configuraton conf.d files?
That's perfectly fine, many users configure their webservers manually using certbot certonly. There is absolutely no difference between certbot-auto and certbot in that regard.
No, the certonly subcommand instructs Certbot not to install the certificates into a webserver.
When not using certonly, Certbot would make a HTTPS virtualhost from the corresponding HTTP virtualhost. But there's nothing wrong with doing that yourself manually.
" Why in the world would you want to do that? " Good question, So to be clear, why would I not want to write to my .conf files? Well, because nothing ever changes there assuming the path to the renewed letsecrypt/live cert files never changes. SO ideally, I would:
issue my long command in my script file - just once. and then in the future just issue:
"certbot renew certonly"
Will that work? Do I also lose the cron job insert by specifying certonly? If so, then I have to issue the "certbot renew certonly" every 3 months right?
I mean, yeah, I suppose I could trust writing to my .conf files but I just dont think it will work to automatically locate each #virtualNameSpace segment and then overwrite my cert path references. Maybe it will but why bother since it will never change (if certbot does not change the locations arbitrarily in the future). And one more thing: "certbot" and "renew" will not work unless it also turns off my rewrite engine temporarily - and I don't think it is set up to do that right? So I still have to run my script to turnoff before and turnon after certbot is run. So if I am running a script anyway that I could put in a cron job myself (and can assume the path to the live certs and key files does not change with "renew", I might as well just keep running my full script in a cron job, simply changing out the certbot-auto for certbot right?
Well, I do hope it works. Shame they could not just point certbot auto to the new snap version and save us all the time on this. Simply making "renew" an optional new tag for those of us who don't already have cert in a script.
Thank you so much! So it appears the only thing I lose by not updating my certbot-auto to certbot --classic is possibly nothing since there are likely no changes when doing certonly? Or is that still risky not to change over? What can change for example could you imagine in the future on certbot that would break certbot-auto? Perhaps the actual handshaking that letsencrypt uses for the http verification part of temp files (i.e. proof that I control the server) could change or something like that?
You're probably running a (very) old version of Certbot. Switching to the snap installation method instead of the now defunct wrapper script means you'll always be running an up to date Certbot, as snap updates Certbot automatically.
Running old/ancient versions of Certbot means you won't have bugfixes, security fixes, new features and/or the possibility something will become incompatible in the future (not likely, but possible).
Also note that the --classic option is just an option for snap to install Certbot. It won't be used in the actual certbot command.
The certonly subcommand is not necessary when using the renew subcommand. In fact, both ar a subcommand and you can only use one of them: they are mutually exclysive.
Frankly, I would very much recommend you to read the actual Certbot user guide at User Guide — Certbot 2.6.0 documentation. Because I have the feeling you have, no offence, absolutely no clue at all how Certbot actually works.
Yeah, you all have been so helpful. It appears if I did not use "certonly", that a NEW cond.d file would be created with redundant virtualNameSpace segments that would specify the exact path to /etc/letsencrypt/live certs. So, because there eis no guarantee which conf file apache would run first, I would have to remove all my cert paths from my existing conf files. Anyway, if we can assume that the new certbot will never change such location on a "renew" then best to leave my script as "certonly". Further, since I must have in a script anyway (certbot does not turn off my rewriteengine which I think would be required for ALL OF US if you have automatic http to https redirect on your webservers - highly recomended btw, I may as well go once step further and just put my full script in the cron job and not bother with "renew". "If it ain't broke ..."
"redundant virtualNameSpace segments"? I have no idea what you're talking about. As sane Apache configuration would only have one HTTP (port 80) and one HTTPS (port 443) VirtualHost section per hostname (and aliasses). There is nothing redundant about that. There should NOT be duplicate VirtualHost sections what so ever.
I have absolutely no clue what you mean by this. "Which conf file would run first"? That doesn't matter in a sane Apache configuration.
I fail to see the relationship between the requirement of a script and turning off RewriteEngine. Also note that there are other methods of redirecting HTTP to HTTPS than RewriteEngine.
You are correct I have little time or energy as a computer engineer myself to get into even more details of this stuff, However that said I am very familiar with how certbot creates a temporary directory for testing before being able to issue a cert. and I am familiar with and have coded encryption algos. in general. What takes me a lot of time is trying to learn other people's code.
