Suche

Markus Badberg (Protonet Support) 28.02.2019 - 18:57

LetsEncrypt aktualisieren

Ihr habt bestimmt eine Mail bekommen, dass der LetsEncrypt Client aktualisiert werden muss, wenn ihr LetsEncrypt mit eurer eigenen Domain nutzt. Dann weil noch ein alter Client genutzt wird, der TLS-SNI-01 verwendet. Dies möchte LetsEncrypt aufgrund von Sicherheitsvorkehrungen abschalten.

Weitere Infos hier auf Englisch: https://community.letsencrypt.org/t/action-required-lets-encrypt-certificate-renewals/83163

Den Client auf der Box zu aktualisieren geht recht einfach, da nur die Versionsnummer im Script angepasst werden muss. Zumindest um auf die Schnelle auf der sicheren Seite zu sein. Nach einem Neustart muss diese Änderung wieder vorgenommen werden!

Wir loggen uns also per SSH auf unsere Protonetbox und öffnen mit dem Editor unserer Wahl die Datei „/usr/local/bin/letsencrypt“

Das rot markierte ist der originale Eintrag. Diesen ändern wir so, dass es wie beim grün markierten aussieht. Oder kommentieren den roten Eintrag aus und fügen den grünen Eintrag hinzu. Jeder, wie er möchte. Zusätzlich noch den grünen Eintrag beachten, wo letsencrypt schließlich ausgeführt wird!

#!/bin/sh
CUSTOM_DOMAIN=$(cat /etc/protonet/nodenames/custom | xargs) # xargs trims white space
if [ ! "$CUSTOM_DOMAIN" ];then
  echo "--- Error. No custom domain set. Please create /etc/protonet/nodenames/custom, insert your domain and symlink /etc/protonet/nodename to it."
  exit 1;
fi
echo "--- Custom domain $CUSTOM_DOMAIN correctly set at /etc/protonet/nodenames/custom"
# This only works with IPv4 at the moment
RESOLVE_IP=$(dig +short $CUSTOM_DOMAIN A | tail -n 1)
MY_IP=$(curl http://ident.me/)
if [ $RESOLVE_IP = $MY_IP ]; then
  echo "--- Box is reachable from the outside via $CUSTOM_DOMAIN"
else
  echo "--- Error. Box is not reachable via $CUSTOM_DOMAIN. Please set DNS records or wait till nameservers have received the update."
  exit 1;
fi
# using the Email of the first user with the role 'admin'
EMAIL=$(cd /home/protonet/dashboard/current && RAILS_ENV=production bundle exec rails runner 'puts User.where(role: "admin").first.email' | tail -n 1)
echo "--- Using $EMAIL for letsencrypt registration."
echo "--- OK! Grabbing new SSL certificate via letsencrypt";
sudo mkdir -p /etc/protonet/letsencrypt
sudo ln -s /etc/protonet/letsencrypt /etc/letsencrypt
sudo rm -rf /tmp/letsencrypt
git clone https://github.com/certbot/certbot.git /tmp/letsencrypt
cd /tmp/letsencrypt
# pinned to certbot version 0.6.0
# git checkout v0.6.0
# pinned to certbot version 0.31.0
git checkout v0.31.0
# we don't want apt-get to run, we have everything needed for letsencrypt v0.6 to run
sed -i 's/apt-get update/echo/g' ./letsencrypt-auto
sed -i 's/apt-get install/echo/g' ./letsencrypt-auto
sudo sv stop /home/protonet/dashboard/shared/services/enabled/nginx
sudo service haproxy stop
./letsencrypt-auto certonly --standalone -d $CUSTOM_DOMAIN --email $EMAIL --agree-tos --force-renew --no-self-upgrade
rc=$?
if [ $rc -eq 0 ]; then
  echo "--- Successfully generated certificate.";
else
  echo "--- Error. Couldn't generate certificate via letsencrypt.";
  sudo sv start /home/protonet/dashboard/shared/services/enabled/nginx
  sudo service haproxy start
  exit $rc;
fi
if sudo test -e "/etc/letsencrypt/live/$CUSTOM_DOMAIN/fullchain.pem"; then
  echo "--- Certificate files exist.";
else
  echo "--- Error. Can't find certificate files."
  sudo sv start /home/protonet/dashboard/shared/services/enabled/nginx
  sudo service haproxy start
  exit 1;
fi
sudo mv /etc/protonet/httpd_ssl.crt /etc/protonet/httpd_ssl.crt.old
sudo mv /etc/protonet/httpd_ssl.key /etc/protonet/httpd_ssl.key.old
sudo cp /etc/letsencrypt/live/$CUSTOM_DOMAIN/fullchain.pem /etc/protonet/httpd_ssl.crt
sudo chown protonet:protonet /etc/protonet/httpd_ssl.crt
sudo chmod 0755 /etc/protonet/httpd_ssl.crt
sudo cp /etc/letsencrypt/live/$CUSTOM_DOMAIN/privkey.pem /etc/protonet/httpd_ssl.key
sudo chown protonet:protonet /etc/protonet/httpd_ssl.key
sudo chmod 0755 /etc/protonet/httpd_ssl.key
sudo sv start /home/protonet/dashboard/shared/services/enabled/nginx
sudo service haproxy start
echo "--- Enabling cron job to renew certificate once in a while."
touch /etc/protonet/letsencrypt_enabled

Nun kann man das Script einmal manuell starten

/usr/local/bin/letsencrypt
Bei einer Fehlermeldung

Sollte hier noch eine Fehlermeldung auftauchen, müssen evtl. noch Reste von TLS-SNI-01 entfernt werden, dies macht ihr mit folgendem Befehl

sudo sh -c "sed -i.bak -e 's/^\(pref_challs.*\)tls-sni-01\(.*\)/\1http-01\2/g' /etc/letsencrypt/renewal/*; rm -f /etc/letsencrypt/renewal/*.bak"
Um das ganze Reboot-Persistent zu bekommen, macht man Folgendes:

Wir wechseln in das Rootverzeichnis

cd /

Nun packen wir die Datei und legen sie in das local_patch Verzeichnis ab. Sollte das Verzeichnis noch nicht existieren, legen wir es an

sudo mkdir /protonet/firmware/local_patches

Existiert das Verzeichnis bereits, können wir direkt diesen Befehl ausführen:

sudo tar cvzf /protonet/firmware/local_patches/letsencrypt_latest.tar.gz usr/local/bin/letsencrypt

Nun wird bei jedem Neustart diese tar.gz Datei entpackt und die originale Datei überschrieben. Wenn man dieses wieder rückgängig machen möchte, muss man einfach die tar.gz Datei aus dem local_patches Ordner entfernen und die Box neustarten.

Den Originalpost findet ihr hier:

http://badberg.online/r/Klz


Zuletzt bearbeitet: 09.03.2019 - 18:24

19 Antworten

Daniel 04.03.2019 - 15:34

Hi Markus,

danke Dir für die Anleitung. Per Coda war das in Sekunden erledigt und weggespeichert. 😉

Jetzt also Daumen drücken und hoffen, dass bei der nächsten Aktualisierung alles glatt läuft. Anschlussfragen:
– Das Zertifikat wurde gerade gestern noch einmal erneuert, nun gültig bis. 1. Juni. Ob die Versionsänderung geklappt hat oder nicht, werden wir also erst am 2. Juni wissen?
– Wenn bis dahin SOUL neu gestartet muss, sind die Änderungen in o. g. Datei erneut durchzuführen, richtig?
– Weißt Du, ob auch noch eine „richtige“ Lösung für alle geben wird?

Viele Grüße
Daniel

Markus Badberg (Protonet Support) 04.03.2019 - 22:31

Hallo Daniel,

soweit ich weiß, soll das natürlich in einem späteren Update gefixt werden. Auf das kommende Update warten wir ja alle schon sehnsüchtig 🙂

Ich habe im Blogbeitrag, den ich am Ende des Artikels gesetzt habe, noch ein Update vorgenommen. Dort wird nun auch beschrieben, wie dieser Eintrag persistent gesetzt wird und natürlich auch, wie dieses dann wieder entfernt wird, falls das neue Update raus kommt.

Schöne Grüße,
Markus

born-to-be-root 05.03.2019 - 9:39

Könnte man nicht das Script dann auch sofort einmal ausführen, um die aktuelle Version von letsencrypt auszuchecken und ein neues Zertifikat zu erzeugen? Denn das Problem ist ja schon, dass bis zur nächsten Ausführung des cron-jobs noch die alte Version drauf ist.

Markus Badberg (Protonet Support) 05.03.2019 - 10:51

Der Blogeintrag ist aktueller 😉

Dort ist es bereits beschrieben.

Ich mag dieses System hier nicht, da es den Beitrag ziemlich verunglimpft hat. Ich hoffe, ich werde diesen Beitrag hier demnächst vernünftig editieren können, dann füge ich das auch hier hinzu.

born-to-be-root 05.03.2019 - 18:15

Hat funktioniert, danke!

Daniel 05.03.2019 - 10:06

Moin Markus,

danke Dir! In dem neuen Blog-Zusatz scheint ein Fehler zu sein, Antwort:
tar: Removing leading `/‘ from member names

Da ich von der Konsole eigentlich keine Ahnung habe, weiß Qwant natürlich Rat: Müsste es statt „sudo tar cvzf ….“vielleicht „sudo tar cvPf…“ heißen? Danach ist ist die Datei letsencrypt_latest.tar.gz jedenfalls /local_patches. Allerdings verstehe ich die Infos zu absoluten Pfadnamen beim Entpacken etc. nicht. Und: Nach einem Neustart ist bei mit in der letsencrypt-Datei wieder die 0.6.0

Noch eine Frage zu Deinem Blog: Wann sollte/könnte der beschriebene Fehler „Performing the following challenges:…“ auftreten? Ich habe die Änderungen wie gesagt direkt per Coda gemacht, da ich keine Ahnung habe, wie ich mich in der Konsole bewege. Dabei gab’s keine Fehlermeldung, SOUL/Carla läuft noch und ist erreichbar…?

Danke für die Hilfe!

VG
Daniel

Markus Badberg (Protonet Support) 05.03.2019 - 10:57

Das ist nur eine Warnung und tar entfernt den „/“ selbst.
Ist also nur ein kleiner Fehler, der nichts ausmachen dürfte, wenn man vorher in das Rootverzeichnis wechselt. Also vorher ein „cd /“

Da ich nicht genau weiß, wie SOUL die Datei entpackt, ist die Version aus dem Rootverzeichnis mit relativem Pfad richtiger.

Wenn du keine Fehlermeldung hattest, ist bei dir alles gut. Bei mir lief es ebenfalls so durch.
Jemand anderes hat mich auf den Fehler aufmerksam gemacht und ich habe diesen Fehler mit seiner Hilfe beheben können.

m4gr01ino 06.03.2019 - 9:53

Wenn mein Zertifikat lt. Browser bis Juni gültig ist, muss ich dann diesen Patch ausführen oder reichts dann, auf das nächste Update zu warten (vorausgesetzt das kommt vor Juni 😉 )?

Markus Badberg (Protonet Support) 06.03.2019 - 11:03

Wenn das Update bis dahin draußen ist, kann man schon abwarten.
Man kann sich ja einen Termin eine Woche vor Ablauf setzen und dann hat man immer noch genügend Zeit, zu reagieren.

msch 06.03.2019 - 14:58

Achtung: hier und im Blog ist ein kleiner aber feiner Fehler. Die Zeile muss wie folgt lauten:

sudo mkdir /protonet/firmware/local_patches

patches mit kleinem „p“, denn Linux ist case sensitive!

Markus Badberg (Protonet Support) 06.03.2019 - 16:13

Ist geändert! 🙂 Danke

Daniel 06.03.2019 - 19:05

Moin!

So, das persistente Eintragen der Version 31 scheint geklappt zu haben: Nach Neustart ist weiter die Zeilen mit 31 drin.

Das Ausführen des Scripts endete anfangs aber (doch) mit dem angesprochenen Error. Dann fiel mir in der Fehlermeldung auf, das beim „Fetching“ (was immer das auch ist) eine http-URL der Carla aufgerufen werden soll, also Port 80 – der aber gesperrt war. Nach der Freigabe hat sich alles zurechtgeschnuggelt, SSL-Zertfikat mit Datum heute erneuert. – Vielen Dank für die Hilfe, @Markus!!

Kurz: Für das beschriebene Vorgehen MUSS Port 80 im Router auf die Box zeigen. Die bisherige LetsEncrypt-Aktualisierung ging also ohne Port 80.

Gretchenfrage wäre aber, ob der Port nun dauerhaft nach außen offen sein muss, oder ob das nur für die einmalige, initiale Freischaltung notwendig war. Wenn der Port 80 nun immer offen sein muss, erscheint das für mich als Laien suboptimal – oder was meinen die Experten? Kann das, zumal mit einem steinalten Ubuntu im Hintergrund, ein Sicherheitsrisiko sein? Die LetsEncrypt-Initiative wird sich aber ja irgendwas dabei gedacht haben…?

Viele Grüße
Daniel

Markus Badberg (Protonet Support) 09.03.2019 - 18:29

Das kommt auf die jeweilige Version an, die vom certbot genutzt wird. Es war in früheren Versionen anscheinend mal möglich und in der v0.31.0 muss Port 80 offen sein. https://community.letsencrypt.org/t/required-ports-to-run-lets-encrypt/36101 Auch scheint v0.32.0, die seit ein paar Tagen draußen ist, unter SOUL nicht mehr zu funktionieren. Daher habe ich die Anleitung noch erweitert.Und die Webserver Konfiguration auf der Box ist so, dass immer automatisch auf 443, also SSL umgeleitet wird. Das ist das übliche vorgehen, damit die Box immer Erreichbar ist.Wenn ich nämlich noch niemals auf der Box war und Port 80 zeigt nicht auf die Box, dann erhalte ich, wenn ich die Seite ohne explizit „https“ zu schreiben, eine Meldung, dass die Seite nicht Erreichbar ist.Ist bei meiner Webseite und vielen Anderen übrigens auch genau so 😉

Daniel 09.03.2019 - 19:27

Danke Markus, habe ich eingebaut. Spiele aber doch mit dem Gedanken, wie ganz am Anfang mal auf ein eigenes, „manuelles“ Zertifikat zu nutzen. Siehe https://support.protonet.info/de/forum/eigenes-ssl-bei-eigener-domain-zertifikataufbau/?usp_success=2&post_id=19743

Der offene Port 80 am Router macht mich ein wenig nervös… 😉

Markus Badberg (Protonet Support) 09.03.2019 - 19:43

Braucht dich nicht nervös zu machen, so lange er auf die Protonetbox zeigt.
Dahinter steht eine 302’er Weiterleitung.

Natürlich kannst du auch ein anderes Zertifikat nutzen. LetsEncrypt stellt ja nur eine kostenlose Alternative dar. Vor 2015 gab es diese Möglichkeit überhaupt nicht und jedes Zertifikat hat Geld gekostet.

msch 11.03.2019 - 17:11

Top. Der Hinweis mit Port 80 sollte in fett 😉 auch auf die Anleitung im MBits-Blog.
Besten Dank!

Chau 13.03.2019 - 3:00

Hallo,
Ich versuche gerade mein letsEncrypt Client zu aktualisieren und scheiterte bereits an dem ersten Schritt.
Wie logge ich mich auf meiner Box via SSH ein?
Ich habe bereits hier in der Suche “ SSH einloggen“ eingeben und bekomme keinen Beitrag oder Anleitung wie man sich auf seiner Box via SSH einloggt.
Kann mir jemand den Link zur Anleitung geben?
Ich bedanke mich herzlichst.
Chau

Daniel 14.03.2019 - 10:27

Moin Chau,

siehe https://support.protonet.info/de/faq/cat-faq/videos/#video-ssh-zugriff-auf-protonet-server erster Punkt mit Video von der lieben Micha.

VG und viel Erfolg
Daniel

LitServ 15.03.2019 - 8:27

Hallo Markus Badberg,

Danke!, hat auf meiner Maya funktioniert, Zertifikat ist erneuert.

Frage: Ich habe eine zweite Maya, die ich von außen über einen anderen Port (4-stellig) erreiche. Zur Klarstellung: der vom Standard abweichende Port gilt nur ‚von außen‘; intern natürlich Standard-Port 443.

Auf dieser zweiten Maya ist das Zertifikat abgelaufen.

Will ich das Zertifikat erneuern – z.B. mit dem von Ihnen beschriebenen Patch – , muss ich die ‚erste‘ Maya‘ aus dem Netz nehmen und den Router vorübergehend so konfigurieren, dass die zweite Maya über den Standard-Port für https erreichbar ist.

Das geht natürlich, ist aber lästig. Gibt es eine Möglichkeit, die ganze Prozedur so zu gestalten, dass das Zertifikat bezogen bzw. erneuert werden kann, selbst wenn von außen die Maya nicht über den Standard-Port erreichbar ist?