Rulez un server vechi Ubuntu 14.04. Funcționează fără probleme de ani de zile, dar, odată cu deprecierea recentă a ACMEv1, nu pot reînnoi certificatele din nou. Am căutat pe google despre cum să rezolv această problemă, dar nu sunt sigur ce să fac.
Pe serverul meu nu am făcut o „instalare oficială” a letsencrypt. Mai degrabă, l-am clonat într-un folder personalizat.
Întrebarea mea este, pot face doar o actualizare git sau clonează letsencrypt din nou la o versiune mai recentă și te aștepți să funcționeze bine? Actualizarea serverului meu NU este O OPȚIUNE deocamdată. Despre clonare, bănuiesc că aș putea avea probleme și cu vechile mele versiuni de python/pip, care este 2.7.6 și pip 1.5.4. Nici să încerci să vezi ce se întâmplă nu este o opțiune. Există lucruri din care nu este ușor de recuperat, așa că prefer să am un fel de îndrumare de specialitate înainte de a merge all-in. Rădăcina problemei este deprecierea ACMEv1, așa că mă întreb care este cel mai puțin invaziv mod de a rezolva această problemă. actualizare git sau re-clonare pare simplu.
Commit-ul pe care l-am clonat a fost următorul:
$ git log --name-status HEAD^..HEAD
comite 4c28fc417c978090ae8def91b81ed59f439e797a (HEAD -> master, origine/master, origine/HEAD)
Îmbinare: b57371a3 0454031c
Autor: bmw <[email protected]>
Data: marți 5 ian 18:02:19 2016 -0500
Fuzionați cererea de extragere #2073 de la alex/mai multe greșeli de scriere
S-au remediat o pereche de greșeli de scriere în documente
comite 0454031cce4b88fef44e3e129e879a35b49c2314
Autor: Alex Gaynor <[email protected]>
Data: Duminica 3 ian 14:37:08 2016 -0500
S-au remediat o pereche de greșeli de scriere în documente
M acme/acme/jose/json_util.py
M acme/acme/jose/util.py
deci, da, e vechi.
În plus, am câteva modificări locale, toate create automat de letsencrypt dacă nu greșesc; Nu-mi amintesc să fi modificat niciunul dintre acele fișiere:
stare $ git
Pe stăpânul de ramură
Sucursala dvs. este actualizată cu „origine/master”.
Modificări care nu au fost efectuate pentru comitere:
(utilizați „git add <file>...” pentru a actualiza ceea ce va fi comis)
(utilizați „git restore <fișier>...” pentru a renunța la modificările din directorul de lucru)
schimbare de tip: acme/examples/standalone/localhost/cert.pem
schimbare de tip: acme/examples/standalone/localhost/key.pem
schimbare de tip: bootstrap/archlinux.sh
schimbare de tip: bootstrap/centos.sh
schimbare de tip: bootstrap/debian.sh
schimbare de tip: bootstrap/fedora.sh
schimbare de tip: bootstrap/gentoo.sh
schimbare de tip: bootstrap/manjaro.sh
schimbare de tip: bootstrap/suse.sh
schimbare de tip: 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
schimbare de tip: letshelp-letsencrypt/letshelp_letsencrypt/testdata/mods-enabled/ssl.load
Fișiere neurmărite:
(utilizați „git add <fișier>...” pentru a include în ceea ce va fi comis)
letsencrypt.zip
nicio modificare adăugată la commit (utilizați „git add” și/sau „git commit -a”)
În sfârșit, reînnoiesc certificatele cu un script cu următorul format:
#!/bin/bash
sudo /.../my-letsencrypt-clone/letsencrypt-auto certonly -v -t --webroot \
-w /var/www/web1/ -d www.domeniu1.com -d domeniu1.com -d subdomeniu.domeniu1.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 reporniți
sudo service postfix restart
sudo doveadm reload
După cum puteți deduce din script, certificatul este partajat de serviciile mele apache2, postfix și doveadm și nimeni altcineva.
In al meu /etc/letsencrypt/live folder am următorul conținut:
total 28
drwxr-xr-x 2 root root 4096 10 martie 2017 www.domain1.com
drwxr-xr-x 2 root root 4096 12 iunie 2017 www.domain1.com-0001
drwxr-xr-x 2 root root 4096 12 iunie 2017 www.domain1.com-0002
drwxr-xr-x 2 root root 4096 30 aprilie 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 13 iunie 2019 www.domain1.com-0005
drwxr-xr-x 2 root root 4096 Mar 8 20:19 www.domain1.com-0006
Deci scenariul alege (ultimul_cert variabilă) folderul cu cel mai mare număr, care este cel în care letsencrypt reînnoiește certificatele și make /etc/ssl/private/domain1.com indicați-l, deoarece acesta este folderul pe care serviciile mele îl folosesc pentru a încărca certificatul multidomeniu.
