Replace certbot-auto with acme.sh?

Hi to All,

I've two VPS Debian 8 based, Apache2 web server, that I'm going to upgrade to another Linux distro, process that will take a few months.
Every certs made by Let'sEncrypt and different domains in a single certificate.

Actually, "certbot-auto" seems that it is no longer usable:

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.

So I think (suggest me if it's the right way) to migrate to "acme.sh".

Is it correct to do this procedure? ->

  1. remove "certbot-auto" ->
    certbot delete
  2. remove old certbot "garbage" ->
    apt remove --purge certbot python-certbot
  3. Install acme.sh ->
    curl https://get.acme.sh | sh
  4. run "acme.sh" to obtain the certs ->
    acme.sh --issue --apache -d example.com -d www.example.com -d cp.example.com -d test.org -d try.net
  5. create the new cron entry ->
    0 0 * * * "/home/user/.acme.sh"/acme.sh --cron --home "/etc/letsencrypt/live/myserver.org/" > /dev/null

Could be fine?

Many thanks!!

Davide

Hi @danjde

that looks bad.

Never remove certificates if they are in use.

So:

First step 3 - 5. Install another client, create a certificate, install the certificate.

Then triple-check if the new certificates are used.

I would only remove the Certbot cron job. Ignore the other things, you can delete these months later.

5 Likes

image

I don't think those are doing the same thing.
certbot delete can be used to delete certificates issued by certbot.
remove "certbot-auto" sounds like you want to remove the certbot program itself.

But as @JuergenAuer stated, you don't want to delete anything before replacing it with another working system.
So, start at step #3.

3 Likes

Thanks Rudy!
I will follow your hint!

For the right cron syntax I'll ask to the "acme.sh" developers.

Thanks again!

Davide

2 Likes

This command wouldn't remove certbot-auto; it would rather delete certificates that have been issued using that software. Not recommended, certainly not until you had replacement certs issued and working.

If you're considering doing this, it's because you have OS packages of certbot installed--in that case, there's no reason for you to be using certbot-auto. What's the output of certbot --version?

In any event, I'm all for removing certbot and its mess of Python dependencies, and acme.sh works pretty well for me. I believe its installation process will create the cron job for you, so you wouldn't need to manually add that.

2 Likes

Right!

Actually on my system I've installed from deb packages "certbot 1.9.0" and certbot-auto 1.0.0.
I'm using certbot-auto 1.0.0, certbot result installed but unused.
In the next month, I will migrate from Debian to Centos, now I need to overcome the certbot-auto block, even if I am happy I think about leaving certbot.

Sure, this is what I will do!
But still not clear to me, the acme.sh usage.
I currently use a cumulative certificate, placed into

"/etc/letsencrypt/live/myserver.org/"

and would like to fetch all certs not using the "home" path as suggested by acme.sh documentation, but only the above path, for security reason.

I write to the acme.sh developers, but the answer wasn't entirely clear to me, can you show to me any basic example for shell and cron usage, considering my requirement above?

Many thanks!

1 Like

Locate Certbot - Auto Package. For those of you who configured SSL using the Click-to-deploy and Bitnami SSL tutorials, your certbot - auto package was downloaded to your home directory.

Seriously, why? The .deb package is a recent version--there's simply no reason for you to have certbot-auto installed.

It's easy enough to tell acme.sh where you want to put the cert/chain/key, but it's still ordinarily going to have its own "home" directory where it stores the account config file, account key, etc. I don't see any reason to change that--what "security reason" do you see as a concern?

If I wanted acme.sh to issue a cert and place its relevant files in /etc/letsencrypt/live/myserver.org, here's how I'd do it:

acme.sh --issue -d domain1.org -d domain2.org # add whatever other parameters may be needed for issuance--DNS host, webroot, etc.
acme.sh --install-cert -d domain1.org --cert-file /etc/letsencrypt/live/myserver.org/cert.pem --key-file /etc/letsencrypt/live/myserver.org/privkey.pem --fullchain-file /etc/letsencrypt/live/myserver.org/fullchain.pem --reloadCmd 'systemctl reload httpd’

The --reloadCmd flag would be altered to restart or reload whatever service(s) use this cert. And the default cron job will run daily and renew the cert when necessary.

3 Likes

Yes, it was my surprise too, but if I execute certbot --version obtain "certbot 1.9.0" and executing certbot-auto --version obtain 1.0.0. Queering from "apt" (certbot) obtain "0.10.2" Also in my opinion there is something strange, but I want to go further, in any case this is the past..

Mah, simply I would like to set all certs into a "only root readable" directory, as certbot does. it's not better?

Well, so i couldn't set a predefined directory for issuing a cert as "/etc" acme.sh?

Right! :wink:

The last (but not least) question: certbot allowed me to execute a command only in the situation where it ended successfully. Do you know if it is possible with "acme.sh"?

Thanks again!

1 Like

There are several options:

  --reloadcmd <command>     Command to execute after issue/renew to reload the server.
  --renew-hook <command>    Command to be run after each successfully renewed certificate.
  --deploy-hook <hookname>  The hook file to deploy cert
2 Likes

In that case, it's easy--install acme.sh as root, then its home directory is in root's home directory, which is only root-readable. I'd still probably want to tell it to put the cert/chain/key files somewhere outside of /root, but that's easy to do with the command I gave above.

If you have particular ownership/permission requirements for the installed cert/chain/key, after the first time you install them (i.e., once you run acme.sh --install-cert), change the ownership and permissions as desired--acme.sh won't change them going forward. When acme.sh installs a new cert (as would happen in a renewal), it cats the new cert over the old one, which means ownership and permissions don't change.

3 Likes

Simply perfect, I just have to try :wink:

Right!

Yes, you made this point very clear :wink:

WAW! Wonderful!

At this point I seem to have gathered enough information, now is the time to try, I will not fail to update you and publish the procedure that I am going to adopt!

Really thanks to all of you!

2 Likes

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