Nginx SSL-Zertifikat und HTTPS-Umleitungsfehler

Einführung

Nginx ist ein beliebter Webserver, der viele große und stark frequentierte Websites im Internet hosten kann. Nach der Installation von Nginx akzeptiert Ihre Website standardmäßig Anfragen für HTTP-Verkehr. Dies ist nicht die sicherste Option für Ihre Website. Aus diesem Grund möchten Sie möglicherweise Ihren HTTP-Verkehr auf HTTPS umleiten, das für verschlüsselten Verkehr steht und mit einem Nginx SSL-Zertifikat verifiziert ist. Selbst mit Ressourcen wie Let’s Encrypt oder Cerbot, die den Prozess des Erwerbs eines Zertifikats automatisieren und bei der Umleitung auf HTTPS unterstützen, können dennoch Fehler mit Ihrem Nginx-Webserver auftreten.

Die Beispiele in diesem Leitfaden wurden auf einem Ubuntu 22.04-Server getestet, sollten aber auf die meisten Nginx-Installationen anwendbar sein. Die meisten dieser Fehler können innerhalb der standardisierten Konfigurationsdatei von Nginx behoben werden, obwohl Verzeichnisse und Pfade leicht abweichen können.

In diesem Tutorial erfahren Sie über häufig auftretende Fehler beim Einrichten von TLS/SSL-Zertifikaten und HTTPS-Umleitungsverbindungen für Ihren Nginx-Server. Sie lernen auch, mögliche Ursachen für diese Umleitungsfehler zu identifizieren und zu beheben.

Ihr Nginx-Fehlerprotokoll überprüfen

Die in diesem Tutorial präsentierten Fehler und Lösungen sind gängige Fälle, aber nicht erschöpfend. Aufgrund der Art von Syntaxfehlern, die die Struktur dessen, was Nginx als gültige Anweisungen erkennt, brechen, sind die folgenden Fehler nur Richtlinien für die Reaktion von Nginx. Oft kann ein Fehler in einen anderen übergehen, und ein Fehler kann symptomatisch für ein größeres oder separates Problem sein. Ihre spezifischen Umstände und die Einrichtung können variieren.

Bitte beachten Sie, dass Sie immer das Nginx-Fehlerprotokoll konsultieren können, um eine laufende Liste einzusehen:

sudo cat /var/log/nginx/error.log

Ihre Umleitungsrichtlinie für Ihren Serverblock überprüfen

Wenn Sie Probleme damit haben, dass Ihre Website nicht von HTTP auf HTTPS umleitet, kann ein Problem mit der Direktive vorliegen, die Sie in Ihrer Konfigurationsdatei eingerichtet haben. Insbesondere sollte die listen-Direktive auf den entsprechenden Port zeigen, in diesem Fall 443, was den verschlüsselten HTTPS-Verkehr kennzeichnet. Zum Kontext, wenn Sie einen Server-Domain-Block für Ihren Nginx-Webserver eingerichtet haben, kann Ihre Konfiguration folgende Struktur aufweisen:

/etc/nginx/sites-available/example.com
server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

Die Inhalte dieser Datei bieten Details zu mehreren Direktiven, aber die wichtigste, auf die Sie achten sollten, ist die listen-Direktive. Derzeit erlaubt diese Direktive nur eingehende Anfragen für Port 80, der für Nginx standardmäßig ist. Dieser Port ist auch für HTTP-Verkehr, nicht für HTTPS. Um die Umleitung von HTTP-Verkehr auf HTTPS zu ermöglichen, müssen Sie die listen-Direktive aktualisieren, um Port 443 einzubeziehen.

Ein Weg, dies effizient zu tun, ist durch das Erlangen eines TLS/SSL-Zertifikats von einer Zertifizierungsstelle (CA) wie Let’s Encrypt. Ein Nginx SSL-Zertifikatfür Ihre Website zu haben, hilft dabei, verschlüsseltes HTTPS für Webserver zu ermöglichen.

Zusätzlich ist das Erlangen und Installieren dieses Zertifikats für Nginx komplett automatisiert über einen Software-Client namens Certbot, der ein Plugin für Nginx hat. Sie können Certbot erlauben, Ihre Nginx-Konfigurationsdatei automatisch zu konfigurieren, um allen HTTP-Verkehr auf HTTPS umzuleiten und direkten HTTP-Verkehr nicht zuzulassen. Sie können dies auch manuell tun, wenn Sie es bevorzugen, und die gleichen Prinzipien gelten. Erfahren Sie mehr darüber, wie dies mit unserem Tutorial über das Sichern von Nginx mit Let’s Encrypt gemacht wird. Für die Zwecke dieses Tutorials haben wir ein Zertifikat durch Let’s Encrypt erhalten, und die Konfigurationsdatei wird folgendermaßen aktualisiert:

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

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}

server {
        if ($host = www.example.com) {
                return 301 https://$host$request_uri;
        } # managed by Certbot


        if ($host = example.com) {
                return 301 https://$host$request_uri;
        } # managed by Certbot


        listen 80;
        listen [::]:80;

        server_name example.com www.example.com;
        return 404; # managed by Certbot
}

Wenn Sie diesen Server-Domain-Block mit dem ersten Beispiel vergleichen, können Sie die Änderungen bewerten, die als Ergebnis der automatisierten Schritte von Certbot zur Einrichtung des SSL-Zertifikats gemacht wurden. Wichtiger ist, dass die listen-Direktive nun auf Port 443 zeigt, was bedeutet, dass HTTPS-Verbindungen erlaubt sind. Das Zertifikat und der Schlüssel, die durch Certbot über Let’s Encrypt generiert wurden, sind nun auch mit Ihrem Serverblock verbunden.

Zusätzlich strukturiert Certbot Ihren Serverblock um, um allen HTTP-Verkehr auf HTTPS umzuleiten. Sie haben jetzt einen zusätzlichen Serverblock, der Ihre ursprüngliche listen-Direktive auf Port 80 handhabt. Dieser neue Serverblock fängt allen Verkehr zu Ihren Domains ab, indem er eine bedingte Überprüfung auf die $host-Variable durchführt. Dies wird mit den bedingten if-Direktivenanweisungen ausgeführt. Diese Direktiven überprüfen, ob die Variable mit Ihren Domains übereinstimmt, dann verwendet Nginx eine 301-Umleitung, um die Anfrage zur HTTPS-Version der Site zu senden. Darüber hinaus wird als Sicherheitsnetz jeder Verkehr, der durch die bedingte Umleitung gelangt, als 404-Fehler erfasst.

Ihre Firewall-Einstellungen anpassen

Wenn Ihr Webbrowser nicht reagiert, selbst nachdem Sie das TLS/SSL-Zertifikat eingerichtet haben, dann könnten Sie ein Problem mit Ihren Firewall-Einstellungen haben. Wie im vorherigen Abschnitt erwähnt, wird die Umleitung von HTTP und HTTPS automatisch als listen-Direktive in Ihrer Konfigurationsdatei eingerichtet, wenn Sie dem Let’s Encrypt-Tutorial gefolgt sind. Daher könnte eine mögliche Fehlerquelle sein, dass Ihre Firewall keinen HTTPS-Verkehr auf Port 443 zulässt.

Um den Status der derzeit offenen Ports auf Ihrer Firewall zu überprüfen, können Sie den folgenden Befehl ausführen. Beachten Sie, dass dieses Tutorial die Uncomplicated Firewall, UFW, verwendet, sodass dies je nach Ihrer Distribution variieren kann:

sudo ufw status
Status: active

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

Wenn Ihre Outputs eine Liste ähnlich der folgenden widerspiegeln, dann bedeutet dies, dass Ihre Firewall derzeit nur für die Annahme von HTTP-Anfragen geöffnet ist. Um diese Einstellungen zu ändern, müssen Sie das Nginx-HTTPS-Profil hinzufügen, das TLS/SSL-verschlüsselten Verkehr über Port 443 zulässt. Führen Sie dazu den folgenden Befehl aus:

sudo ufw allow 'Nginx HTTPS'

Wenn Sie die Rückmeldung Rule added erhalten haben, dann haben Sie dieses Profil erfolgreich zu Ihrer Liste hinzugefügt. Sie können dies bestätigen, indem Sie den Status überprüfen:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
Nginx HTTPS                ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)
Nginx HTTPS (v6)           ALLOW       Anywhere (v6)

Hinweis: Es gibt ein Nginx-Profil namens Nginx Full, das sowohl HTTP- als auch HTTPS-Portverbindungen öffnet. Wenn Sie die Liste aufräumen möchten, können Sie die beiden Regeln mit sudo ufw delete allow ‚Nginx HTTP‘ und sudo ufw delete allow ‚Nginx HTTPS‘ entfernen und die folgende Regel hinzufügen:

sudo ufw allow 'Nginx Full'

Ihre Firewall ist dann bereit, Verbindungen von HTTP- und HTTPS-Verkehr zu akzeptieren.

Jetzt sind sowohl die Nginx HTTP- als auch die HTTPS-Profile aufgeführt, Port 443 ist geöffnet, und Anfragen werden auf HTTPS umgeleitet.

Ihre Umleitung sicher mit einem Nginx SSL-Zertifikat einrichten

Die Umleitung von HTTP auf HTTPS bedeutet, dass Sie verschlüsselte Verkehrsverbindungen zulassen, und dies wird typischerweise mit einem TLS/SSL-Zertifikat verifiziert. Es gibt jedoch immer noch mögliche Fehlermeldungen auf Browser-Ebene. Behalten Sie im Hinterkopf, dass diese Fehlermeldungen nicht bedeuten, dass etwas mit Ihrem Nginx-Server falsch ist, sondern eher mit dem Nginx SSL-Zertifikat selbst.

Zum Beispiel, wenn Sie ein selbstsigniertes SSL-Zertifikat verwenden, ist dieses nicht von einer Zertifizierungsstelle (CA) wie Let’s Encrypt verifiziert. Infolgedessen wird wahrscheinlich eine Warnmeldung erscheinen, wenn Sie in Ihrem Browser zu https://example.com navigieren, die Besucher darauf hinweist, dass diese Seite unsicher ist:

In diesem Szenario gibt es einen Fehler, der besagt, Ihre Verbindung ist nicht privat und hat einen spezifischen Fehler, der NET::ERR_CERT_AUTHORITY_INVALID angibt. Es ist möglich, dies zu umgehen, trotz dass das Nginx SSL-Zertifikat nicht sicher ist, wenn Sie auf die Option Erweitert drücken:

Die Option Erweitert gibt an, dass example.com nicht ausreichend identifiziert werden kann. Auch wenn dies nicht wahr sein mag, weil Sie Ihren Webserver mit einem selbstsignierten Nginx SSL-Zertifikat eingerichtet haben, wird dies so von jedem wahrgenommen, der Ihre Seite besucht.

Obwohl Sie auf Ihrer Website fortfahren können, indem Sie auf die Option Weiter zu… drücken, ist es eine schlechte Benutzererfahrung, diese Art von Sicherheits- und Datenschutznachricht beim Besuch Ihrer Seite zu erhalten. Sie werden ein Zertifikat verwenden wollen, das von einer CA verifiziert ist.

Es ist jedoch möglich, die folgende Nachricht zu erhalten, auch wenn Sie ein TLS/SSL-Zertifikat über Let’s Encrypt eingerichtet haben:

Diese Nachricht unterscheidet sich von der ursprünglichen Nachricht Ihre Verbindung ist nicht privat, da der Netzwerkfehler NET::ERR_CERT_DATE_INVALID lautet, was bedeutet, dass Ihr aktuelles SSL/TLS-Zertifikat abgelaufen ist. Es ist wichtig zu beachten, dass ein Let’s Encrypt-Zertifikat nur für 90 Tage gültig ist. Wenn Sie das certbot-Paket bei der Installation von Let’s Encrypt verwendet haben, wird eine Überprüfung auf ablaufende Zertifikate innerhalb der nächsten 30 Tage geplant, und dies wird zweimal täglich über systemd ausgeführt.

Sie können den Status des Timers mit dem folgenden Befehl überprüfen:

sudo systemctl status snap.certbot.renew.service

Die Ausgabe bestätigt, dass Ihre Zertifikatserneuerung aktiv ist.

Wenn Ihr Zertifikat abgelaufen ist und Sie eine Erneuerung erzwingen möchten, können Sie dies mit dem folgenden Befehl tun. Dies ist auch nützlich, wenn Sie verschiedene Domains haben, für die Sie ein Zertifikat erneuern möchten:

certbot certonly –force-renew -d example.com

Obwohl das certbot-Paket mit einem Zertifikatserneuerungsskript mit /etc/cron.d kommt, gibt es auch andere Optionen. Zum Beispiel können Sie die renew_hook-Option mit Certbot einrichten, sodass Sie nach der Erneuerung andere Aufgaben ausführen können. Um dies zu tun, müssen Sie renew_hook zur Certbot-Erneuerungskonfigurationsdatei hinzufügen. Beginnen Sie, indem Sie die Datei mit Ihrem bevorzugten Texteditor öffnen:

sudo nano /etc/letsencrypt/renewal/example.com.conf

Sobald Sie in der Datei sind, fügen Sie den Hook zur letzten Zeile hinzu, um die Web-Frontend-Dienste neu zu laden, damit sie so eingerichtet werden können, dass sie das erneuerte Zertifikat verwenden:

renew_hook = systemctl reload your_service

Sobald Sie fertig sind, können Sie die Datei speichern und schließen. Wenn Sie nano verwenden, drücken Sie STRG + X, Y und dann ENTER.

Unabhängig davon, was Sie wählen, wenn Sie Ihren Zertifikatserneuerungsprozess einrichten, können Sie immer bestätigen, dass certbot den Erneuerungsprozess wie vorgesehen ausführt, mit dem folgenden Befehl:

sudo certbot renew --dry-run

Schließlich überprüfen Sie auf Syntaxfehler mit sudo nginx -t und starten dann Nginx mit sudo systemctl restart nginx neu, um sicherzustellen, dass Ihre Änderungen implementiert sind. Nachdem Sie all dies getan haben, navigieren Sie in Ihrem Webbrowser zu https://example.com, um zu bestätigen, dass die Umleitung korrekt funktioniert.

Schlussfolgerung

In diesem Tutorial haben Sie gelernt, wie Sie gängige Fehler mit Nginx-Webserver-Umleitungen adressieren, speziell von HTTP zu HTTPS. Einige dieser Lösungen umfassen die Überprüfung, ob Ihre Konfigurationsdatei korrekt eingerichtet ist, um auf den entsprechenden Port zu hören, Ihre Firewall zu öffnen, um diese Verbindungen zu empfangen, und wie Sie Sicherheitsfehlermeldungen behandeln, die Sie bezüglich nicht verifizierter oder abgelaufener SSL/TLS-Zertifikate erhalten könnten – HTTPS-Redirect-Fehler – Nginx SSL-Zertifikat und HTTPS-Umleitungsfehler