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 pr
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
what kind of server you have?
"Certbot went to hell"
I would not go chasing after it! - LOL
Can you uninstall it and reinstall it?
I need to install CERTBOT auto on debian 8, but you guys removed it, and I have a server that cant do snapd, and I am NOT upgrading to debian 9-11 SIMPLY because of snapd - This makes my secured website TRASH, because all I get for the most current version of certbot is:
install snapd, install snapd/snaps: I WANT the 1.9.0 version that I can download, NOT RAW OUTPUT: If I am running Debian 8, there is a REASON, and I want to do certbot, because you need to be a scriptng genious, and the HELP page 404's - what good is it. Help page is BLANK!
Now to ELIMINATE your questions that were just pasted: I did it below
I CANT run certbot, because I cant install it UNLESS someone gives me the certbot 1.9.0, so I can renew my certs: I dont know HOW to use anything BUT the certbot auto, and i dont fancy having to DESTROY the setup I have because of some resouce HOG like SNAPD
Webserver: Apache 2.4 (debian 8)
Host: Godaddy, but I am just getting domains and email through them, and i own and run the server the sites are on.
I have root aaccess
No Control Panel
Version I want of certbot: 1.9.0 for debian
Please send me the certbot 1.9.0 so I can install it: You guys really need to FIX certbot: it was so easy for me to use the auto, but now, it seems like there are 500 clients that you can get, and you need to be a scripter to run it. GIVE us a CHOICE and let us run the older stuff
Debian 8 - Everybody just threw the old program away, and I need it, cant get 1.9.0 anywhere, and the website wants you to run deb9 deb 10 or 11, and my websites CANT run on deb9-11 because of mysql and PHP problems which I can fix if I run 8 for now, but SNAPS are trash, and take up resources, and I am NOT gonna run snaps: I cant even FIND the old version of the program, i get a list of files, and NOT the file I want.
Certbot seems to have forgotten to leave the program there, or allow us to get it, all I can find is RAW script, and I have NO idea why this thing cant be an installable program, like it was before. I uninstalled it because I was getting "certbot doesnt work anymore....."
rg305: No: Instructions are GONE for debian 8, and there is NO WAY to install it without throwing my OS in the trash...........BAD Move.......I need the older version, NOT a push to upgrade
you don't have to stay with certbot, it's just one of the client and technically isn't from Let's encrypt.
a single file pure bash script, full acme client.
keep mind you will need to edit config file to point production endpoint https://acme-v02.api.letsencrypt.org get real cerrtificate, in first state it will point to staging test environment.
P.S you will need to update CA store to even connect to api that use let's encrypt: (DST root expiration) and older openssl behavior
all i get is a LIST of files: what do i download??
Github is confusing.....
scroll down and read the readme.md
There is also the
acme.sh ACME client.
You are not alone. You really are not alone. Perhaps my solution will work for you. Find a spare computer. A laptop will do. Install a newer version of your OS, which will come with a newer version of certbot. rsync /etc/letsencrypt from your server over to the "laptop". You can now run certbot on the "laptop" with --manual (which is what I do). Follow the instructions and create the verification file on your server. Alternatively you can export and nfs mount your webroot to the "laptop" (maintain location and assure root write permissions). You may then also have to rsync your webserver setup directory to the "laptop" for certbot to find the webroot directory. Then you can run certbot from the "laptop" with the --webroot option. The certbot on the "laptop" will write the verification file to your server webroot and will receive the new certificate. rsync /etc/letsencrypt from the "laptop" back to your server. Update certificate links on your server, if that is your normal routine.
If PHP works on your server, you could just use CertSage...
I would like to clarify some things:
Debian 8 was released in 2015, with a 5 year support window that expired in June 2020.
nobody removed support for certbot on Debian 8; the Debian team stopped supporting that platform over a year ago. The Debian volunteers are responsible for porting certbot to Debian and making it available to Debian users, not the certbot or LetsEncrypt volunteers.
you are missing critical security updates by not updating your os to one in an active support window.
there are numerous ways to install a ssl certificate on an outdated, unsupported, operating system. They include, but are not limited to: manually install a client from source, use another client, and obtain certificates on another machine and transfer them.
any proper solution for this problem, however, will always include updating the server to an actively supported operating system, or moving to a server with an actively supported operating system.
I can understand everyone WANTING me to throw Debian 8 in the trash and upgrade to DEB 11 - I NEED 8 because there are plugins on my websites that REQUIRE php, and I can't use php7.3/7.4/8.0 because then my website is TRASH while I figure out how to get plugins that are compliant with 7.3/4/8.
Without making sure my website wont CRASH hard because of not knowing what is compatible with PHP 7.3/7.4 or 8.0 plugin wise, I WILL NOT update everything because:
Deb11 uses Mariadb and I use mysql
Deb11 is NEW and there are things that may NOT and DO NOT work well with my websites. I will check for plugin compatibility, and make sure that my databases wont DIE because of the new versions of SQL and PHP. I upgraded Once before, and it was a blasted NIGHTMARE, so I downgraded to make sure my sites are working and STABLE - I like Deb 11, but I want my system to work without having a problem.
DEB11 has the new Certbot, BUT: Someone decided that we needed a whole bunch of snaps on our systems, and I already use GDebi and Synaptic to install things, and I dont need snapd if that is the ONLY reason to have snapd (snaps) is because of certbot - I had to install python too, and something messed up once.
My system may be EOL as far as the version, but I have learned that you don't MESS with what WORKS! Some people like me don't think that snaps should be needed to run a script that will go out and pull the information IN, and renew domains.
When I have done all of the needed work to insure that my plugins won't crash the websites i have (meaning that php7/8 will be supported) BY the plugins I use, THEN and ONLY THEN will I upgrade to Deb11 full time, and not before. I cant RISK losing what works while I am setup and the sites are running OK, because the older system is EOL - There are others of us who run older systems, and we may need to for a while until we can get that straightened out, and THEN I will run debian 11
Are you able to run virtual systems?
Unless your server get hacked due to unfixed remote exploits..
Also, almost everything you say makes sense. Nobody wants a dysfunctional site due to incompatibilities. That said, usually one would make sure all the required steps are already done before a OS version becomes EOL. That's just proper system administration if you'd ask me. Also, usually one would have a production system and a testing system, so one can find out if stuff works or not without messing up the production system.
In any case, you can't expect software engineers to keep on supporting EOL systems. So while it may be your choice not to upgrade yet (for somewhat understandable reasons), it may have other
consequences such as unsupported software.
OK: I have acme.sh, and i have stuff in /etc/letsencrypt. So I have a config file for my domain, and I wanted to know where you get this piece:
Location for all your certs, these can either be on the server (full path nam$
or using ssh /sftp as for the ACL
#DOMAIN_CERT_LOCATION="/etc/ssl/buddy-baker.us.crt" # this is domain cert
#DOMAIN_KEY_LOCATION="/etc/ssl/buddy-baker.us.key" # this is domain key
#CA_CERT_LOCATION="/etc/ssl/chain.crt" # this is CA cert
#DOMAIN_CHAIN_LOCATION="" # this is the domain cert and CA cert
#DOMAIN_PEM_LOCATION="" # this is the domain key, domain cert and CA cert
Do I pull that from the /etc/apache2 directory for example, or do I get that from the lines that say in my buddy-baker.us-le-ssl.conf:
I have 4 domains DOT US, DOT COM, DOT ORG and DOT INFO: I am wondering what to put in there for keys/certs?
Can someone let me know what I have to do?
There are plenty of "right answers".
[there is no set requirement - short of being placed into a secure location (and it doesn't wreak any havoc]
That said, it seems like you want a seamless transition from
acme.sh [without any
If so, I would proceed with caution [backup things before making any changes].
It seems possible to obtain certs via both ACME clients.
- relink the entries in
[if all works, then uninstall
acme.sh is set to renew all your sets via scheduled task
- have a (or four)!