So sichern Sie Nginx mit Let’s Encrypt unter Debian 8

Einführung

Let’s Encrypt ist eine neue Zertifizierungsstelle (Certificate Authority, CA), mit der auf einfache Weise kostenlose TLS / SSL-Zertifikate abgerufen und installiert werden können, wodurch verschlüsseltes HTTPS auf Webservern ermöglicht wird. Es vereinfacht den Prozess, indem ein Software-Client, "+ certbot " (zuvor " letsencrypt +" genannt), bereitgestellt wird, der versucht, die meisten (wenn nicht alle) der erforderlichen Schritte zu automatisieren. Gegenwärtig ist der gesamte Vorgang zum Abrufen und Installieren eines Zertifikats nur auf Apache-Webservern vollständig automatisiert. Mit Let’s Encrypt können Sie jedoch auf einfache Weise ein kostenloses SSL-Zertifikat erhalten, das unabhängig von der von Ihnen gewählten Webserver-Software manuell installiert werden kann.

In diesem Tutorial zeigen wir Ihnen, wie Sie mit Let’s Encrypt ein kostenloses SSL-Zertifikat erhalten und mit Nginx unter Debian 8 verwenden können. Wir zeigen Ihnen auch, wie Sie Ihr SSL-Zertifikat automatisch erneuern können. Wenn Sie einen anderen Webserver verwenden, lesen Sie einfach die Dokumentation Ihres Webservers, um zu erfahren, wie Sie das Zertifikat mit Ihrem Setup verwenden.

image: https://assets.digitalocean.com/articles/letsencrypt/nginx-letsencrypt.png [Nginx mit Verschlüsselung des TLS / SSL-Zertifikats und automatischer Verlängerung]

Voraussetzungen

Bevor Sie diesem Tutorial folgen, benötigen Sie einige Dinge.

Sie sollten einen Debian 8-Server mit einem Nicht-Root-Benutzer haben, der die Berechtigung "+ sudo +" besitzt. Sie können lernen, wie Sie ein solches Benutzerkonto einrichten, indem Sie unserem initial server setup for Debian 8 tutorial folgen.

Wenn Sie Nginx noch nicht auf Ihrem Server installiert haben, folgen Sie dazu this guide.

Sie müssen den registrierten Domainnamen besitzen oder kontrollieren, mit dem Sie das Zertifikat verwenden möchten. Wenn Sie noch keinen registrierten Domainnamen haben, können Sie einen bei einem der vielen Domainnamen-Registrare registrieren (z. Namecheap, GoDaddy usw.).

Wenn Sie dies noch nicht getan haben, müssen Sie einen * A Record * erstellen, der Ihre Domain auf die öffentliche IP-Adresse Ihres Servers verweist. Wenn Sie den DNS von DigitalOcean verwenden, können Sie https://www.digitalocean.com/community folgen / tutorials / wie-ein-host-name-mit-digitalocean-eingerichtet wird [diese anleitung]). Dies ist erforderlich, da Let’s Encrypt überprüft, ob Sie die Domäne besitzen, für die ein Zertifikat ausgestellt wird. Wenn Sie beispielsweise ein Zertifikat für "+ example.com " erhalten möchten, muss diese Domain auf Ihren Server aufgelöst werden, damit der Überprüfungsprozess funktioniert. Unser Setup verwendet " example.com " und " www.example.com +" als Domainnamen, daher sind * beide DNS-Einträge erforderlich *.

Sobald Sie alle Voraussetzungen aus dem Weg geräumt haben, fahren Sie mit der Installation der Let’s Encrypt-Clientsoftware fort.

Schritt 1: Installieren Sie Certbot, den Let’s Encrypt Client

Der erste Schritt zur Verwendung von Let’s Encrypt zum Abrufen eines SSL-Zertifikats besteht darin, den "+ certbot +" Let’s Encrypt-Client auf Ihrem Server zu installieren.

Das "+ certbot " - Paket war nicht verfügbar, als Debian 8 veröffentlicht wurde. Um auf das " certbot +" - Paket zugreifen zu können, müssen wir das Jessie-Backports-Repository auf unserem Server aktivieren. Dieses Repository kann verwendet werden, um neuere Softwareversionen als die in den Stable-Repositorys enthaltenen zu installieren.

Fügen Sie das Backports-Repository zu Ihrem Server hinzu, indem Sie Folgendes eingeben:

echo 'deb http://ftp.debian.org/debian jessie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list

Aktualisieren Sie nach dem Hinzufügen des neuen Repositorys den Paketindex "+ apt +", um Informationen zu den neuen Paketen herunterzuladen:

sudo apt-get update

Sobald das Repository aktualisiert ist, können Sie das Paket + certbot + installieren, indem Sie auf das Backports-Repository abzielen:

sudo apt-get install certbot -t jessie-backports

Der + certbot + Client sollte nun einsatzbereit sein.

Schritt 2: Besorgen Sie sich ein SSL-Zertifikat

Let’s Encrypt bietet verschiedene Möglichkeiten, SSL-Zertifikate über verschiedene Plugins abzurufen. Im Gegensatz zum Apache-Plugin, das in a different tutorial behandelt wird, Die meisten Plugins helfen Ihnen nur bei der Beschaffung eines Zertifikats, für dessen Verwendung Sie Ihren Webserver manuell konfigurieren müssen. Plugins, die nur Zertifikate erhalten und diese nicht installieren, werden als "Authentifikatoren" bezeichnet, da sie zur Authentifizierung verwendet werden, ob einem Server ein Zertifikat ausgestellt werden soll.

Wir zeigen Ihnen, wie Sie mit dem * Webroot * -Plugin ein SSL-Zertifikat erhalten.

Verwendung des Webroot-Plugins

Das Webroot-Plugin legt eine spezielle Datei im Verzeichnis "+ /. Well-known " Ihres Dokumentenstamms ab, die (über Ihren Webserver) vom Let's Encrypt-Dienst zur Validierung geöffnet werden kann. Abhängig von Ihrer Konfiguration müssen Sie möglicherweise den Zugriff auf das bekannte Verzeichnis " /. Well-known +" explizit zulassen.

Wenn Sie Nginx noch nicht installiert haben, folgen Sie dazu this tutorial. Fahren Sie unten fort, wenn Sie fertig sind.

Um sicherzustellen, dass das Verzeichnis zur Validierung für Let’s Encrypt zugänglich ist, nehmen wir eine schnelle Änderung an unserer Nginx-Konfiguration vor. Standardmäßig befindet es sich unter "+ / etc / nginx / sites-available / default ". Wir werden ` nano` verwenden, um es zu bearbeiten:

sudo nano /etc/nginx/sites-available/default

Fügen Sie im Serverblock diesen Standortblock hinzu:

Zum SSL-Serverblock hinzufügen

       location ~ /.well-known {
               allow all;
       }

Sie möchten auch nachsehen, auf was Ihr Dokumentenstamm festgelegt ist, indem Sie nach der Direktive "+ root " suchen, da der Pfad für die Verwendung des Webroot-Plugins erforderlich ist. Wenn Sie die Standardkonfigurationsdatei verwenden, lautet das Stammverzeichnis " / var / www / html".

Speichern und schließen.

Überprüfen Sie Ihre Konfiguration auf Syntaxfehler:

sudo nginx -t
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Wenn keine Fehler gefunden werden, starten Sie Nginx mit dem folgenden Befehl neu:

sudo systemctl restart nginx

Nachdem wir unseren "+ webroot-path " kennen, können wir mit dem Webroot-Plugin ein SSL-Zertifikat mit diesen Befehlen anfordern. Hier geben wir auch unsere Domain-Namen mit der Option " -d " an. Wenn Sie möchten, dass ein einzelnes Zertifikat mit mehreren Domain-Namen funktioniert (z. Stellen Sie sicher, dass " example.com " und " www.example.com +") alle einschließen. Stellen Sie außerdem sicher, dass Sie die markierten Teile durch den entsprechenden Webroot-Pfad und die Domainnamen ersetzen:

sudo certbot certonly -a webroot --webroot-path= -d  -d

Nach der Initialisierung von "+ certbot +" werden Sie aufgefordert, Ihre E-Mail-Adresse einzugeben und den Nutzungsbedingungen von Let’s Encrypt zuzustimmen. Danach wird die Herausforderung ausgeführt. Wenn alles erfolgreich war, sollten Sie eine Ausgabenachricht sehen, die ungefähr so ​​aussieht:

Output:IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
  fullchain.pem. Your cert
  will expire on . To obtain a new or tweaked version of
  this certificate in the future, simply run certbot again. To
  non-interactively renew *all* of your certificates, run "certbot
  renew"
- If you lose your account credentials, you can recover through
  e-mails sent to [email protected].
- 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

Sie möchten den Pfad und das Ablaufdatum Ihres Zertifikats notieren, die in der Beispielausgabe hervorgehoben wurden.

Zertifikatsdateien

Nach Erhalt des Zertifikats verfügen Sie über die folgenden PEM-codierten Dateien:

  • * cert.pem: * Das Zertifikat Ihrer Domain

  • * chain.pem: * Das Kettenzertifikat Let’s Encrypt

  • * fullchain.pem: * + cert.pem + und + chain.pem + kombiniert

  • * privkey.pem: * Der private Schlüssel Ihres Zertifikats

Es ist wichtig, dass Sie den Speicherort der soeben erstellten Zertifikatdateien kennen, damit Sie sie in Ihrer Webserverkonfiguration verwenden können. Die Dateien selbst befinden sich in einem Unterverzeichnis in + / etc / letsencrypt / archive +. Mit Let’s Encrypt werden jedoch symbolische Links zu den neuesten Zertifikatsdateien im Verzeichnis "+ / etc / letsencrypt / live / +" erstellt. Da die Links immer auf die neuesten Zertifikatdateien verweisen, sollten Sie diesen Pfad verwenden, um auf Ihre Zertifikatdateien zu verweisen.

Sie können überprüfen, ob die Dateien vorhanden sind, indem Sie diesen Befehl ausführen (in Ihrem Domain-Namen ersetzen):

sudo ls -l /etc/letsencrypt/live/

Die Ausgabe sollte aus den vier zuvor genannten Zertifikatdateien bestehen. In Kürze konfigurieren Sie Ihren Webserver so, dass "+ fullchain.pem " als Zertifikatsdatei und " privkey.pem +" als Zertifikatsschlüsseldatei verwendet wird.

Generieren Sie eine starke Diffie-Hellman-Gruppe

Um die Sicherheit weiter zu erhöhen, sollten Sie auch eine starke Diffie-Hellman-Gruppe generieren. Verwenden Sie diesen Befehl, um eine 2048-Bit-Gruppe zu generieren:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Dies kann einige Minuten dauern, aber wenn dies erledigt ist, haben Sie eine starke DH-Gruppe unter "+ /etc/ssl/certs/dhparam.pem +".

Schritt 3: Konfigurieren von TLS / SSL auf dem Webserver (Nginx)

Nachdem Sie über ein SSL-Zertifikat verfügen, müssen Sie Ihren Nginx-Webserver für die Verwendung konfigurieren.

Wir werden einige Anpassungen an unserer Konfiguration vornehmen:

  1. Wir erstellen ein Konfigurations-Snippet, das den Speicherort unseres SSL-Schlüssels und der Zertifikatsdatei enthält.

  2. Wir werden ein Konfigurations-Snippet mit starken SSL-Einstellungen erstellen, das in Zukunft für alle Zertifikate verwendet werden kann.

  3. Wir werden die Nginx-Serverblöcke anpassen, um SSL-Anforderungen zu verarbeiten, und die beiden obigen Ausschnitte verwenden.

Diese Methode zur Konfiguration von Nginx ermöglicht es uns, saubere Serverblöcke zu erhalten und allgemeine Konfigurationssegmente in wiederverwendbare Module zu unterteilen.

Erstellen Sie ein Konfigurations-Snippet, das auf den SSL-Schlüssel und das Zertifikat verweist

Zuerst erstellen wir ein neues Nginx-Konfigurations-Snippet im Verzeichnis "+ / etc / nginx / snippets +".

Um den Zweck dieser Datei richtig zu unterscheiden, nennen wir sie "+ ssl- ", gefolgt von unserem Domainnamen, gefolgt von " .conf +" am Ende:

sudo nano /etc/nginx/snippets/ssl-.conf

In dieser Datei müssen wir nur die Direktive "+ ssl_certificate" auf Ihre Zertifikatsdatei und die Direktive "+ ssl_certificate_key" auf den zugehörigen Schlüssel setzen. In unserem Fall sieht das so aus:

/etc/nginx/snippets/ssl-example.com.conf

ssl_certificate /etc/letsencrypt/live//fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live//privkey.pem;

Wenn Sie diese Zeilen hinzugefügt haben, speichern und schließen Sie die Datei.

Erstellen Sie ein Konfigurations-Snippet mit starken Verschlüsselungseinstellungen

Als Nächstes erstellen wir ein weiteres Snippet, das einige SSL-Einstellungen definiert. Dies wird Nginx mit einer starken SSL-Verschlüsselungssuite einrichten und einige erweiterte Funktionen aktivieren, die dazu beitragen, unseren Server sicher zu halten.

Die von uns festgelegten Parameter können in zukünftigen Nginx-Konfigurationen wiederverwendet werden, daher geben wir der Datei einen generischen Namen:

sudo nano /etc/nginx/snippets/ssl-params.conf

Um Nginx SSL sicher einzurichten, verwenden wir die Empfehlungen von Remy van Elst auf der Website https://cipherli.st [Cipherli.st]. Diese Website wurde entwickelt, um benutzerfreundliche Verschlüsselungseinstellungen für gängige Software bereitzustellen. Weitere Informationen zu seinen Entscheidungen bezüglich der Nginx-Auswahlmöglichkeiten finden Sie unter hier.

Für unsere Zwecke können wir die bereitgestellten Einstellungen vollständig kopieren. Wir müssen nur ein paar kleine Änderungen vornehmen.

Zunächst werden wir unseren bevorzugten DNS-Resolver für Upstream-Anforderungen hinzufügen. Für diesen Leitfaden verwenden wir die von Google. Wir werden auch vorgehen und die Einstellung + ssl_dhparam + so setzen, dass sie auf die Diffie-Hellman-Datei verweist, die wir zuvor generiert haben.

Schließlich sollten Sie sich einen Moment Zeit nehmen, um sich über HTTP Strict Transport Security (HSTS) und insbesondere über https://hstspreload.appspot.com/ [zu informieren. "Preload" -Funktionalität. Das Vorladen von HSTS bietet erhöhte Sicherheit, kann jedoch weitreichende Konsequenzen haben, wenn es versehentlich oder falsch aktiviert wird. In diesem Handbuch werden die Einstellungen nicht vorab geladen, aber Sie können dies ändern, wenn Sie sicher sind, dass Sie die Auswirkungen verstehen:

/etc/nginx/snippets/ssl-params.conf

# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver  valid=300s;
resolver_timeout 5s;


add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Passen Sie die Nginx-Konfiguration an, um SSL zu verwenden

Nachdem wir unsere Snippets haben, können wir unsere Nginx-Konfiguration anpassen, um SSL zu aktivieren.

In diesem Handbuch wird davon ausgegangen, dass Sie die Standard-Serverblockdatei im Verzeichnis "+ / etc / nginx / sites-available +" verwenden. Wenn Sie eine andere Serverblockdatei verwenden, ersetzen Sie deren Namen in den folgenden Befehlen.

Bevor wir fortfahren, sichern wir zunächst unsere aktuelle Server-Blockdatei:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

Öffnen Sie nun die Server-Blockdatei, um Anpassungen vorzunehmen:

sudo nano /etc/nginx/sites-available/default

Im Inneren beginnt Ihr Serverblock wahrscheinlich so:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;

   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

Diese Konfiguration wird so geändert, dass unverschlüsselte HTTP-Anforderungen automatisch zu verschlüsseltem HTTPS umgeleitet werden. Dies bietet die beste Sicherheit für unsere Websites. Wenn Sie sowohl HTTP- als auch HTTPS-Datenverkehr zulassen möchten, verwenden Sie die folgende alternative Konfiguration.

Wir werden die Konfiguration in zwei separate Blöcke aufteilen. Nach den beiden ersten Anwei- Wir richten dann eine Umleitung zum zweiten Serverblock ein, den wir erstellen. Anschließend schließen wir diesen kurzen Block:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name  www.;



   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

Als nächstes müssen wir einen neuen Serverblock direkt darunter starten, um die verbleibende Konfiguration aufzunehmen. Wir können die beiden "+ listen +" - Direktiven, die Port 443 verwenden, auskommentieren. Danach müssen wir nur noch die zwei Snippet-Dateien einfügen, die wir erstellt haben:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name  www.;
   return 301 https://$server_name$request_uri;
}



   # SSL configuration






   . . .

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

(Alternative Konfiguration) HTTP- und HTTPS-Verkehr zulassen

Wenn Sie sowohl verschlüsselten als auch unverschlüsselten Inhalt zulassen möchten oder müssen, müssen Sie Nginx etwas anders konfigurieren. Dies wird im Allgemeinen nicht empfohlen, wenn dies vermieden werden kann. In einigen Situationen kann dies jedoch erforderlich sein. Grundsätzlich komprimieren wir einfach die zwei separaten Serverblöcke zu einem Block und entfernen die Umleitung:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;



   server_name  www.;



   . . .

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Schritt 4: Passen Sie die Firewall an

Wenn Sie eine Firewall aktiviert haben, müssen Sie die Einstellungen anpassen, um SSL-Datenverkehr zuzulassen. Das erforderliche Verfahren hängt von der verwendeten Firewall-Software ab. Wenn Sie derzeit keine Firewall konfiguriert haben, können Sie vorwärts springen.

UFW

Wenn Sie * ufw * verwenden, können Sie die aktuelle Einstellung anzeigen, indem Sie Folgendes eingeben:

sudo ufw status

Es wird wahrscheinlich so aussehen, was bedeutet, dass nur HTTP-Verkehr zum Webserver erlaubt ist:

OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW                        ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW (v6)                   ALLOW       Anywhere (v6)

Um zusätzlich HTTPS-Verkehr zuzulassen, können wir das Profil "WWW Full" zulassen und dann die redundante Berechtigung "WWW" löschen:

sudo ufw allow 'WWW Full'
sudo ufw delete allow 'WWW'

Ihr Status sollte jetzt so aussehen:

sudo ufw status
OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)

HTTPS-Anforderungen sollten jetzt von Ihrem Server akzeptiert werden.

IPTables

Wenn Sie "+ iptables +" verwenden, können Sie die aktuellen Regeln anzeigen, indem Sie Folgendes eingeben:

sudo iptables -S

Wenn Sie Regeln aktiviert haben, werden diese angezeigt. Eine Beispielkonfiguration könnte folgendermaßen aussehen:

Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Die zum Öffnen des SSL-Datenverkehrs erforderlichen Befehle hängen von Ihren aktuellen Regeln ab. Für einen grundlegenden Regelsatz wie den oben genannten können Sie den SSL-Zugriff hinzufügen, indem Sie Folgendes eingeben:

sudo iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Wenn wir uns die Firewall-Regeln noch einmal ansehen, sollten wir die neue Regel sehen:

sudo iptables -S
Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Wenn Sie ein Programm verwenden, um "+ iptables +" - Regeln beim Booten automatisch anzuwenden, sollten Sie sicherstellen, dass Sie Ihre Konfiguration mit der neuen Regel aktualisieren.

Schritt 5: Aktivieren der Änderungen in Nginx

Nachdem wir die Änderungen vorgenommen und die Firewall angepasst haben, können wir Nginx neu starten, um die neuen Änderungen zu implementieren.

Zuerst sollten wir überprüfen, ob unsere Dateien Syntaxfehler enthalten. Wir können dies tun, indem wir Folgendes eingeben:

sudo nginx -t

Wenn alles erfolgreich ist, erhalten Sie ein Ergebnis, das so aussieht:

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Wenn Ihre Ausgabe mit der obigen übereinstimmt, enthält Ihre Konfigurationsdatei keine Syntaxfehler. Wir können Nginx problemlos neu starten, um unsere Änderungen zu implementieren:

sudo systemctl restart nginx

Das TLS / SSL-Zertifikat von Let’s Encrypt ist nun vorhanden und die Firewall lässt den Datenverkehr auf Port 80 und 443 zu. Zu diesem Zeitpunkt sollten Sie testen, ob das TLS / SSL-Zertifikat funktioniert, indem Sie Ihre Domain über HTTPS in einem Webbrowser aufrufen.

Sie können den Qualys SSL Labs-Bericht verwenden, um zu sehen, wie Ihre Serverkonfiguration abschneidet:

In a web browser:https://www.ssllabs.com/ssltest/analyze.html?d=

Dies kann einige Minuten dauern. Das SSL-Setup in diesem Handbuch sollte mindestens eine * A * -Bewertung enthalten.

Schritt 6: Automatische Verlängerung einrichten

"Zertifikate verschlüsseln" hat eine Gültigkeit von 90 Tagen. Es wird jedoch empfohlen, die Zertifikate alle 60 Tage zu erneuern, um eine Fehlerquote zu erzielen. Zum jetzigen Zeitpunkt ist die automatische Erneuerung für den Client selbst noch nicht verfügbar. Sie können Ihre Zertifikate jedoch manuell erneuern, indem Sie den Let’s Encrypt-Client mit der Option "+ renew +" ausführen.

Führen Sie den folgenden Befehl aus, um den Erneuerungsprozess für alle installierten Domänen auszulösen:

sudo certbot renew

Da wir das Zertifikat kürzlich installiert haben, überprüft der Befehl nur das Ablaufdatum und gibt eine Meldung aus, dass das Zertifikat noch nicht erneuert werden muss. Die Ausgabe sollte ungefähr so ​​aussehen:

Output:Saving debug log to /var/log/letsencrypt/.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal

The following certs are not due for renewal yet:
 /etc/letsencrypt/live//fullchain.pem (skipped)
No renewals were attempted.

Beachten Sie, dass, wenn Sie ein gebündeltes Zertifikat mit mehreren Domänen erstellt haben, in der Ausgabe nur der Basisdomänenname angezeigt wird. Die Verlängerung sollte jedoch für alle in diesem Zertifikat enthaltenen Domänen gültig sein.

Eine praktische Möglichkeit, um sicherzustellen, dass Ihre Zertifikate nicht veraltet sind, besteht darin, einen Cron-Job zu erstellen, der den Befehl zur automatischen Verlängerung regelmäßig für Sie ausführt. Da bei der Erneuerung zunächst nach dem Ablaufdatum gesucht wird und die Erneuerung nur ausgeführt wird, wenn das Zertifikat weniger als 30 Tage vor dem Ablaufdatum liegt, ist es sicher, einen Cron-Job zu erstellen, der beispielsweise jede Woche oder sogar jeden Tag ausgeführt wird.

Bearbeiten Sie die crontab, um einen neuen Job zu erstellen, der den Befehl renewal jede Woche ausführt. Führen Sie Folgendes aus, um die Crontab für den Root-Benutzer zu bearbeiten:

sudo crontab -e

Wenn Sie + crontab + zum ersten Mal verwenden, werden Sie möglicherweise aufgefordert, Ihren bevorzugten Texteditor auszuwählen. Wenn Sie keine starke Vorliebe haben, ist * nano * eine einfache Wahl.

Fügen Sie die folgenden Zeilen hinzu:

crontab entry30 2 * * * /usr/bin/certbot renew --noninteractive --renew-hook "/bin/systemctl reload nginx" >> /var/log/le-renew.log

Speichern und schließen. Dadurch wird ein neuer Cron-Job erstellt, der jeden Tag um 2:30 Uhr den Befehl "+ certbot renew " ausführt und Nginx neu lädt, wenn ein Zertifikat erneuert wird. Die vom Befehl erzeugte Ausgabe wird an eine Protokolldatei weitergeleitet, die sich unter ` / var / log / le-renewal.log +` befindet.

Fazit

Das ist es! Ihr Webserver verwendet jetzt ein kostenloses Let’s Encrypt TLS / SSL-Zertifikat, um HTTPS-Inhalte sicher bereitzustellen.