Acmev1 deprecated and certbot unavailable

Help
1

Hi, now that let's encrypt acme v1 is deprecated and I cannot install certbot (due to Ubuntu kernel issues I cannot resolve right now), I need to renew my certificates but need help in moving from let's encrypt to something else like acme.sh.

My domain is: api.referencefitness.com

I ran this command: letsencrypt renew

It produced this output: Acmev1 deprecated, impossible to renew

My web server is (include version): nginx 1.16.1

The operating system my web server runs on is (include version): Ubuntu 16.04.7 LTS, kernel 4.4.30-mod-std-ipv6-64

My hosting provider, if applicable, is: OVH

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): sudo letsencrypt --version = certbot 0.27.0

My questions are

  • can I renew the existing certificates on another server that has certbot installed
  • can I renew the existing certificates using acme.sh and if yes, how should I proceed
  • are there any other options, like creating new certificates that replace the existing ones (least preferred) or other renewal only clients

Thanks for your help

2 Likes
2

Probably YES; but not really worth any effort above just getting new certs.

Not LE certs; not without a great deal of trouble/work.

Copy entire LE directory and run certbot on new server.
Use another ACME client and get all new certs.
Use offline authentication and get certs without any downtime (via: DNS-01 authentication).

1 Like
3

I don't know if it might only have information you already know, but there's some information on upgrading certbot in this thread:

In general, there's not really a concept of "renewal" of a certificate from a protocol point of view. You can just request a new certificate that has the same list of domain names, and that's treated as a "renewal" for purposes of things like tracking rate limits. If you use a different client, then you probably need to update your web server's configuration accordingly to wherever the other client is saving the key & certificate.

2 Likes
4

Hi there,

Thanks for your input.

Tried renewing the certs on another server with certbot after copying /etc/letsencrypt folder but host challenge check failed.

Then, although it did take some trial and error, I managed to issue new certificates with acme.sh, updating the nginx config to use the new certs with success.

What is weird though, is there is supposed to be a "nginx mode" in acme.sh, which worked well with the staging certificate environment (--test flag) but failed as soon as I tried to issue a cert in production, claiming it could not find the domain's config file in nginx. It seems to have some problems with relative includes in nginx config files.
Luckily, using the standalone server for issuing certs worked fine, although requiring a minimal downtime since it needs the 80 port also used by nginx, but doing that in the middle of the night is fine.

Restarted nginx (reload did not serve the new cert, weirdly) and got the new, prolonged cert.

2 Likes
5

If you already use nginx, I would recommend using the webroot mode (-w flag in acme.sh) instead of standalone, as this will avoid downtime and then using a reloadcmd to reload nginx.

Nginx does re-read certificate files on reloads.

2 Likes
6

I didn't quite understand the web root method. Care to elaborate? Thanks

2 Likes
7

--webroot -w /web/root/path/for/your -d "domain.com,www.domain.com"

1 Like
8

Yeah, I figured that from the docs, but I'm still hesitant on what it does differently with this method.

Anyway, the initial problem is solved, so that's that! Thanks for your insight.

3 Likes
9

There are two parts to using --apache or --nginx

  1. authentication
  2. installation

--webroot is used only for authentication [no changes will be made to the web server configuration]
In order to make automatically changes to the web configuration, --webroot can be combined with an installation method:

  1. --apache (or -i apache)
  2. --nginx (or -i nginx)
  3. OR certonly if you don't want certbot to install anything

You can mix and match an authentication method with an installation method to best suit your needs.

1 Like
10

When retrieving a certificate from Let's Encrypt, LE performs validation that you control the domain name you're requesting a certificate for. The common method (= "challenge") to do this is called the HTTP-01 challenge. With this challenge, Let's Encrypt connects to your webserver via HTTP and attempts to retrieve a file that was placed there by your acme client.

The nginx mode in acme.sh attempts to autoconfigure everything needed - the path under which to place the file for the challenge, the certificate files, reloading nginx and so on. It figures out some of this by attempting to parse your nginx config files.

The webroot mode doesn't do anything of this: You just tell acme.sh "place the challenge file here in this directory, where my webserver will access them" and that's it - no webserver config parsing neccessary. Acme.sh will then place you the certs wherever you want and you're responsible for "installing" them (that is, telling nginx to use the [new] cert files).

3 Likes
11

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