I'm running an old Ubuntu 14.04 server. It has been running without issues for years now but, with the recent deprecation of ACMEv1 i can't renew the certificates again. I have googled about how to deal with this problem but i'm not sure what to do.
In my server didn't make an "official installation" of letsencrypt. Rather, I just cloned it to some custom folder.
My question is, can I just make a git update or clone letsencrypt again to a more recent version and expect everything to work just fine? Upgrading my server is NOT AN OPTION as of right now. About cloning, I suspect I could have problems with my old versions of python/pip as well, which is 2.7.6, and pip 1.5.4. Just trying to see what happens is not an option either. There are things that are not easy to recover from, so I prefer to have some kind of expert guidance before going all-in. The root of the problem is the deprecation of ACMEv1 though, so I wonder what is the least invasive way of solving that particular problem. git update or re-clone looks straightforward.
The commit I cloned was the next one:
$ git log --name-status HEAD^..HEAD
commit 4c28fc417c978090ae8def91b81ed59f439e797a (HEAD -> master, origin/master, origin/HEAD)
Merge: b57371a3 0454031c
Author: bmw <[email protected]>
Date: Tue Jan 5 18:02:19 2016 -0500
Merge pull request #2073 from alex/more-typos
Fixed a pair of typos in docstrings
commit 0454031cce4b88fef44e3e129e879a35b49c2314
Author: Alex Gaynor <[email protected]>
Date: Sun Jan 3 14:37:08 2016 -0500
Fixed a pair of typos in docstrings
M acme/acme/jose/json_util.py
M acme/acme/jose/util.py
so, yes, it's old.
Besides, I have some local changes, all created automatically by letsencrypt if I'm not wrong; I don't remember modifying any of those files:
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
typechange: acme/examples/standalone/localhost/cert.pem
typechange: acme/examples/standalone/localhost/key.pem
typechange: bootstrap/archlinux.sh
typechange: bootstrap/centos.sh
typechange: bootstrap/debian.sh
typechange: bootstrap/fedora.sh
typechange: bootstrap/gentoo.sh
typechange: bootstrap/manjaro.sh
typechange: bootstrap/suse.sh
typechange: bootstrap/ubuntu.sh
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/default_vhost/apache2/conf-enabled/other-vhosts-access-log.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/default_vhost/apache2/conf-enabled/security.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/default_vhost/apache2/conf-enabled/serve-cgi-bin.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/default_vhost/apache2/sites-enabled/000-default.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/two_vhost_80/apache2/conf-enabled/other-vhosts-access-log.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/two_vhost_80/apache2/conf-enabled/security.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/two_vhost_80/apache2/conf-enabled/serve-cgi-bin.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/two_vhost_80/apache2/sites-enabled/000-default.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/two_vhost_80/apache2/sites-enabled/encryption-example.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/two_vhost_80/apache2/sites-enabled/letsencrypt.conf
typechange: letsencrypt-apache/letsencrypt_apache/tests/testdata/debian_apache_2_4/two_vhost_80/apache2/sites-enabled/mod_macro-example.conf
typechange: letsencrypt-nginx/letsencrypt_nginx/tests/testdata/etc_nginx/ubuntu_nginx_1_4_6/default_vhost/nginx/sites-enabled/default
typechange: letshelp-letsencrypt/letshelp_letsencrypt/testdata/mods-enabled/ssl.load
Untracked files:
(use "git add <file>..." to include in what will be committed)
letsencrypt.zip
no changes added to commit (use "git add" and/or "git commit -a")
Lastly, I renew the certificates with a script with the following format:
#!/bin/bash
sudo /.../my-letsencrypt-clone/letsencrypt-auto certonly -v -t --webroot \
-w /var/www/web1/ -d www.domain1.com -d domain1.com -d subdomain.domain1.com \
-w /var/www/web2/ -d web2 \
-w /var/www/web3/ -d www.web3.com -d web3.com
last_cert=$(sudo find /etc/letsencrypt/live/ -type d -iname "www.domain1.com-*" | sort | tail -n 1)
sudo ln -sfn "$last_cert" /etc/ssl/private/domain1.com
sudo service apache2 restart
sudo service postfix restart
sudo doveadm reload
As you can deduce from the script, the certificate is shared by my apache2, postfix and doveadm services and no one else.
In my /etc/letsencrypt/live folder I have the following contents:
total 28
drwxr-xr-x 2 root root 4096 Mar 10 2017 www.domain1.com
drwxr-xr-x 2 root root 4096 Jun 12 2017 www.domain1.com-0001
drwxr-xr-x 2 root root 4096 Jun 12 2017 www.domain1.com-0002
drwxr-xr-x 2 root root 4096 Apr 30 2018 www.domain1.com-0003
drwxr-xr-x 2 root root 4096 Oct 11 2018 www.domain1.com-0004
drwxr-xr-x 2 root root 4096 Jun 13 2019 www.domain1.com-0005
drwxr-xr-x 2 root root 4096 Mar 8 20:19 www.domain1.com-0006
So the script picks (last_cert variable) the folder with highest number, which is the one where letsencrypt is renewing certificates, and make /etc/ssl/private/domain1.com point to it, because that's the folder that my services are using to load the multidomain certificate.
