Orphaned OS: CentOS 6.x

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: jick.net

I ran this command: certbot-auto --version

It produced this output: "Your system is not supported by certbot-auto anymore."

My web server is (include version):Apache/2.2.15

The operating system my web server runs on is (include version):Scientific Linux 6.x (equivalent to CentOS 6.x)

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.10.1 (Error message: "Your system is not supported by certbot-auto anymore.")

I am forced to run the orphaned SL 6.x system because newer versions no longer support PHP5, and PHP7 is not only downward-INcompatible but seemingly designed to be impossible to convert from PHP5 without simply recoding a life's work from scratch. But now I can't renew my certs because there is no "snap" for CentOS 6.x clones. In my life's work simply lost?

I can answer your question in these ways:

  1. End-of-life means just that. One can't have any expectation that a dead OS will be able to keep interacting with internet services or receive modern releases of packages. CentOS 6's end-of-life date has been known since 2011, plenty of time to plan a migration strategy.
  2. If it's really a matter of urgency, you can run PHP 5.5 on a supported OS like CentOS 7 using some well-known third party repositories such as Remi's RPM repository.
  3. There are other choices of ACME client besides Certbot if you need something which will work in an EOL operating system. acme.sh or lego might work for you, even if they don't work in the exact same way as Certbot.
  4. Keeping an EOL operating system connected to the internet is a /very/ bad idea. You could consider placing a second modern server in front of the EOL server, to serve as an HTTPS reverse proxy.

If you have an existing certbot-auto installation (i.e. there are files in /opt/eff.org/certbot), it should be able to keep renewing certificates.

Try:

certbot-auto renew --dry-run

It may complain about not being supported anymore, but it will still do the job (until it can't).

4 Likes

Okay, #certbot-auto renew --dry-run complained but claimed success, so I ran #certbot-auto renew and that created a new fullchain3.pem file. Now all I have to do is remember what to do with it, if anything.

I am resigned to buying a new server and porting everything to it, but this will take some time. I will definitely look into Remi's RPMs for PHP 5.5, but I'm going to dump SL and run openSUSE instead. Hopefully Remi's RPMs will also work there.

Thank you very much for your help! -- Jess

Run /opt/eff.org/certbot/venv/bin/letsencrypt instead of certbot-auto. It will work but not try to update the client.

Perfect! Thank you. BTW, I presume that once I run it and select the domains, there is no further follow-up needed until the next time my cert expires?

Run the same way you ran certbot-auto ... it's essentially the same code without the auto update functionality.

I run it daily and haven't had a problem once.

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