I don't know if it is the right topics, bu my question is:
I am certifying Domains at a CENTOS Server without problems. But now I receive a message that says:
Your system is not supported by certbot-auto anymore.
Certbot will no longer receive updates.
Please visit https://certbot.eff.org/ to check for other alternatives.
I visited this LINK address but I didn't see what my real alternatives are. Currently I don't have how to move from CENTOS, so, please, help me: what can I do?
Which version of CentOS are you using? Because they provide RPMs of certbot in CentOS 7. CentOS 6 has been EOL for a while now, so you really should be upgrading anyway.
Please upgrade your CentOS versions. CentOS 6 is end of life and doesn't get any support/upgrades any longer.
After upgrading your CentOS, please see the instructions in the warning message you received to move from certbot installed through the deprecated certbot-auto wrapper script to certbot installed through snap.
Do you think that the upgrade from CENTOS 6.9 or 6.0 to CENTOS 7 could be easily accomplished? Does it necessarily envolve also the upgrade of things like POSTFIX, MYSQL, PHP and so on?
Why not? What makes them worse than apt install certbot? If the OS (or third-party repo) package maintainers are keeping the packages up-to-date (the current CentOS package is for 1.10), that seems much more desirable than a closed-source, third-party system like snap. Edit: Particularly when CentOS doesn't ship with snap--it's a Ubuntu thing.
OK, fine, the certbot maintainers want to use snap. IMO, that's another good reason not to use certbot.
No, it can't. You'll most likely need to back up your system, do a clean install, and restore. AFAIK, you can't do an in-place upgrade from CentOS 6 to 7. And you should have been planning for this for a while now--the CentOS EOL calendar is published a long time in advance (well, until they pulled the rug out from under CentOS 8).
Partly correct, the name "letsencrypt" for the ACME client now called "certbot" is ancient (like, 2016). The current versions, which includes versions installed into the virtual environment by the certbot-auto wrapper script, are called "certbot".
Also, it's very much possible to keep using the certbot-auto script with the option --no-self-upgrade. I'm not familiair with the script that much, so it might be necessary to download a previous version of the script from Github from before the deprecation.
In any case, all of the above is not recommended, as this will prevent you to update certbot. This can have security implications and it might even break your HTTPS if Let's Encrypt decides to change something major, just like with the ACMEv1 to ACMEv2 change.
And I'm not even talking about the security implications of running an End-of-Life distribution not getting any security updates...........
On my system, which was installed using certbot-auto (using the --debug option), I have both certbot and letsencrypt. They are identical.
My experience was that certbot-auto stopped working with an error about it no longer being supported, regardless if the no self upgrade option was specified. This is why I had to hunt around to find the letsencrypt command in /opt/eff.org/certbot/venv/bin
Some systems have no other options ... I have a few Amazon Linux 1 systems that I have yet to migrate to Linux 2 ... and I can't use the currently recommended way to install certbot.
On my Amazon Linux 2 instances, I am able to install certbot from the EPEL repo.
There are dozens of other clients. You can do it EFF's way, and install use a proprietary, closed-source software marketplace for the sake of installing their client, or instead use something like acme.sh. Unless you're using acme-dns (for which acme.sh's integration isn't very good), I don't see any real reason to use certbot at all.
OK, you need to install a client for a proprietary, closed-source software marketplace. Still seems a strange way for EFF to go, and not one I intend to follow. And there's no good reason to follow it with CentOS (at least CentOS 7), when they maintain up-to-date packages themselves. If your distro doesn't, there are lots of other clients if you don't feel like using snap.
I'm using certbot ... it's setup and working well. If you're running an old version of Linux, you can't use the EFF recommended alternatives. Amazon Linux 1 doesn't support snapd and certbot isn't in the EPEL repo.
I'll upgrade to Amazon Linux 2 at some point in the coming months, so calling the letsencrypt or certbot command from /opt/eff.org/certbot/venv/bin will work fine.
No, it's something I have to do. Upgrading RHEL based Linux instances isn't the most straight forward thing. Some of my instances are simple and the upgrade went smoothly. Others are more complex and take much more planning.
…containing open source software I can understand the apprehension of making use of a partly closed source system. That said, Github isn't open source too, right? But is hosting TONS of open source code and probably only a few puritans have a problem with that.
I can understand from the certbot team perspective to better advise the same thing for most of the distro's if possible. For example, Gentoo doesn't use systemd by default and thus cannot run snapd. Therefore, the recommende method of installing certbot on Gentoo is using the Gentoo package manager. But if snap is an option, I can understand the team doesn't want to run into possiblel trouble in the future for example. Better to harmonize everything as much as possible.
Personally, I wouldn't use snap too.. Not a fan Luckily, I use Gentoo
Well, guess it's a matter of advantages versus disadvantages of not upgrading
I can understand the apprehension of making use of a partly closed source system. That said, Github isn't open source too, right? 
But is hosting TONS of open source code and probably only a few puritans have a problem with that.