I am running letsencrypt-auto. I have started to receive the following message:
You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages.
I thought the whole point of letsencrypt-auto was that it kept itself up to date. How is this happening?
Regards
Tony
The client was renamed to certbot a couple of releases ago. Along with this release, a new -auto script called certbot-auto was released. This new script introduced some backwards-incompatible changes, while the letsencrypt-auto script was essentially kept backwards-compatible to prior releases of the client. While letsencrypt-auto will continue to work for the time being, the goal is to get users to migrate to the newer certbot-auto script (or a packaged version), so that’s what this message is essentially about.
Any instructions on making the switch? I can’t seem to find any on this site or elsewhere?
It’s a drop-in replacement - follow the instructions from https://certbot.eff.org/. If you have existing scripts that currently use letsencrypt-auto, replace that with certbot-auto. Configuration and certificates are still stored in /etc/letsencrypt and will continue working.
In my case, I’m using the recommended package from EPEL (CentOS 7) and seeing the message still. Not sure if this is a packaging issue that needs to be reported or a bug in the client.
Having the same issue here. Running Fedora 23 with the latest repo version of CertBot and get the same error message when trying to do a cert operation. Checked and don’t have either a letsencrypt-auto or certbot-auto on the machine:
psf:~$ rpm -qa certbot
certbot-0.8.1-1.fc23.noarch
psf:~$
psf:~$ whereis letsencrypt
letsencrypt: /usr/bin/letsencrypt /etc/letsencrypt
psf:~$ whereis letsencrypt-auto
letsencrypt-auto:
psf:~$ whereis certbot
certbot: /usr/bin/certbot /usr/share/man/man1/certbot.1.gz
psf:~$ whereis certbot-auto
certbot-auto:
psf:~$As per Certbot, the command is just
certbot
Let us know if you get the same error using that. Might help you too, @motoko?
From User Guide — Certbot 2.7.0.dev0 documentation
Many platforms now have native packages that give you a certbot or (for older packages) letsencrypt command you can run. On others, the certbot-auto / letsencrypt-auto installer and wrapper script is a stand-in. Throughout the documentation, whenever you see references to certbot script/binary, you should substitute in the name of the command that certbot.eff.org told you to use on your system (certbot, letsencrypt, or certbot-auto).
Apologies, should have made it clearer, I am currently running the certbot command, to be specific:
psf:~$ sudo /usr/bin/certbot renew --standalone --noninteractive --pre-hook "systemctl stop nginx; systemctl stop postfix" --post-hook "systemctl start nginx; systemctl start postfix"
[sudo] password for psf:
2016-06-23 09:41:17,613:WARNING:certbot.cli:You are running with an old copy of certbot that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages.
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/example.uk.conf
-------------------------------------------------------------------------------
The following certs are not due for renewal yet:
/etc/letsencrypt/live/example.uk/fullchain.pem (skipped)
No renewals were attempted.
psf:~$My guess is something in the
def possible_deprecation_warning(config)
section in https://github.com/certbot/certbot/blob/master/certbot/cli.py. I am not following it after a long day, but hopefully that points someone in the right direction.
This could also just be a false warning and it will update - possibly.
In my case, it’s the same as what @psfshr wrote. The question is if it’s a bug in the client or if something needs to be done in the packaging process.
At least for now, based on the code, I have found that adding no-self-upgrade = True to /etc/letsencrypt/cli.ini will silence the message.
This is almost certainly a a bug but I cannot quite follow the logic
Just did a fresh setup on a new CentOS7 box from EPEL with the same issue, so looks like its something in the Fedora/EPEL release.
Same issue here.
There is a Redhat bug report on this. Last entry says “New packages underway”:
https://bugzilla.redhat.com/show_bug.cgi?id=1348391
The temporary workaround I am using in my /etc/cron.daily bash script:
/usr/bin/certbot renew -q --no-self-upgrade
The instructions at https://certbot.eff.org/#ubuntuother-apache seem to be insufficient. I did the following successfully:
$ sudo wget https://dl.eff.org/certbot-auto $ sudo chmod a+x certbot-auto
However, the following seemed to fail:
$ sudo ./certbot-auto --apache Too many flags setting configurators/installers/authenticators 'webroot' -> 'apache' $ sudo ./certbot-auto --apache certonly Too many flags setting configurators/installers/authenticators 'webroot' -> 'apache'
What should I do next?
Is it possible that you have a config file (for example /etc/letsencrypt/cli.ini) that tells certbot to use the webroot plugin? This would conflict with --apache. I would recommend either changing your cli.ini file to use the apache plugin instead if that’s your intent, or get rid of the cli.ini file completely and pass all configuration options via arguments.
I have several arguments in /etc/letsencrypt/cli.ini:
rsa-key-size = 4096 email = me@mydomain.com authenticator = webroot renew-by-default = true agree-tos = true renew-by-default agree-tos
However, how is the following command reading my cli.ini file?
$ sudo ./certbot-auto --apache
I did not tell certbot-auto to read /etc/letsencrypt/cli.ini
If it is automatically reading my cli.ini file, then do I change the following:
authenticator = webroot
to
authenticator = apache
?
If that works, then how do I tell certbot-auto to renew the certificates for my domain?
https://certbot.eff.org/#ubuntuother-apache says to run:
./path/to/certbot-auto renew --quiet --no-self-upgrade
Does that automatically figure out which domains have certificates and therefore knows which certificates to renew? Or, do I append the argument for the domain, such as the following?
./path/to/certbot-auto renew --quiet --no-self-upgrade /var/www/example.com/public_html -d example.com -d www.example.com
/etc/letsencrypt/cli.ini is one of the paths certbot (or letsencrypt prior to the rename) checks by default.
That would work, yes.
Yes, the client checks for configuration files stored in /etc/letsencrypt/renewal. There should be one file for each certificate you've obtained previously, and the file contains the exact settings/arguments you used to get the certificate, so renew will re-use those.
Typically, you don't add any arguments to the renew command (other than things like --quiet or --no-self-upgrade). If you find yourself needing to change any of the configuration flags, the best way is to repeat the command you originally used to obtain the certificate and change the parts you need (like add another -d argument to add a domain, etc.). Alternatively, you can also modify the renewal configuration files mentioned earlier.
If all you want to do here is switch from letsencrypt-auto to certbot-auto while preserving all your settings, certificates, etc., ./certbot-auto renew is probably all you need to run.
In my /etc/letsencrypt/cli.ini file, I changed
authenticator = webroot
to
authenticator = apache
I ran the following and got the following error message:
/opt/letsencrypt$ sudo ./certbot-auto --apache
The apache plugin is not working; there may be problems with your existing configuration.
The error was: NotSupportedError(‘Apache plugin support requires libaugeas0 and augeas-lenses version 1.2.0 or higher, please make sure you have you have those installed.’,)
What should I do next? How do I install libaugeas0 and augeas-lense? What is certbot-auto --apache supposed to do anyways?
What OS (and version of that OS) are you running this on?
It is Ubuntu 12.04.4 LTS