Will certbot still renew existing certificates after CentOS 6 is end of life?

Help
1

Centos has ended of life in 2020
Certbot says this when I run it manually
"Your system is not supported by certbot-auto anymore."
My question is: will the existing certificates get renew? Or I have to configrate a new server for certbot to renew them?

2

It will keep renewing certificates for as long as it can.

What has changed is that it no longer receives updates, meaning you won't receive any bugfixes or features which are introduced to Certbot in future.

If you wanna see whether renewal will work, you can try:

certbot-auto renew --dry-run
3 Likes
3

with the command I got this:
Bootstrapping dependencies for Legacy RedHat-based OSes that will use Python3... (you can skip this with --no-bootstrap)
yum is hashed (/usr/bin/yum)
To use Certbot on this operating system, packages from the SCL repository need to be installed.
Enable the SCL repository and try running Certbot again.

4

Did you already have certbot-auto installed on this server, or are you installing it now?

certbot-auto --no-bootstrap --version
5

I didn't installed it, I just downloaded certbot-auto and chmod +x and ran it 1 year ago. everything worked fine untill yesterday.
./certbot-auto --no-boostrap --version
Bootstrapping dependencies for Legacy RedHat-based OSes that will use Python3... (you can skip this with --no-bootstrap)
yum is hashed (/usr/bin/yum)
To use Certbot on this operating system, packages from the SCL repository need to be installed.
Enable the SCL repository and try running Certbot again.

6

Sorry, I made a typo. It should have been:

certbot-auto --no-bootstrap --version

So there should be an existing installation in /opt/eff.org/certbot. Try the above command and let me know.

7

setup a new server with a newer release then migrate instead of clinging to an unsupported version

8

It's an empty folder. You didn't make any typo

9

That's something I want to avoid. Too much work to do.

10

If the folder is empty, then you're out of luck. It means certbot-auto is uninstalled. It won't re-install itself due to both certbot-auto being deprecated, and CentOS 6 being end-of-life.

11

Oh, that's sad
Is it possible to download an earlier version of certbot to make it work with --no-upgrade option?

12

Possibly, using the advice at the end of

(although this was suggested for Debian-based OSes, which doesn't include CentOS)

Note that Brad specifically explains that this isn't recommended. And there are good reasons for that. Getting security updates for both Certbot and your OS itself is important!

13

Thanks you very much. It's helpful.

1 Like
14

A better solution would be to use a different client with fewer dependencies, like acme.sh. But, unless you're planning on decommissioning this system very shortly, you really should follow @HardcoreGames' advice and upgrade to a release that's receiving security patches.

1 Like
15

Thank you
I'm a little wondering, what' could be the certbot security flaw?
It doesn't listen on any public ports.

16

I don't know that there would be any in certbot itself, and as long as you aren't using it in standalone mode, it wouldn't be directly listening for anything. I was talking about the whole OS, not about certbot.

17

I know I suggested that Certbot, too, might need security updates.

A few ideas about things that might conceivably go wrong with a program like Certbot:

  • Creating some file with the wrong permissions?
  • Generating a private key insecurely?
  • Being able to be tricked into revealing the contents of some file, or into revealing DNS API credentials, or into running a non-root-created file as a hook script, due to some unforeseen bug about temporary files, environment variables, symbolic links, a race condition, or something along these lines?
  • Arbitrary code execution based on the contents of Apache or nginx configuration files? (This could be a problem in shared hosting environments where there is some script that allows untrusted users to create their own virtual hosts that Certbot then attempts to parse.)
  • Arbitrary code execution based on invalid data transmitted inside the ACME protocol? (Not that CAs are organizations that are especially likely to try to exploit such a bug...)
  • Security holes inherited from libraries that Certbot uses as dependencies?

Things that might not necessarily be considered security holes, but that still might be improved in the future:

  • Improvements to private key lifecycles. :slight_smile:
  • Updates to the Apache or nginx TLS defaults following new TLS security recommendations from Mozilla?
1 Like
18

Or cases where Certbot edits nginx or Apache configuration files in ways that (in combination with other existing configurations) produces potential security problems, like

1 Like
19

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