Centos change from acme.sh to certbot; tips?

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:lazygranch.com

I ran this command:

It produced this output:

My web server is (include version):nginx version: nginx/1.20.1

The operating system my web server runs on is (include version):centos 7

My hosting provider, if applicable, is:digital ocean

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): acme.sh

I can't get zerossl to work and I know that is the not a problem of letsencrypt. I want to switch to the "snap" version of certbot. My question here is what is the proper way to rid myself of acme.sh and do the change to certbot without clobbering useful files on the server, if any.

It looks like you have a long successful history with Let's Encrypt certificates. What problems did you have that made you want to switch to acme.sh and now the snap certbot? I ask because maybe the original problem has an easy solution. That is, I wonder if it is at all related to the expiry of the Let's Encrypt DST Root CA X3 root certificate on Sept 30. Thanks

2 Likes

I probably didn't state my problem well. The acme.sh worked great until the author sold it. The bash scriot now has 666 open issues on github. It looks hopeless. I can't make the acme.sh fallback hook to letencrypt work. As I stated that is not your problem. What I do need know is the best way to switch to certbot.

Centos 7 initially had some issue with certbot but there is now a "snap" package to install. I want to rid myself of acme.sh and switch to certbot.

My question is how do I go about making the change? There are procedures for an initial installation, but in this case I already have been issued Letsencrypt certs so I am sort of starting with certbot in the middle of the workflow if that makes sense.

I assume acme.sh has a cron entry that I need to remove. Anything else?

1 Like

Thanks for that. I thought you just added --server letsencrypt to your acme.sh command but I believe you when you say you had issues and ongoing concerns.

So, mostly just ignore that you ever had acme.sh installed and start using Certbot. It will start issuing Lets Encrypt certs and there you go. You have a working server using certs so you would just update your server conf certificate file names to use the new certs created by Certbot. So, do not delete acme.sh certs until that is working!

I recommend using something like:

sudo certbot certonly --webroot -w (path to server root) -d (domain1) -d (domain2) ... --deploy-hook "(reload cmd for nginx)"

The certonly and webroot work well for existing servers such as yours. It will not update your server conf.

Add --dry-run to that command to test the setup and remove that when successful to get your real certs. These will be in /etc/letsencrypt/live/(domain1)/. You are likely using fullchain and privkey so still use them just from here.

Yes, if you have any cron for acme.sh remove that when you have Certbot running. It won't hurt if it happens to create one extra cert while you get Certbot running.

Hope this helps

UPDATE: @gariac I did not address snap install as you sounded familiar with it but just in case review here

2 Likes

OK. Thanks. I will report back hopefully with success.

Snap, flatpack, etc. These things seem to work in general Ultimately I need to dump centos for other reasons* and will go to some Debian with long term support. Then use programs from a regular package manager.

  • Other reason being IBM sort of making centos no longer free after the Redhat purchase. Not your problem but in the event anyone is curious.
2 Likes

IIUC, EFF moved to Snap to avoid having to worry about what version of certbot was in which package manager for each distro :slight_smile:

2 Likes

In general, acme.sh and certbot can co-exist.
They don't normally put any files in any common areas.
That said, web servers won't automatically switch to using new certs from other ACME clients, so you will have to update your vhost config files accordingly.
I would simply uninstall whichever is left unused (at the end of your test).

2 Likes

I followed the centos 7 installations. No issues there.

I had to turn off the firewall to make
sudo certbot --nginx
work.
Otherwise perfect. The firewall was never an issue with acme.sh FWIW.

The error message was pretty clear:
"Timeout during connect (likely firewall problem)"

Sorry, but you can use --set-default-ca to switch back to use letsencrypt, if you want one more try.

acme.sh  --set-default-ca  --server  letsencrypt
1 Like

The thread is open for a month. I have some work to do on the websites but will try the acme once again before the thread closes. I didn't mention that the acme code kept timing out. I really think it is hosed.

Use whatever works best for you, of course, but I use acme.sh on probably a couple dozen systems without problems. Timeouts would not result from acme.sh itself. Now, if you're concerned about the sale to ZeroSSL, fair enough, I'm not a fan either--but it has worked, and continues to work, well for me. And just browsing the first page of the issues list, it looks like most of them are a matter of user error/instruction or feature requests.

2 Likes

If you needed to turn it off for Certbot you would have had to turn it off for acme.sh. The Lets Encrypt server needs to reach your system for an http authentication. That part of the process is the same for both.

I see you issued some new certs although I cannot reach your system with http or https. Do you still need help?

You could combine your domain names in one cert, and probably should, but this is not necessary depending how your servers are defined. You used to combine them so I mention this in case you did not intend that.

2 Likes

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