One place for hosting & domains

      sichern

      Sichern von Nginx mit Let’s Encrypt unter Ubuntu 20.04


      Einführung

      Let´s Encrypt ist eine Zertifizierungsstelle (CA), die eine einfache Möglichkeit bietet, kostenlose TLS/SSL-Zertifikate zu erhalten und zu installieren. Dadurch können Sie die verschlüsselten HTTPS auf Webservern bereitstellen. Es vereinfacht den Prozess, indem ein Software-Client, Certbot, bereitgestellt wird, der versucht, die meisten (wenn nicht alle) der erforderlichen Schritte zu automatisieren. Derzeit ist der gesamte Prozess zum Abrufen und Installieren eines Zertifikats sowohl auf Apache als auch auf Nginx vollständig automatisiert.

      In diesem Tutorial nutzen Sie Certbot, um ein kostenloses SSL-Zertifikat für Nginx auf Ubuntu 20.04 zu erhalten und Ihr Zertifikat so einzurichten, dass es automatisch erneuert wird.

      Dieses Tutorial verwendet eine separate Nginx Serverkonfiguration anstelle der Standarddatei. Wir empfehlen die Erstellung neuer Nginx-Serverblockdateien für jede Domäne, da so häufige Fehler vermieden werden können und die Standarddateien als Fallback-Konfiguration erhalten bleiben.

      Voraussetzungen

      Um dieser Anleitung zu folgen, benötigen Sie:

      • Ein Ubuntu 20.04-Server, der gemäß dem Tutorial Ersteinrichtung des Servers für Ubuntu 20.04 eingerichtet wurde, einschließlich eines Nicht-root-Benutzers mit sudo-Berechtigung und einer Firewall.

      • Einen registrierten Domänennamen. In diesem Tutorial wird durchgehend example.com genutzt. Sie können einen Domänennamen unter Namecheap erwerben oder einen kostenlosen von Freenom herunterladen oder einfach die Domänenregistrierungsstelle Ihrer Wahl verwenden.

      • Die beiden folgenden DNS-Einträge für Ihren Server eingerichtet. Wenn Sie DigitalOcean verwenden, lesen Sie bitte unsere DNS Dokumentation für Details, wie Sie sie hinzufügen.

        • Ein A-Datensatz mit example.com mit Verweis auf die öffentliche IP-Adresse Ihres Servers.
        • Ein A-Datensatz mit www.example.com, der auf die öffentliche IP-Adresse Ihres Servers verweist.
      • Nginx wird gemäß Installieren von Nginx unter Ubuntu 20.04 installiert. Stellen Sie sicher, dass Sie für Ihre Domäne einen Serverblock haben. In diesem Tutorial nutzen wir /etc/nginx/sites-available/example.com als Beispiel.

      Schritt 1 — Installieren von Certbot

      Der erste Schritt zur Nutzung von Let’s Encrypt, um ein SSL-Zertifikat zu erhalten, ist die Installation der Certbot-Software auf Ihrem Server.

      Installieren Sie Certbot und das Nginx Plugin mit apt:

      • sudo apt install certbot python3-certbot-nginx

      Certbot ist nun einsatzbereit, aber damit SSL für Nginx damit automatisch konfiguriert werden kann, müssen wir einige Bereiche der Nginx-Konfiguration überprüfen.

      Schritt 2 — Bestätigen der Nginx-Konfiguration

      Certbot muss in Ihrer Nginx-Konfiguration den richtigen Serverblock finden können, damit SSL automatisch konfiguriert werden kann. Dazu hält er nach einer server_name-Anweisung Ausschau, die zur Domäne passt, für die Sie ein Zertifikat anfordern.

      Wenn Sie den Schritt zur Einrichtung des Serverblocks im Nginx Installations-Tutorial befolgt haben, sollten Sie einen Serverblock für Ihre Domäne unter /etc/nginx/sites-available/example.com mit der Anweisung server_name haben, der bereits entsprechend eingerichtet wurde.

      Um dies zu überprüfen, öffnen Sie die Konfigurationsdatei für Ihre Domäne mit nano oder einem anderen Texteditor:

      • sudo nano /etc/nginx/sites-available/example.com

      Suchen Sie nach der Zeile server_name. Das sollte wie folgt aussehen:

      /etc/nginx/sites-available/example.com

      ...
      server_name example.com www.example.com;
      ...
      

      Wenn Sie sie gefunden haben, schließen Sie den Editor und fahren Sie mit dem nächsten Schritt fort.

      Sollten Sie sie nicht finden, aktualisieren Sie entsprechend. Speichern Sie dann die Datei, beenden Sie den Editor und überprüfen Sie die Syntax Ihrer Konfigurationsbearbeitungen:

      Wenn Sie einen Fehler erhalten, öffnen Sie die Serverblockdatei und überprüfen Sie sie auf Schreibfehler oder fehlende Zeichen. Sobald die Syntax Ihrer Konfigurationsdatei korrekt ist, laden Sie Nginx neu, um die neue Konfiguration zu laden:

      • sudo systemctl reload nginx

      Certbot kann nun den richtigen Serverblock finden und automatisch aktualisieren.

      Als Nächstes aktualisieren wir die Firewall, um den HTTPS-Datenverkehr zu ermöglichen.

      Schritt 3 — Zulassen von HTTPS durch die Firewall

      Wenn Sie die UFW-Firewall aktiviert haben, wie im Leitfaden zu den Voraussetzungen empfohlen, müssen Sie die Einstellungen so anpassen, dass Sie den HTTPS-Datenverkehr zulassen. Praktischerweise registriert Nginx einige Profile mit ufw bei der Installation.

      Sie können die aktuelle Einstellung sehen, indem Sie Folgendes eingeben:

      Sie sieht wahrscheinlich etwa so aus, was bedeutet, dass nur HTTP-Verkehr zum Webserver zugelassen ist:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6)

      Um den HTTPS-Verkehr zu ermöglichen, erlauben Sie das Nginx Full Profil und löschen Sie die Zulassung des redundanten Nginx HTTP Profils:

      • sudo ufw allow 'Nginx Full'
      • sudo ufw delete allow 'Nginx HTTP'

      Ihr Status sollte nun wie folgt aussehen:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      Als Nächstes führen wir Certbot aus und holen unsere Zertifikate ab.

      Schritt 4 — Abrufen eines SSL-Zertifikats

      Certbot bietet eine Vielzahl von Möglichkeiten, um SSL-Zertifikate über Plugins zu erhalten. Das Nginx-Plugin übernimmt die Neukonfiguration von Nginx und das Neuladen der Konfiguration, wenn nötig. Geben Sie Folgendes ein, um dieses Plugin zu verwenden:

      • sudo certbot --nginx -d example.com -d www.example.com

      Damit wird Certbot mit dem --nginx Plugin ausgeführt, wobei über -d die Domänennamen angegeben werden, für die das Zertifikat gültig sein soll.

      Wenn Sie Certbot zum ersten Mal ausführen, werden Sie aufgefordert, eine E-Mail-Adresse einzugeben und die Bedingungen des Dienstes zu akzeptieren. Danach kommuniziert Certbot mit dem Let’s Encrypt-Server und stellt dann anhand einer Prüfung sicher, dass Sie die Domäne, für die Sie das Zertifikat anfordern, auch kontrollieren.

      Nach erfolgreicher Überprüfung fragt Certbot, wie Sie Ihre HTTPS-Einstellungen konfigurieren möchten.

      Output

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

      Treffen Sie Ihre Wahl und drücken Sie dann ENTER. Die Konfiguration wird aktualisiert und Nginx zum Abholen der neuen Einstellungen neu geladen. Certbot schließt mit einer Mitteilung, dass der Prozess erfolgreich war und wo Ihre Zertifikate gespeichert sind:

      Output

      IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/example.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/example.com/privkey.pem Your cert will expire on 2020-08-18. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Ihre Zertifikate werden heruntergeladen, installiert und geladen. Versuchen Sie, Ihre Website mit https:// neu zu laden und beachten Sie den Sicherheitsindikator Ihres Browsers. Es sollte angezeigt werden, dass die Seite ordnungsgemäß gesichert ist. Meist sieht man das an einem Schloss-Symbol. Wenn Sie Ihren Server mit dem SSL Labs Server Test testen, erhält er eine A-Bewertung.

      Wir wollen abschließend den Erneuerungsvorgang testen.

      Schritt 5 – Überprüfen der automatischen Erneuerung von Certbot

      Zertifikate von Let’s Encrypt sind nur neunzig Tage gültig. Das soll Benutzer dazu ermutigen, die Erneuerung ihrer Zertifikate zu automatisieren. Das Certbot-Paket, das wir installiert haben, übernimmt diese Aufgabe für uns und fügt hierfür einen systemd Timer hinzu, der sicherstellt, dass sie zweimal täglich ausgeführt wird und jedes Zertifikat automatisch nach dreißig Tagen erneuert wird.

      Sie können den Status des Timers mit systemctl abfragen:

      • sudo systemctl status certbot.timer

      Output

      ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Mon 2020-05-04 20:04:36 UTC; 2 weeks 1 days ago Trigger: Thu 2020-05-21 05:22:32 UTC; 9h left Triggers: ● certbot.service

      Um den Erneuerungsprozess zu testen, können Sie mit certbot einen Probelauf durchführen:

      • sudo certbot renew --dry-run

      Wenn Sie keine Fehler sehen, sind Sie fertig. Bei Bedarf erneuert Certbot Ihre Zertifikate und lädt Nginx neu, um die Änderungen zu übernehmen. Wenn der automatische Erneuerungsprozess jemals fehlschlägt, sendet Let’s Encrypt eine Nachricht an die von Ihnen angegebene E-Mail und warnt Sie, wenn Ihr Zertifikat bald abläuft.

      Zusammenfassung

      In diesem Tutorial haben Sie den Let’s Encrypt-Client Certbot installiert, SSL-Zertifikate für Ihre Domäne heruntergeladen, Nginx so konfiguriert, dass es diese Zertifikate verwendet und die automatische Zertifikatserneuerung eingerichtet. Wenn Sie weitere Fragen zur Verwendung von Certbot haben, ist die Dokumentation ein guter Ausgangspunkt.



      Source link

      So installieren und sichern Sie Redis unter Ubuntu 20.04


      Eine frühere Version dieses Tutorials wurde von Justin Ellingwood verfasst

      Einführung

      Redis ist ein In-Memory-Schlüsselwertspeicher, der für seine Flexibilität, Leistung und breite Sprachunterstützung bekannt ist. Dieses Tutorial zeigt, wie Sie Redis auf einem Ubuntu 20.04-Server installieren, konfigurieren und sichern.

      Voraussetzungen

      Um diesen Leitfaden auszuführen, benötigen Sie Zugriff auf einen Ubuntu 20.04-Server, der einen non-root user mit sudo-Berechtigungen und eine mit ufw konfigurierte Firewall aufweist. Hierzu können Sie unserem Leitfaden zur Ersteinrichtung eines Servers unter Ubuntu 20.04 folgen.

      Schritt 1 — Installieren und Konfigurieren von Redis

      Wir verwenden den APT-Paketmanager, um Redis aus den offiziellen Ubuntu-Repositorys zu installieren. Zum Zeitpunkt dieses Schreibens ist die in den Standard-Repositorys verfügbare Version 5.0.7.

      Als Erstes aktualisieren Sie Ihren lokalen apt-Paketcache:

      Installieren Sie anschließend Redis, indem Sie Folgendes eingeben:

      • sudo apt install redis-server

      Dadurch werden Redis und seine Abhängigkeiten heruntergeladen und installiert. Danach müssen Sie eine wichtige Konfigurationsänderung in der Redis-Konfigurationsdatei vornehmen, die bei der Installation automatisch generiert wurde.

      Öffnen Sie diese Datei mit Ihrem bevorzugten Texteditor:

      • sudo nano /etc/redis/redis.conf

      Suchen Sie in der Datei die Anweisung supervised. Mit dieser Anweisung können Sie ein Init-System deklarieren, um Redis als Dienst zu verwalten. Damit erhalten Sie mehr Kontrolle über seine Funktion. Die Anweisung supervised ist standardmäßig auf no eingestellt. Da Ubuntu das Init-System systemd verwendet, ändern Sie die Anweisung zu systemd:

      /etc/redis/redis.conf

      . . .
      
      # If you run Redis from upstart or systemd, Redis can interact with your
      # supervision tree. Options:
      #   supervised no      - no supervision interaction
      #   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
      #   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
      #   supervised auto    - detect upstart or systemd method based on
      #                        UPSTART_JOB or NOTIFY_SOCKET environment variables
      # Note: these supervision methods only signal "process is ready."
      #       They do not enable continuous liveness pings back to your supervisor.
      supervised systemd
      
      . . .
      

      Das ist die einzige Änderung, die Sie an dieser Stelle in der Redis-Konfigurationsdatei vornehmen müssen. Wenn Sie fertig sind, speichern und schließen Sie die Datei. Wenn Sie nano zum Bearbeiten der Datei verwendet haben, drücken Sie dazu STRG + X, Y und dann ENTER.

      Starten Sie dann den Redis-Dienst neu, damit die Änderungen, die Sie in der Konfigurationsdatei vorgenommen haben, angewendet werden:

      • sudo systemctl restart redis.service

      Redis ist nun installiert und konfiguriert und läuft auf Ihrem Rechner. Bevor Sie Redis benutzen, ist es jedoch ratsam, zunächst zu prüfen, ob es korrekt funktioniert.

      Schritt 2 — Testen von Redis

      Wie bei jeder neu installierten Software ist es sinnvoll, sicherzustellen, dass Redis wie erwartet funktioniert, bevor weitere Änderungen an der Konfiguration vorgenommen werden. Wir behandeln in diesem Schritt verschiedene Möglichkeiten, um zu prüfen, ob Redis korrekt funktioniert.

      Zuerst überprüfen Sie, ob der Redis-Dienst ausgeführt wird:

      • sudo systemctl status redis

      Wenn er ohne Fehler ausgeführt wird, gibt dieser Befehl eine Ausgabe, die der folgenden ähnelt:

      Output

      ● redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-04-30 23:26:54 UTC; 4s ago Docs: http://redis.io/documentation, man:redis-server(1) Process: 36552 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS) Main PID: 36561 (redis-server) Tasks: 4 (limit: 2345) Memory: 1.8M CGroup: /system.slice/redis-server.service └─36561 /usr/bin/redis-server 127.0.0.1:6379 . . .

      Hier können Sie sehen, dass Redis ausgeführt wird und bereits aktiviert ist. Das bedeutet, dass Redis bei jedem Boot des Servers automatisch startet.

      Anmerkung: Diese Einstellung ist für viele häufige Anwendungsfälle von Redis wünschenswert. Falls Sie Redis lieber manuell bei jedem Boot des Servers starten möchten, können Sie das mit folgendem Befehl konfigurieren:

      • sudo systemctl disable redis

      Um zu testen, ob Redis richtig funktioniert, stellen Sie mit dem Redis-Befehlszeilenclient redis-cli eine Verbindung zum Server her:

      Testen Sie in der folgenden Eingabeaufforderung die Verbindung mit dem Befehl ping:

      Output

      PONG

      Diese Ausgabe bestätigt, dass die Serververbindung nach wie vor besteht. Als Nächstes überprüfen Sie, ob Sie Schlüssel festlegen können, indem Sie Folgendes ausführen:

      Output

      OK

      Rufen Sie den Wert ab, indem Sie Folgendes eingeben:

      Wenn alles funktioniert, können Sie den gespeicherten Wert abrufen:

      Output

      "It's working!"

      Nachdem Sie die Bestätigung haben, dass Sie den Wert abrufen können, beenden Sie die Redis-Eingabeaufforderung, um wieder zur Shell zu gelangen:

      Als Letztes testen wir, ob Redis auch nach einem Stopp oder Neustart die Daten noch enthält. Dazu starten Sie die Redis-Instanz zunächst neu:

      • sudo systemctl restart redis

      Stellen Sie dann erneut mit dem Befehlszeilenclient eine Verbindung her:

      Bestätigen Sie, dass Ihr Testwert immer noch verfügbar ist:

      Der Wert Ihres Schlüssels sollte immer noch zugänglich sein:

      Output

      "It's working!"

      Wenn Sie fertig sind, beenden Sie und kehren zur Shell zurück:

      Damit ist die Redis-Installation voll funktionsfähig und kann von Ihnen verwendet werden. Einige der Standardkonfigurationseinstellungen sind jedoch unsicher und bieten böswilligen Akteuren die Möglichkeit, Ihren Server und seine Daten anzugreifen und sich Zugang dazu zu verschaffen. Die verbleibenden Schritte in diesem Tutorial behandeln Methoden zur Milderung dieser Schwachstellen, wie sie in der offiziellen Redis-Website beschrieben sind. Diese Schritte sind optional und Redis wird auch dann noch funktionieren, wenn Sie sie nicht befolgen. Es wird jedoch dringend empfohlen, die Schritte auszuführen, um die Sicherheit Ihres Systems zu erhöhen.

      Schritt 3 — Binden an localhost

      Standardmäßig ist Redis nur von localhost zugänglich. Wenn Sie Redis jedoch mit einem anderen Tutorial als diesem installiert und konfiguriert haben, haben Sie die Konfigurationsdatei eventuell so geändert, dass sie Verbindungen von überall zulässt. Das ist nicht so sicher wie eine Bindung an localhost.

      Um dies zu korrigieren, öffnen Sie die Redis-Konfigurationsdatei zur Bearbeitung:

      • sudo nano /etc/redis/redis.conf

      Suchen Sie diese Zeile und stellen Sie sicher, dass die Kommentierung aufgehoben ist (entfernen Sie das #, falls vorhanden):

      /etc/redis/redis.conf

      bind 127.0.0.1 ::1
      

      Danach speichern und schließen Sie die Datei (drücken Sie STRG + X, Y und dann ENTER).

      Starten Sie dann den Dienst neu, um sicherzustellen, dass systemd Ihre Änderungen liest:

      • sudo systemctl restart redis

      Um zu prüfen, ob diese Änderung angenommen wurde, führen Sie den folgenden netstat-Befehl aus:

      • sudo netstat -lnp | grep redis

      Output

      tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 14222/redis-server tcp6 0 0 ::1:6379 :::* LISTEN 14222/redis-server

      Anmerkung: Der Befehl netstat ist möglicherweise nicht standardmäßig auf Ihrem System verfügbar. In diesem Fall können Sie ihn (sowie eine Reihe anderer praktischer Netzwerktools) mit dem folgenden Befehl installieren:

      • sudo apt install net-tools

      Die Ausgabe zeigt, dass das redis-server-Programm an localhost (127.0.0.1) gebunden ist und zeigt die Änderung, die Sie gerade in der Konfigurationsdatei vorgenommen haben. Wenn Sie eine andere IP-Adresse in dieser Spalte sehen, z. B. (0.0.0.0), sollten Sie überprüfen, ob Sie die Kommentierung in der korrekten Zeile aufgehoben haben und den Redis-Dienst erneut starten.

      Nachdem die Redis-Installation nun nur auf localhost lauscht, wird es für böswillige Akteure schwieriger, Anfragen zu stellen oder Zugriff auf Ihren Server zu erhalten. Allerdings ist Redis derzeit nicht so eingestellt, dass Benutzer sich authentifizieren müssen, bevor sie Änderungen an der Konfiguration oder den gespeicherten Daten von Redis vornehmen können. Um hier Abhilfe zu schaffen, können Sie mit Redis verlangen, dass Benutzer sich mit einem Passwort authentifizieren, bevor sie Änderungen über den Redis-Client redis-cli vornehmen.

      Schritt 4 — Konfigurieren eines Redis-Passworts

      Durch die Konfiguration eines Redis-Passworts wird eine der beiden in Redis integrierten Sicherheitsfunktionen befähigt – der Befehl auth, mit dem sich Clients für den Zugriff auf die Datenbank authentifizieren müssen. Das Passwort wird direkt in der Konfigurationsdatei von Redis, /etc/redis/redis.conf, konfiguriert. Öffnen Sie diese Datei erneut mit Ihrem bevorzugten Editor:

      • sudo nano /etc/redis/redis.conf

      Scrollen Sie zum Abschnitt SECURITY und suchen Sie eine Anweisung mit der Kommentierung:

      /etc/redis/redis.conf

      . . .
      # requirepass foobared
      . . .
      

      Heben Sie die Kommentierung auf, indem Sie # entfernen, und ändern Sie foobared in ein sicheres Passwort.

      Anmerkung: Über der Anweisung requirepass in der Datei redis.conf gibt es eine kommentierte Warnung:

      /etc/redis/redis.conf

      . . .
      # Warning: since Redis is pretty fast an outside user can try up to
      # 150k passwords per second against a good box. This means that you should
      # use a very strong password otherwise it will be very easy to break.
      #
      . . .
      

      Daher ist es wichtig, dass Sie einen sehr starken und sehr langen Wert als Ihr Passwort angeben. Anstatt ein Passwort selbst einzurichten, können Sie den Befehl openssl verwenden, um ein Zufallspasswort zu generieren, wie im folgenden Beispiel. Durch Weiterleiten der Ausgabe des ersten Befehls an den zweiten openssl-Befehl, wie hier gezeigt, werden alle durch den ersten Befehl erzeugten Zeilenumbrüche entfernt:

      • openssl rand 60 | openssl base64 -A

      Ihre Ausgabe sollte ungefähr wie folgt aussehen:

      Output

      RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

      Nach dem Kopieren und Einfügen der Ausgabe dieses Befehls als den neuen Wert für requirepass sollte es so aussehen:

      /etc/redis/redis.conf

      requirepass RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

      Nach dem Einrichten des Passworts speichern und schließen Sie die Datei. Starten Sie erneut Redis:

      • sudo systemctl restart redis.service

      Öffnen Sie den Redis-Client, um zu testen, ob das Passwort funktioniert:

      Folgendes zeigt eine Sequenz von Befehlen, mit denen getestet wird, ob das Redis-Passwort funktioniert. Der erste Befehl versucht, einen Schlüssel auf einen Wert vor der Authentifizierung einzustellen:

      Das funktioniert nicht, da Sie keine Authentifizierung durchgeführt haben. Daher gibt Redis einen Fehler aus:

      Output

      (error) NOAUTH Authentication required.

      Der nächste Befehl führt die Authentifizierung mit dem Passwort durch, das in der Redis-Konfigurationsdatei angegeben ist:

      Redis bestätigt:

      Output

      OK

      Danach wird der vorherige Befehl erfolgreich ausgeführt:

      Output

      OK

      get key1 fragt Redis nach dem Wert des neuen Schlüssels.

      Output

      "10"

      Nachdem Sie die Bestätigung haben, dass Sie Befehle im Redis ausführen können, beenden Sie redis-cli:

      Als Nächstes befassen wir uns mit der Umbenennung von Redis-Befehlen, die Ihrem Rechner schweren Schaden zufügen können, falls sie versehentlich oder durch einen bösartigen Akteur eingegeben werden.

      Schritt 5 — Umbenennen von gefährlichen Befehlen

      Die andere in Redis integrierte Sicherheitsfunktion besteht in der Umbenennung oder vollständigen Deaktivierung bestimmter Befehle, die als gefährlich eingestuft werden.

      Diese Befehle können von unautorisierten Benutzern dazu verwendet werden, Ihre Daten anders zu konfigurieren, zu zerstören oder anderweitig zu löschen. Wie das Authentifizierungs-Passwort wird das Umbenennen oder Deaktivieren von Befehlen im gleichen SECURITY-Abschnitt der Datei /etc/redis/redis.conf konfiguriert.

      Einige der Befehle, die als gefährlich eingestuft werden, sind: FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME und DEBUG. Die Liste ist nicht umfassend, aber das Umbenennen oder Deaktivieren aller Befehle in dieser Liste ist ein guter Ausgangspunkt, um die Sicherheit Ihres Redis-Servers zu erhöhen.

      Ob Sie einen Befehl deaktivieren oder umbenennen sollten, hängt von Ihren spezifischen Bedürfnissen oder von denen Ihrer Website ab. Wenn Sie für einen Befehl, der missbraucht werden könnte, keine Verwendung haben, können Sie ihn deaktivieren. Andernfalls liegt es in Ihrem Interesse, diesen umzubenennen.

      Um Redis-Befehle umzubenennen oder zu deaktivieren, öffnen Sie erneut die Konfigurationsdatei:

      • sudo nano /etc/redis/redis.conf

      Achtung: Die folgenden Schritte zur Deaktivierung und Umbenennung von Befehlen sind Beispiele. Sie sollten nur die Befehle deaktivieren oder umbenennen, die für Sie sinnvoll sind. Sie können die vollständige Liste der Befehle unter redis.io/commands selbst überprüfen und eruieren, wie diese missbraucht werden könnten.

      Um einen Befehl zu deaktivieren, benennen Sie ihn einfach wie unten gezeigt in eine leere Zeichenfolge um (gekennzeichnet durch ein Paar Anführungszeichen ohne Zeichen dazwischen):

      /etc/redis/redis.conf

      . . .
      # It is also possible to completely kill a command by renaming it into
      # an empty string:
      #
      rename-command FLUSHDB ""
      rename-command FLUSHALL ""
      rename-command DEBUG ""
      . . .
      

      Zur Umbenennung eines Befehls geben Sie diesem wie bei den unten gezeigten Beispielen einen anderen Namen. Umbenannte Befehle sollten für andere schwierig zu erraten und für Sie selbst leicht zu merken sein:

      /etc/redis/redis.conf

      . . .
      # rename-command CONFIG ""
      rename-command SHUTDOWN SHUTDOWN_MENOT
      rename-command CONFIG ASC12_CONFIG
      . . .
      

      Speichern Sie Ihre Änderungen und schließen Sie die Datei.

      Nach der Umbenennung eines Befehls wenden Sie die Änderung an, indem Sie Redis neu starten:

      • sudo systemctl restart redis.service

      Um den neuen Befehl zu testen, gehen Sie in die Redis-Befehlszeile:

      Führen Sie eine Authentifizierung durch:

      Output

      OK

      Nehmen wir an, dass Sie den Befehl CONFIG so wie im voherigen Beispiel in ASC12_CONFIG umbenannt haben. Versuchen Sie zunächst, den ursprünglichen Befehl CONFIG zu verwenden. Das sollte fehlschlagen, da Sie diesen umbenannt haben:

      Output

      (error) ERR unknown command `config`, with args beginning with:

      Der umbenannte Befehl kann jedoch erfolgreich aufgerufen werden. Die Groß- und Kleinschreibung muss nicht beachtet werden:

      • asc12_config get requirepass

      Output

      1) "requirepass" 2) "your_redis_password"

      Zum Schluss können Sie redis-cli verlassen:

      Beachten Sie, dass Sie sich erneut authentifizieren müssen, wenn Sie bereits die Befehlszeile von Redis verwenden und Redis neu starten. Andernfalls erhalten Sie diesen Fehler, wenn Sie einen Befehl eingeben:

      Output

      NOAUTH Authentication required.

      Bezüglich der Umbenennung von Befehlen wird am Ende des Abschnitts SECURITY in /etc/redis/redis.conf folgende Warnung angegeben:

      /etc/redis/redis.conf

      . . .
      # Please note that changing the name of commands that are logged into the
      # AOF file or transmitted to replicas may cause problems.
      . . .
      

      Hinweis: Das Redis-Projekt verwendet die Begriffe „master“ und „slave“, während DigitalOcean generell die Alternativen „primary“ und „secondary“ bevorzugt. Um Verwirrungen zu vermeiden, werden an dieser Stelle die in der Redis-Dokumentation genutzten Begriffe verwendet.

      Das bedeutet, dass es kein Problem geben sollte, wenn der umbenannte Befehl nicht in der AOF-Datei enthalten ist, oder wenn er enthalten ist, aber die AOF-Datei nicht an Slaves übertragen wurde.

      Denken Sie bitte daran, wenn Sie Befehle umbenennen möchten. Der beste Zeitpunkt zur Umbenennung eines Befehls ist dann, wenn Sie keine AOF-Persistenz nutzen. Ein anderer Zeitpunkt ist direkt nach der Installation, bevor die Anwendung bereitgestellt wird, die Redis verwendet.

      Wenn Sie AOF verwenden und mit einer Master-Slave-Installation arbeiten, sollten Sie diese Antwort von der GitHub-Frageseite des Projekts beachten. Nachfolgend eine Antwort auf die Frage des Autors:

      Die Befehle werden in der AOF protokolliert und auf die gleiche Weise, in der sie gesendet werden, an den Slave repliziert. Wenn Sie also versuchen, die AOF auf einer Instanz, die nicht die gleiche Umbenennung hat, erneut wiederzugeben, kann es zu Inkonsistenzen kommen, da der Befehl nicht ausgeführt werden kann (dasselbe gilt für Slaves).

      Daher ist es in Fällen wie diesen am besten, bei der Umbenennung sicherzustellen, dass umbenannte Befehle auf alle Instanzen in Master-Slave-Installationen angewendet werden.

      Zusammenfassung

      In diesem Tutorial haben Sie Redis installiert und konfiguriert, die korrekte Funktion Ihrer Redis-Installation überprüft und die integrierten Sicherheitsfunktionen genutzt, um sie weniger anfällig für Angriffe böswilliger Akteure zu machen.

      Denken Sie daran, dass die Sicherheitsfunktionen von Redis, die wir eingerichtet haben, sehr leicht zu umgehen sind, sobald sich jemand auf Ihrem Server angemeldet hat. Daher ist die wichtigste Sicherheitseinrichtung auf Ihrem Redis-Server Ihre Firewall (die Sie konfiguriert haben, wenn Sie in den Voraussetzungen dem Leitfaden zur Ersteinrichtung eines Servers gefolgt sind). Diese Barriere ist für böswillige Akteure nur sehr schwer zu überwinden.



      Source link

      So sichern Sie Apache mit Let’s Encrypt unter Ubuntu 20.04


      Einführung

      Let’s Encrypt ist eine Zertifizierungsstelle (Certificate Authority, CA), die das Abrufen und Installieren von kostenlosen TLS-/SSL-Zertifikaten erleichtert und so verschlüsseltes HTTPS auf Webservern ermöglicht. Es vereinfacht den Prozess, indem ein Software-Client, Certbot, bereitgestellt wird, der versucht, die meisten (wenn nicht alle) der erforderlichen Schritte zu automatisieren. Derzeit ist der gesamte Prozess zum Abrufen und Installieren eines Zertifikats sowohl auf Apache als auch auf Nginx vollständig automatisiert.

      In diesem Leitfaden verwenden wir Certbot, um ein kostenloses SSL-Zertifikat für Apache unter Ubuntu 20.04 zu erhalten, und stellen sicher, dass dieses Zertifikat so eingerichtet ist, dass es automatisch erneuert wird.

      In diesem Tutorial wird anstelle der Standardkonfigurationsdatei von Apache eine separate virtuelle Hostdatei zum Einrichten der Website verwendet, die von Let’s Encrypt gesichert wird. Wir empfehlen, neue virtuelle Apache-Hostdateien für jede auf einem Server gehostete Domäne zu erstellen, da dies dazu beiträgt, häufige Fehler zu vermeiden und die Standardkonfigurationsdateien als Fallback-Setup beizubehalten.

      Voraussetzungen

      Um dieser Anleitung zu folgen, benötigen Sie:

      • Einen Ubuntu 20.04-Server, der gemäß dem Tutorial Ersteinrichtung des Servers für Ubuntu 20.04 eingerichtet wurde, einschließlich eines sudo non-root users und einer Firewall.

      • Einen vollständig registrierten Domänennamen. In diesem Tutorial wird your_domain durchgehend als Beispiel verwendet. Sie können einen Domänennamen unter Namecheap günstig erwerben oder einen kostenlosen von Freenom herunterladen,. oder einfach die Domänenregistrierngsstelle Ihrer Wahl verwenden.

      • Die beiden folgenden DNS-Einträge wurden für Ihren Server eingerichtet. Sie finden in dieser Einführung in DigitalOcean DNS Details dazu, wie Sie sie hinzufügen können.

        • Einen A-Datensatz mit your-domain, der auf die öffentliche IP-Adresse Ihres Servers verweist.
        • Einen A-Datensatz mit your-domain, der auf die öffentliche IP-Adresse Ihres Servers verweist.
      • Apache gemäß Installieren von Apache unter Ubuntu 20.04 installiert. Stellen Sie sicher, dass Sie eine virtuelle Hostdatei für Ihre Domäne haben. In diesem Tutorial wird /etc/apache2/sites-available/your_domain.conf als Beispiel verwendet.

      Schritt 1 — Installieren von Certbot

      Um ein SSL-Zertifikat mit Let’s Encrypt zu erhalten, müssen wir zuerst die Certbot-Software auf Ihrem Server installieren. Wir werden dafür die Standard-Ubuntu-Paket-Repositorys verwenden.

      Wir benötigen zwei Pakete: certbot und python3-certbot-apache. Letzteres ist ein Plugin, das Certbot in Apache integriert und ermöglicht, das Abrufen eines Zertifikats und das Konfigurieren von HTTPS auf Ihrem Webserver mit einem einzigen Befehl zu automatisieren.

      • sudo apt install certbot python3-certbot-apache

      Außerdem werden Sie zur Bestätigung der Installation aufgefordert, indem Sie Y und dann ENTER drücken.

      Certbot ist jetzt auf Ihrem Server installiert. Im nächsten Schritt verifizieren wir die Konfiguration von Apache, um sicherzustellen, dass Ihr virtueller Host angemessen festgelegt ist. Dadurch wird sichergestellt, dass das Certbot-Client-Skript Ihre Domänen erkennen und Ihren Webserver so konfigurieren kann, dass Ihr neu generiertes SSL-Zertifikat automatisch verwendet wird.

      Schritt 2 — Überprüfen Ihrer Apache Virtual Host-Konfiguration

      Um SSL für Ihren Webserver automatisch abrufen und konfigurieren zu können, muss Certbot den richtigen virtuellen Host in Ihren Apache-Konfigurationsdateien finden. Ihre Serverdomänennamen werden aus den Anweisungen ServerName und ServerAlias abgerufen, die in Ihrem VirtualHost-Konfigurationsblock definiert sind.

      Wenn Sie den Schritt zum Einrichten des virtuellen Hosts im Tutorial zur Apache-Installation ausgeführt haben, sollten Sie einen VirtualHost-Block für Ihre Domäne unter /etc/apache2/sites-available/your_domain.conf mit dem ServerName und auch den ServerAlias-Anweisungen, die bereits entsprechend festgelegt wurden, einrichten.

      Um dies zu überprüfen, öffnen Sie die virtuelle Hostdatei für Ihre Domäne mit nano oder Ihrem bevorzugten Texteditor:

      • sudo nano /etc/apache2/sites-available/your_domain.conf

      Suchen Sie die bestehenden Zeilen ServerName und ServerAlias. Sie sollten wie folgt aussehen:

      /etc/apache2/sites-available/your_domain.conf

      ...
      ServerName your_domain
      ServerAlias www.your_domain
      ...
      

      Wenn Sie Ihren ServerName und Ihre ServerAlias bereits so eingerichtet haben, können Sie Ihren Texteditor beenden und mit dem nächsten Schritt fortfahren. Wenn Sie nano verwenden, können Sie zum Beenden STRG+X drücken, dann Y und ENTER, um zu bestätigen.

      Wenn Ihre aktuelle virtuelle Hostkonfiguration nicht dem Beispiel entspricht, aktualisieren Sie sie entsprechend. Wenn Sie fertig sind, speichern Sie die Datei und beenden Sie den Editor. Führen Sie dann den folgenden Befehl aus, um Ihre Änderungen zu validieren:

      • sudo apache2ctl configtest

      Sie sollten eine Syntax OK als Antwort erhalten. Wenn Sie einen Fehler erhalten, öffnen Sie die virtuelle Hostdatei und überprüfen Sie sie auf Schreibfehler oder fehlende Zeichen. Sobald die Syntax Ihrer Konfigurationsdatei korrekt ist, laden Sie Apache neu, sodass die Änderungen wirksam werden:

      • sudo systemctl reload apache2

      Mit diesen Änderungen kann Certbot den richtigen VirtualHost-Block finden und ihn aktualisieren.

      Als Nächstes aktualisieren wir die Firewall, um den HTTPS-Datenverkehr zu ermöglichen.

      Schritt 3 — Zulassen von HTTPS durch die Firewall

      Wenn Sie die UFW-Firewall aktiviert haben, wie in den erforderlichen Anleitungen empfohlen, müssen Sie die Einstellungen anpassen, um den HTTPS-Datenverkehr zuzulassen. Bei der Installation registriert Apache einige verschiedene UFW-Anwendungsprofile. Wir können das Profil Apache Full nutzen, um sowohl HTTP- als auch HTTPS-Datenverkehr auf Ihrem Server zuzulassen.

      Um zu verifizieren, welche Art von Datenverkehr derzeit auf Ihrem Server erlaubt ist, können Sie Folgendes verwenden:

      Wenn Sie einem unserer Apache-Installationsleitfäden gefolgt sind, sollte Ihre Ausgabe ungefähr so aussehen, was bedeutet, dass derzeit nur HTTP-Datenverkehr auf Port 80 zulässig ist:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Um zusätzlich den HTTPS-Datenverkehr einzulassen, lassen Sie das Profil „Apache Full“ zu und löschen Sie das redundante Profil „Apache“:

      • sudo ufw allow 'Apache Full'
      • sudo ufw delete allow 'Apache'

      Ihr Status sieht nun wie folgt aus:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6)

      Sie können nun Certbot ausführen und Ihre Zertifikate abrufen.

      Schritt 4 — Abrufen eines SSL-Zertifikats

      Certbot bietet eine Vielzahl von Möglichkeiten, um SSL-Zertifikate über Plugins zu erhalten. Das Apache-Plugin kümmert sich um die Neukonfiguration von Apache und das Neuladen der Konfiguration bei Bedarf. Geben Sie Folgendes ein, um dieses Plugin zu verwenden:

      In diesem Skript müssen Sie eine Reihe von Fragen beantworten, um Ihr SSL-Zertifikat zu konfigurieren. Zunächst werden Sie nach einer gültigen E-Mail-Adresse gefragt. Diese E-Mail wird für Erneuerungsbenachrichtigungen und Sicherheitshinweise verwendet:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): you@your_domain

      Nach dem Bereitstellen einer gültigen E-Mail-Adresse drücken Sie ENTER, um mit dem nächsten Schritt fortzufahren. Sie werden dann aufgefordert, zu bestätigen, ob Sie den Nutzungsbedingungen von Let’s Encrypt zustimmen. Sie können dies bestätigen, indem Sie A drücken und dann ENTER:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Please read the Terms of Service at
      https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
      agree in order to register with the ACME server at
      https://acme-v02.api.letsencrypt.org/directory
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (A)gree/(C)ancel: A
      

      Als Nächstes werden Sie gefragt, ob Sie Ihre E-Mail mit der Electronic Frontier Foundation teilen möchten, um Nachrichten und andere Informationen zu erhalten. Wenn Sie ihren Inhalt nicht abonnieren möchten, geben Sie N ein. Andernfalls geben Sie Y ein. Drücken Sie anschließend ENTER, um mit dem nächsten Schritt fortzufahren.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Would you be willing to share your email address with the Electronic Frontier
      Foundation, a founding partner of the Let's Encrypt project and the non-profit
      organization that develops Certbot? We'd like to send you email about our work
      encrypting the web, EFF news, campaigns, and ways to support digital freedom.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (Y)es/(N)o: N
      

      Im nächsten Schritt werden Sie aufgefordert, Certbot darüber zu informieren, für welche Domänen Sie HTTPS aktivieren möchten. Die aufgelisteten Domänennamen werden automatisch aus Ihrer Konfiguration des virtuellen Apache-Hosts abgerufen. Aus diesem Grund müssen Sie sicherstellen, dass auf Ihrem virtuellen Host die richtigen Einstellungen für ServerName und ServerAlias konfiguriert sind. Wenn Sie HTTPS für alle aufgelisteten Domänennamen aktivieren möchten (empfohlen), können Sie die Eingabeaufforderung leer lassen und ENTER drücken, um fortzufahren. Wählen Sie andernfalls die Domänen aus, für die Sie HTTPS aktivieren möchten, indem Sie die entsprechende Nummer durch Kommas und/oder Leerzeichen getrennt auflisten und dann ENTER drücken.

      Which names would you like to activate HTTPS for?
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      1: your_domain
      2: www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Select the appropriate numbers separated by commas and/or spaces, or leave input
      blank to select all options shown (Enter 'c' to cancel):
      

      Die Ausgabe sieht dann so aus:

      Obtaining a new certificate
      Performing the following challenges:
      http-01 challenge for your_domain
      http-01 challenge for www.your_domain
      Enabled Apache rewrite module
      Waiting for verification...
      Cleaning up challenges
      Created an SSL vhost at /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabled Apache socache_shmcb module
      Enabled Apache ssl module
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabling available site: /etc/apache2/sites-available/your_domain-le-ssl.conf
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      

      Als Nächstes werden Sie aufgefordert, auszuwählen, ob der HTTP-Datenverkehr an HTTPS umgeleitet werden soll. In der Praxis bedeutet dies, dass jemand, der Ihre Website über unverschlüsselte Kanäle (HTTP) besucht, automatisch an die HTTPS-Adresse Ihrer Website umgeleitet wird. Wählen Sie 2, um die Umleitung zu aktivieren, oder 1, wenn Sie sowohl HTTP als auch HTTPS als separate Methoden für den Zugriff auf Ihre Website beibehalten möchten.

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      1: No redirect - Make no further changes to the webserver configuration.
      2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
      new sites, or if you're confident your site works on HTTPS. You can undo this
      change by editing your web server's configuration.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
      
      

      Nach diesem Schritt ist die Konfiguration von Certbot abgeschlossen, und Sie erhalten die letzten Anmerkungen zu Ihrem neuen Zertifikat, wo sich die generierten Dateien befinden und wie Sie Ihre Konfiguration mit einem externen Tool testen können, das die Authentizität Ihres Zertifikats analysiert:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Congratulations! You have successfully enabled https://your_domain and
      https://www.your_domain
      
      You should test your configuration at:
      https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
      https://www.ssllabs.com/ssltest/analyze.html?d=www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      
      IMPORTANT NOTES:
       - Congratulations! Your certificate and chain have been saved at:
         /etc/letsencrypt/live/your_domain/fullchain.pem
         Your key file has been saved at:
         /etc/letsencrypt/live/your_domain/privkey.pem
         Your cert will expire on 2020-07-27. To obtain a new or tweaked
         version of this certificate in the future, simply run certbot again
         with the "certonly" option. To non-interactively renew *all* of
         your certificates, run "certbot renew"
       - Your account credentials have been saved in your Certbot
         configuration directory at /etc/letsencrypt. You should make a
         secure backup of this folder now. This configuration directory will
         also contain certificates and private keys obtained by Certbot so
         making regular backups of this folder is ideal.
       - If you like Certbot, please consider supporting our work by:
      
         Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
         Donating to EFF:                    https://eff.org/donate-le
      
      

      Ihr Zertifikat ist nun installiert und in die Konfiguration von Apache geladen. Versuchen Sie, Ihre Website mit https:// neu zu laden und beachten Sie den Sicherheitsindikator Ihres Browsers. Er sollte darauf hinweisen, dass Ihre Website ordnungsgemäß gesichert ist, normalerweise durch Einfügen eines Schlosssymbols in die Adressleiste.

      Mit dem SSL Labs Server-Test können Sie die Note Ihres Zertifikats überprüfen und detaillierte Informationen dazu aus der Sicht eines externen Dienstes abrufen.

      Im nächsten und letzten Schritt testen wir die automatische Erneuerungsfunktion von Certbot, die garantiert, dass Ihr Zertifikat vor dem Ablaufdatum automatisch erneuert wird.

      Schritt 5 – Überprüfen der automatischen Erneuerung von Certbot

      Zertifikate von Let’s Encrypt sind nur neunzig Tage gültig. Dies soll Benutzer dazu ermutigen, ihren Prozess zur Erneuerung von Zertifikaten zu automatisieren und sicherzustellen, dass missbrauchte Zertifikate oder gestohlene Schlüssel eher früher als später ablaufen.

      Das von uns installierte certbot-Paket kümmert sich um Erneuerungen, indem es ein Erneuerungsskript in /etc/cron.d einfügt, das von einem systemctl-Dienst namens certbot.timer verwaltet wird. Dieses Skript wird zweimal pro Tag ausgeführt und erneuert automatisch alle Zertifikate, die innerhalb von dreißig Tagen ablaufen.

      Um den Status dieses Dienstes zu überprüfen und sicherzustellen, dass er aktiv ist und ausgeführt wird, können Sie Folgendes verwenden:

      • sudo systemctl status certbot.timer

      Sie sehen eine Ausgabe, die dieser ähnelt:

      Output

      ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-04-28 17:57:48 UTC; 17h ago Trigger: Wed 2020-04-29 23:50:31 UTC; 12h left Triggers: ● certbot.service Apr 28 17:57:48 fine-turtle systemd[1]: Started Run certbot twice daily.

      Um den Erneuerungsprozess zu testen, können Sie mit certbot einen Probelauf durchführen:

      • sudo certbot renew --dry-run

      Wenn Sie keine Fehler sehen, sind Sie fertig. Bei Bedarf erneuert Certbot Ihre Zertifikate und lädt Apache neu, um die Änderungen zu übernehmen. Wenn der automatische Erneuerungsprozess jemals fehlschlägt, sendet Let’s Encrypt eine Nachricht an die von Ihnen angegebene E-Mail und warnt Sie, wenn Ihr Zertifikat bald abläuft.

      Zusammenfassung

      In diesem Lernprogramm haben Sie den Let’s Encrypt-Client Certbot installiert, ein SSL-Zertifikat für Ihre Domäne konfiguriert und installiert und bestätigt, dass der automatische Erneuerungsdienst von Certbot in systemctl aktiv ist. Wenn Sie weitere Fragen zur Verwendung von Certbot haben, ist die Dokumentation ein guter Ausgangspunkt.



      Source link