Certbot without automatic system updates


#1

The first time that I’ve used the official client a few days ago I was scared!
It updated the system packages (CentOS 6), installed new ones and that was just a ./letsencrypt-auto --help.

That may be a reasonable for a beta phase product on a test/dev server, but not exactly what you expect to have on a production system.
The problem persists on certbot-auto.

I’ve found the topic at Not impressed, far too many serious problems to enumerate this and other issues that I’ve found, but that was back in november.

From what I’ve found in the documentation, the official command to use is certbot-auto, not certbot which is hidden somewhere on your system.

In order to automate the process, I’ve added the -n --no-self-upgrade arguments in the cron script, but I’ve seen that --no-self-upgrade wasn’t a suppose to be an argument to be used outside of the developers and testers of the client.

So, my question is: what are the options that I have to use certbot without installing a bunch of software without any questions when I first run the program for the first time?
And how should I automate the certificates issuing without the same problems?


#2

The original letsencrypt-auto script was written to install all dependencies automatically, without any confirmation, even when --help was used.

When certbot was released, a new script called certbot-auto was included as well. This script won’t install anything when you run certbot-auto --help. In addition, it won’t install any system packages without asking you to confirm first - meaning you get the usual yum installation dialog with [y/N]. In order to stay backwards-compatible for users of the old letsencrypt-auto script, this change was only made to certbot-auto.

Using certbot without any of the system packages it requires won’t be possible - they are required in order for certbot to work. Think of it like a rpm package with dependencies on other packages. If you want to avoid automatic updates being installed (which might theoretically install additional dependencies), --no-self-upgrade is appropriate. I would recommend doing an occasional manual update once every while in that case.

If you’d rather use a client without any kind of dependencies, there are a couple of options on the list of other client implementations. Most of them don’t provide the kind of automatic configuration that certbot has, but they might be a better fit here.


#3

Where the preferred situation is to use the distributions official package manager to install certbot. Then any dependencies should be resolved by the package manager and nothing else.

Ahem… Well, if there is such a package in the distribution’s repository, that is.

I happen to be “lucky” since I use Gentoo Linux. Our package system ‘portage’ used to have the ‘letsencrypt’ package in a few versions. Now we have the ‘certbot’ package available. We thereby have a supported “upgrade path” from ‘letsencrypt’ to ‘certbot’.

Of course, not all distributions have and do this. The right way would, for most distributions, be to file a ‘package request’ in the distributions ordinary way, like for instance through Bugzilla or what have you for the distro in question.

Only if this is not possible, or if it’s way too slow to get a package within a reasonable time frame, would I go for a git pull. (Or maybe if I needed to overcome some limitation in the normally distributed package by using the latest, greatest and least tested, “still smoking” software from git.)

Having a distribution-provided ‘official’ package installed also means that in some 99+ % of the cases, you don’t want to have any software update itself, through ‘certbot-auto’ or equivalent means. That would totally brake your software maintenance routines. A later “official” upgrade could actually become a downgrade from a ‘git’ package to the distro’s latest package. Personally, I’d be very, very careful not to use that kind of “self-upgrading” software. But yes, I can say so because I happen to be so lucky to have an “official” upgrade path in my distro.

I would encourage any CentOS users to push for an “official” CentOS package of ‘certbot’ as soon as possible. Likewise for any other distribution lacking the ‘certbot’ package.

Finally, with the change of ownership of the Let’s Encrypt client software, I believe we should probably start discuss the new ‘certbot’ client on EFF’s support forum. EFF is responsible for the client now.

Yet another reason why Let’s Encrypt should better describe the ‘three-tier’ design of:

  1. LE as a CA service

  2. The multiple clients to obtain a cert, built, maintained and documented as different initiatives by several different organizations.

  3. The configuration of all kinds of different Web servers to use the obtained certificate. This will most likely require at least a minor tweak by a human being before it’s fully functional.


#4

Reply to self. (Sorry.)

I just went over to the EFF site https://certbot.eff.org and I noticed that the text in their ‘support’ link https://certbot.eff.org/support/ points any visitors come here for support. Sorry.

Personally, I couldn’t disagree more. I strongly believe ‘certbot’ should have it’s own support forum at the EFF site, but well…


#5

Thank you for your answer, @pfg.

certbot-auto with no automatic updates before confirmation is a much better option.
And if using it with the --no-self-upgrade argument doesn’t makes any updates, then I’m happy with it. At least for the moment.

I’m testing other clients, but I would prefer to use certbot-auto, being it sort of the official one, and a very good one. Unfortunately it doesn’t comes with a dns-01 authentiction method, but maybe in the future.


#6

From what I know, the RPM system, used in CentOS, also provides a method of update that would update from a letsencrypt to certbot, if needed.
I’m using CentOS 6, with is not the latest version of CentOS, and probably won’t have any new certbot or certbot-auto package.

Probably not for 6, but maybe for 7. But being a Red Hat Enterprise based system, I would bet that we need some time for it to be added to CentOS.


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.