Upgrading certbot on Ubuntu


#1

I am sorry, but more help than that is needed.

Today, I too received this cryptic email. Unfortunately I don’t have much time trying to understand what Certbot is doing on our server, and IF we need to do anything at all. Certbot was installed by a person that is no longer working with us.

To my understanding Certbot is supposed to make our life simpler by automating some SSL-related technical tasks, but for the moment it is doing the opposite.

Is there a straight-forward instruction for how to upgrade from certbot 0.26 to 0.28? The instructions for Ubuntu 14 and Apache (https://certbot.eff.org/lets-encrypt/ubuntuxenial-apache) are not easy to follow (it looks like full install instructions, not upgrade instructions). It starts describing “DNS plugins”. How do I know if that is even relevant for our system? It seems they are optional, but how do I check if we are using that? It says “If you want to obtain a wildcard certificate” - again, how do I check if we have that or not? “You’ll need to replace dns-plugin with the name of the DNS plugin you want to use” - how am I supposed to figure THAT out? - and there the instructions end.

Any help with checking our installation and moving up to version 0.28 with minimum effort will be very much appreciated!

(I also have very hazy notions of what is “ACME” and “TLS-SNI-01”)


Action required: Let's Encrypt certificate renewals
#2

I guess this is what should be done, but no luck - the version is still 0.26.

sudo apt-get install python-certbot-apache
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages will be upgraded:
python-certbot-apache

Get:1 http://ppa.launchpad.net/certbot/certbot/ubuntu xenial/main amd64 python-certbot-apache all 0.28.0-1+ubuntu16.04.1+certbot+3 [3,872 B]
Fetched 3,872 B in 0s (32.6 kB/s)
(Reading database … 292367 files and directories currently installed.)
Preparing to unpack …/python-certbot-apache_0.28.0-1+ubuntu16.04.1+certbot+3_all.deb …
Unpacking python-certbot-apache (0.28.0-1+ubuntu16.04.1+certbot+3) over (0.25.0-2+ubuntu16.04.1+certbot+1) …
Setting up python-certbot-apache (0.28.0-1+ubuntu16.04.1+certbot+3) …
~$ sudo certbot --version
certbot 0.26.1

… and here is where the installation ended up:
~$ /opt/eff.org/certbot/venv/bin/certbot --version
certbot 0.30.2

Something appears not right with the update script?


#3

Could you try apt instead:
sudo apt install python-certbot-apache


#4

I found another way, somehow forcing certbot to actually update.

Why should I try “apt” when the instructions from Letsencrypt clearly say “apt-get”?
Sorry, our server is not for experimenting.


#5

apt is NOT an experimental.
apt and apt-get are considered to be equal; but there is another thread in this forum that may indicate that under “certain circumstances” apt may work while apt-get may fail to update and hold packages back. [still under investigation]


#6

If you first upgrade to a recent LTS Ubuntu (18.04 for choice) certbot can upgrade to 28.0.1 from the repositories (IIRC Universe or Multiverse)


#7

From our perspective doing “something else” (apt) would indeed be “experimental” - in the sense that we would be on our own by not following the official instructions. As you write, there is apparently lacking information about what is the difference between “apt-get” and “apt”.

Not everyone is a 100% Ubuntu expert.


#8

Hi, since you’re apparently using Ubuntu I’ve split your posts and replies into a new topic, since the discussion in the other thread about CentOS is unlikely to be relevant to your situation.


#9

I’m unclear as to whether you’re actually still looking for a solution but in case you are:

Certbot is split across a number of different packages that all need to be upgraded; python-certbot-apache is just one of them. If you’re willing to run a full apt-get update; apt-get full-upgrade on your server, that should upgrade them all. If not, the following command should upgrade everything you’ve installed from the PPA:

apt-get install --only-upgrade $(grep -Pho '(?<=Package: ).*' /var/lib/apt/lists/ppa.launchpad.net_certbot_certbot_*_Packages)

#10

I admire your sense of “doing things right” and “by the book”.
But unfortunately, Cerbot and Linux (in general) are still very much a moving target.
And their details/books are still being written (and rewritten) as we speak.

There is really no need to be a 100% Ubuntu expert to add/remove/update certbot.
It is not a “life and death” program.

For the extremely paranoid, I would recommend using “snapshots”/“checkpoints” (any method to completely rollback recent changes) to overcome any bad steps taken.
Like: In the unlikely event that some other critical (but unrelated) program happens to react badly to changes made to/with certbot program and required packages.

But for those who are actually connected to a “Nuclear Facility” rated environment, you might want to handle the certbot requests with a dedicated cert only (distribution) system. [So as NOT to introduce any possible risk, nor unwanted change, to resources shared by any other system]

That said, this statement couldn’t be further from the truth:

We help people here everyday that do exactly that.
And even those with problems caused by doing a whole lot worse…
Like the extremists:
“Please help! I messed everything up when I tried to fix it by deleting/moving/revoking/reinstalling…”
[even such “tragedies” can find relief here]

So please don’t feel like we would ever leave you out in the cold should any such event occur.
We are here to help - one and all :slight_smile:


#11

I am sorry if I had the wrong impression of what level of professionalism to expect. We are probably paying nothing for certbot/support, so I guess we are getting much better than what we pay for. Will probably look for a commercial solution instead.


#12

How so?
Does showing honesty and openness equate to lacking professionalism?

You can’t pay others enough to match that.

I couldn’t agree with you more.
You are probably paying nothing.
Expecting to be treated like you have always been treated before.
And are unhappy that the reality doesn’t meet your imagination.
We don’t maintain Linux and it updates packages all the time - change is the constant.
If you use Linux you should be familiar with this.
There are dozens of environments that are covered and many ways to complete the desired task (automate encryption).

If you think that cost equates commercial “quality”, then you would be sadly mistaken and overcharged.
Price alone is NOT the determining factor.
The “quality” of the DV certificates provided are equal (from all practical views).
And as shown time and time again throughout this forum, many have paid for services that are far less “useful” than those provided here.

But I will concede that there are indeed some differences.
Namely:

  • You can get certs for longer periods of time from paid providers
  • You will have to create your own automation system (if even possible)
    [or process the entire request manually]

So, if you will be processing the requests manually, why pay? For that privilege?
You could do the very same thing here, yourself; And save the money charged for… “nothing extra”.
But, of course, you are free to chose - and hopefully you find one that lets you sleep well at night.
I know I sure do :slight_smile:

So, if you only “advantage” is to only have to deal with certs on a yearly (or bi-yearly) basis, then you haven’t fully grasped the concept of fully automating the entire cert process.
Perhaps in time…
The products offered will become more “commercially” sound in your view.
But the service offered is already of “commercial” grade.
How it is used is entirely up to the consumer (Linux, Windows, Mac, Web, Mail, Chat, etc., etc., etc.).

Or… maybe I completely misunderstood you and, if so, I am way off target and I missed the point altogether.


#13

First lesson in professionalism - do not try to engage users/customers in long debates, and especially not making unfounded assumptions about them. Try to lecture someone else. I am done here.


#14

Sounds like a missed opportunity…
Not sure for whom thou.
I tried to pass my knowledge.
Perhaps you could have schooled me - never too old to learn!

FYI - I don’t get paid to type.
[I don’t work for LE]
I did that from the kindness of my heart.

If you read with sad eyes you will only see sadness.


#15

Thanks for this concrete help, will keep it in case it is needed.

I had managed to upgrade using some force-option found in another forum (sorry to not have kept it). Strangely noone saw it in their heart to inform me about how to check if any action at all was needed. (since the instructions were missing that key information).

Sorry to not have lots of time to debate here. Let me at least contribute the solution (found it after ignoring the argumentation offered in this forum and instead searching more myself):

The renewal configuration files are in this folder:
/etc/letsencrypt/renewal
In my particular case I find this parameter there:
pref_challs = dns-01
This was all I would have needed (no action required).

Will revisit this issue when we rebuild our failover solution.


#16

Glad to hear you got it figured out in the end :slight_smile:


#17

image

…reasoning systematically…
I don’t think I’ve had such a “complement” in quite some time :slight_smile:

You obviously do understand open-source and community driven forums.
If you don’t like what one person has to say then just listen to another.
I don’t represent the entire community, nor do I represent LE.
I only represent myself and I’m 100% OK with all that has transpired.
I would most likely do it again in very much the same way.
No regerts - LOL

Happy to hear you found a solution too!


closed #18

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