Häufige Fehler bei der Konfiguration von Domains und HTTPS-Unterstützung

Einleitung

Es gibt viele häufige Fehler, die bei der Konfiguration Ihres Domainnamens oder der HTTPS-Unterstützung auftreten können. DNS, das Domain Name System, kann schwierig zu beheben sein. Es ist schwer, Fehler eindeutig auf DNS zurückzuführen, wenn sie von einem anderen Teil Ihres Stacks verursacht werden könnten.

Ein berüchtigtes „Sysadmin-Haiku“ lautet:

Es ist nicht DNS
Es kann nicht DNS sein
Es war DNS

Die häufigste Zeit, auf DNS-Probleme zu stoßen, ist beim Versuch, die SSL/HTTPS-Unterstützung für Ihre Server zu konfigurieren. Zum Beispiel bei der Verwendung von Let’s Encrypt. In diesem Tutorial werden einige häufige Fehler behandelt, die bei der Arbeit mit DNS, HTTPS oder speziell mit Let’s Encrypt auftreten können.

DNS-Einträge

DNS ist das System, das den Datenverkehr zu Webservern zuweist und leitet. Es verwendet Domänennamen wie your_domain.com, anstatt überall die Verwendung von IP-Adressen zu erfordern. Alle Domain-Registrare stellen ihre eigenen Schnittstellen zur Verwaltung von DNS-Einträgen zur Verfügung, obwohl sie ähnliche Syntax und Regeln verwenden.

Der häufigste DNS-Eintrag ist ein A-Eintrag, der eine primäre Verbindung von einem Domainnamen zu einer Serveradresse herstellt. In diesem Tutorial und bei der Zuweisung von kanonischen Domainnamen zu Server-IP-Adressen geht es hauptsächlich um A-Einträge.

Erforderliche A-Einträge

Aktualisieren oder Migrieren von DNS-Einträgen

Aktualisieren oder Migrieren von DNS-Einträgen

Das Aktualisieren Ihrer DNS-Einträge kann eine Weile dauern, bis sie wirksam werden. Normalerweise sollte es weniger als eine halbe Stunde dauern, aber da Sie DNS nicht sofort nach Änderungen testen können, können Fehler irreführend sein. Sie können Let’s Encrypt nicht für Ihre Domain konfigurieren, bis die DNS-Änderungen auf den meisten oder allen globalen Namensservern verbreitet wurden.

Sie können auch eine Website wie whatsmydns.net verwenden, um zu testen, ob eine DNS-Änderung auf den meisten oder allen globalen Namensservern, die für DNS-Lookups verwendet werden, verbreitet wurde. Wenn DNS bei Ihnen lokal nicht aufgelöst wird, können Sie überprüfen, ob es für die meisten Standorte funktionieren sollte. Ihr Internetanbieter kann langsamer aktualisieren als einige dieser Server, aber normalerweise sollte es nur ein paar Minuten dauern.

Wenn Sie innerhalb eines kurzen Fensters testen, in dem Ihre DNS-Änderungen auf einigen Servern, aber nicht auf anderen verbreitet wurden, ist es möglich, dass Sie unterschiedliche Ergebnisse von Ihrem Remote-Server und Ihrem lokalen Webbrowser erhalten, was noch verwirrender ist. Dies kann passieren, wenn Ihr Remote-Server oder Droplet’s DNS vor dem Ihres Internetanbieters aktualisiert wird. Um diese Fehler auszuschließen, können Sie auch den Befehl nslookup verwenden, um zu testen, welche IP-Adresse ein bestimmter Domainname auflöst:

nslookup mydomain.com

Ausgabe

Name: mydomain.com
    Addresses: 2606:4700::6810:b50f
    2606:4700::6810:b60f
    104.16.181.15
    104.16.182.15

Auf diese Weise können Sie überprüfen, ob Ihre lokalen Ergebnisse mit den globalen DNS-Resolvern übereinstimmen.

Das Konfigurieren Ihres DNS mit einem längeren TTL-Wert (Time-To-Live) macht das Update ebenfalls länger. Der Standard-TTL-Wert, der von den meisten Domainnamenregistraren konfiguriert wird, beträgt 3600 Sekunden oder 1 Stunde. Dies wird normalerweise direkt neben Ihrem A-Eintrag aufgeführt. Ein längerer TTL-Wert hilft, Anfragen effizienter zu cachen, kann jedoch dazu führen, dass DNS-Änderungen länger brauchen, um sich zu verbreiten. Sie möchten Ihren TTL-Wert möglicherweise vorübergehend niedriger einstellen, wenn Sie DNS-Änderungen vornehmen oder testen möchten.

Browser-Fehler und Probleme bei der HTTPS-Konfiguration

Manchmal denken Sie vielleicht, dass Sie HTTPS und Ihre DNS richtig konfiguriert haben, aber Sie oder Ihre Benutzer erhalten dennoch Fehler in ihrem Browser, wenn sie versuchen, Ihre Website zu nutzen.

Die meisten dieser Fehler weisen nicht direkt auf HTTPS-Probleme hin, können jedoch aus fehlerhaften Konfigurationen resultieren. Zum Beispiel, wenn Sie einen Nginx Reverse Proxy verwenden, um ein HTTPS-Gateway zu einer anderen Anwendung bereitzustellen, die auf Ihrem Server läuft, und das Gateway falsch konfiguriert ist, könnten Sie einen 502-Fehler erhalten.

Ein weiterer Fehler, dem Sie begegnen können, ist ein abgelaufenes Zertifikat. Im Gegensatz zu kommerziellen HTTPS-Zertifikaten sind Let’s Encrypt-Zertifikate nur 3 Monate gültig, und das Versäumnis, ein Zertifikat vor Ablaufdatum zu erneuern, führt zu einem Fehler für jeden, der versucht, auf Ihre Website zuzugreifen.

Normalerweise wird dies einen ERR_CERT_DATE_INVALID-Fehler erzeugen. In Chrome könnte dies so aussehen:

Ein abgelaufenes Zertifikat Browser-Warnung

Wenn Sie Let’s Encrypt zunächst konfigurieren, sollte es einen Hintergrundprozess einrichten, um Ihr Zertifikat automatisch zu erneuern. Let’s Encrypt sendet Ihnen auch normalerweise eine E-Mail, wenn Ihr Zertifikat abläuft.

Wenn dieser Prozess jedoch falsch konfiguriert ist oder fehlschlägt, können Sie Ihre Zertifikate manuell erneuern, indem Sie certbot mit dem Befehl renew erneut ausführen:

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

Sie müssen möglicherweise Ihren Webserver nach der Erneuerung Ihrer Zertifikate neu starten. Wenn Sie keine anderen Änderungen an der Konfiguration Ihres Webservers vorgenommen haben, können Sie dies sicher automatisieren (zum Beispiel durch Hinzufügen zu einem geplanten Cron), indem Sie Folgendes ausführen:

systemctl restart nginx

Gemischte Inhalte

Wenn Sie einen komplexen Stack von HTTP auf HTTPS migrieren, bemerken Sie möglicherweise, dass einige Bilder oder andere Website-Ressourcen nicht angezeigt werden. Wenn Sie die Entwicklerkonsole des Browsers öffnen, werden diese Fehler auf „gemischte Inhalte“ zurückgeführt:

Browserfehler zu gemischten Inhalten

Dies liegt an einer Standard-Webrichtlinie, dass HTTP-Inhalte nicht in Websites enthalten sein sollten, die über HTTPS bereitgestellt werden. Dies kann passieren, wenn eine Website Inhalte von zwei verschiedenen Webservern lädt. Oder wenn eine Webanwendung hinter einem Nginx-Gateway bereitgestellt wird, aber die SSL-Weiterleitung nicht richtig funktioniert.

Wenn Sie Nginx verwenden und Datenverkehr zu einer anderen Anwendung hinter Ihrem Webserver weiterleiten und dabei Warnungen zu gemischten Inhalten erhalten, können Sie versuchen, zusätzliche SSL-Weiterleitungskonfigurationen zu einem location-Block hinzuzufügen:

/etc/nginx/sites-available/your-website
    …
        location / {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Proto https;
        }

Darüber hinaus stellen Sie sicher, dass jede von Ihnen bereitgestellte Website mit HTTPS konfiguriert ist. Sie können auch die MDN-Dokumentation zu gemischten Inhaltsfehlern zu Rate ziehen.

Fehler beim Ausführen des Certbot-Skripts von Let’s Encrypt

Sie können auch auf Fehler stoßen, wenn Sie das Certbot-Skript von Let’s Encrypt selbst ausführen. Manchmal enthalten diese Fehler eine beschreibende Ausgabe, die Sie direkt befolgen können. Andere sind weniger eindeutig. Wenn das Skript „timeout“ meldet, handelt es sich höchstwahrscheinlich um ein Firewall-Problem und zeigt Folgendes an:

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

Ausgabe

    Press Enter to Continue
    Waiting for verification…
    Cleaning up challenges
    Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://example.com/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0: 93 Timeout during connect (likely firewall problem)

Normalerweise wird ein Timeout durch eine Verbindung verursacht, die überhaupt keine Antwort erhalten kann, weil eine Firewall absichtlich den gesamten Datenverkehr blockiert. Überprüfen Sie, ob Ihre Firewall nicht den Port 80 oder 443 blockiert, bevor Sie versuchen, Certbot auszuführen. Einige Dokumentationen schlagen vor, dass Sie nur einen der Ports 80 oder 443 öffnen müssen, aber um alle Fehler auszuschließen, sollten Sie versuchen, beide zu öffnen. Wenn Sie UFW mit Nginx verwenden, können Sie dies tun, indem Sie die vollständige Nginx-Konfiguration aktivieren:

sudo ufw allow 'Nginx Full'

Versuchen Sie, Certbot nach der Änderung Ihrer Firewall-Einstellungen erneut auszuführen. Wenn Sie Certbot mehrmals hintereinander ausgeführt haben, um einen Fehler auszuschließen, könnten Sie eine Fehlermeldung zur „Validierungsgrenze“ erhalten, wie diese:

Ausgabe

    too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

In diesem Fall müssen Sie bis zu eine Stunde warten, bis Ihr Konto nicht mehr eingeschränkt ist. Weitere Informationen zu Validierungsgrenzen und anderen Certbot-Fehlern finden Sie in der Certbot-Dokumentation.

Wenn Sie andere Certbot-Fehler erhalten, die nicht mit DNS, Timeouts oder Verbindungsproblemen zu tun haben, handelt es sich wahrscheinlich um Probleme mit der Python-Umgebung auf Ihrem Server, die von Certbot konfiguriert wurde.

HTTPS funktioniert nicht ohne sichtbare Fehler

Wenn Sie überprüft haben, dass Certbot und Ihr DNS korrekt funktionieren, Ihre Website jedoch scheinbar nicht von HTTP zu HTTPS gewechselt hat, liegt dies normalerweise an einer Konfiguration Ihres Webservers. Certbot versucht, die Konfigurationsdateien Ihres Webservers automatisch zu aktualisieren, wenn es zum ersten Mal ausgeführt wird. Aus diesem Grund geben Sie normalerweise nginx in einem Certbot-Befehl an, damit Certbot weiß, welche Art von Webserverkonfiguration nach dem Abrufen eines Zertifikats aktualisiert werden soll. Wenn jedoch Ihre bestehende Webserverkonfiguration sehr komplex ist, kann Certbot diese möglicherweise nicht auf HTTPS aktualisieren, und Sie müssen Ihre eigenen Änderungen vornehmen.

Stellen Sie zunächst sicher, dass Sie einen server_name-Block in Ihrer Webserverkonfigurationsdatei enthalten haben. Ohne diesen weiß Certbot nicht, welche Konfigurationsdatei aktualisiert werden soll. Wenn Sie danach weiterhin Probleme haben, müssen Sie Certbot möglicherweise im Standalone-Modus ausführen, um nur ein Zertifikat abzurufen, und dann Ihren Webserver manuell konfigurieren, um HTTPS zu verwenden.

Eine grundlegende Nginx-HTTPS-Konfiguration enthält listen 443 ssl und den Pfad zu einem SSL-Zertifikat und Schlüssel, wie folgt:

/etc/nginx/sites-available/sample
    …
        listen 443 ssl;
        # RSA-Zertifikat
        ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

        # Weiterleitung von nicht-HTTPS-Traffic zu HTTPS
        if ($scheme != "https") {
            return 301 https://$host$request_uri;
        }
    …

Wenn Sie Nginx konfigurieren, denken Sie daran, dass Sie Änderungen an Ihrer Nginx-Konfiguration durch Ausführen von nginx -t validieren können, bevor Sie den Webserver neu starten. Sobald Sie die Änderungen vorgenommen haben, können Sie Nginx mit der neuen Konfiguration durch Ausführen von folgendem neu starten:

sudo systemctl restart nginx

Fazit

Das Ziel von Let’s Encrypt ist es, allen überall kostenlos HTTPS zur Verfügung zu stellen. Wenn dies automatisch funktioniert, ist es sehr nützlich. Wenn es jedoch nicht funktioniert, kann es verwirrend sein, insbesondere wenn Sie wenig Erfahrung mit der Konfiguration von SSL oder DNS haben. In diesem Tutorial haben Sie mehrere häufige Fehlerszenarien für Let’s Encrypt sowie Fehlerbehebungsschritte durchgesehen.