Verwendung von HTTPS auf Arch Linux Webserver

• Voraussetzungen
• Sicheres Servieren über HTTPS
• Besorgen Sie sich ein SSL / TLS-Zertifikat
• Konfigurieren Sie Ihren Webserver für die Verwendung des privaten Schlüssels und des Zertifikats

Voraussetzungen

• Ein Vultr-Server, auf dem Arch Linux auf dem neuesten Stand ist (siehe diesen Artikel ).
• Ein laufender Webserver, entweder Apache oder Nginx
• Sudo Zugang
  • Befehlen, die als root ausgeführt werden müssen, wird ein Präfix vorangestellt #, und Befehle , die als normaler Benutzer ausgeführt werden können $. Die empfohlene Methode zum Ausführen von Befehlen als Root besteht darin, jedem von ihnen als regulärer Benutzer ein Präfix voranzustellen sudo.
• Lassen Sie einen Texteditor installieren und machen Sie sich mit ihm vertraut, z. B. vi, vim, nano, emacs oder einem anderen ähnlichen Editor.

Sicheres Servieren über HTTPS

Das Bereitstellen von Inhalten über HTTPS kann eine extrem starke Verschlüsselung verwenden, sodass niemand, der den Datenverkehr zwischen dem Benutzer und dem Webserver abfängt, ihn lesen kann. Es verschlüsselt nicht nur den Datenverkehr selbst, sondern auch die URL, auf die zugegriffen wird, wodurch ansonsten Informationen verfügbar gemacht werden können. Seit einiger Zeit ermittelt Google im Rahmen der HTTPS Everywhere-Initiative teilweise Suchrankings basierend darauf, ob eine Seite HTTPS verwendet.

Hinweis : Bei einer DNS-Suche wird zwar der Domänenname angezeigt, mit dem eine Verbindung hergestellt wird, während dieses Vorgangs wird jedoch nicht die gesamte URL angezeigt.

Besorgen Sie sich ein SSL / TLS-Zertifikat

Technisch gesehen ersetzte TLS SSL für HTTPS-Zertifikate, aber die meisten Orte nannten TLS-Zertifikate einfach weiter mit dem populäreren Begriff SSL-Zertifikate. Nach der allgemeinen Verwendung wird in diesem Handbuch dasselbe getan.

Um HTTPS verwenden zu können, benötigt Ihr Webserver einen privaten Schlüssel ( .key) für die private Verwendung und ein Zertifikat ( .crt) für die öffentliche Freigabe, das einen öffentlichen Schlüssel enthält. Ein Zertifikat muss unterschrieben sein. Sie können es selbst signieren, aber moderne Browser werden sich beschweren, dass sie den Unterzeichner nicht erkennen. In Chrome wird beispielsweise Folgendes angezeigt : Your connection is not private. Attackers might be trying to steal your information... NET::ERR_CERT_AUTHORITY_INVALID. Wenn nur eine private Gruppe von Personen die Website nutzt, kann dies akzeptabel sein, da Browser eine Möglichkeit zum Fortfahren bieten. Klicken Sie in Chrome beispielsweise auf "Erweitert" und dann auf "Weiter zu ... (unsicher)". Es wird weiterhin "Nicht sicher" angezeigt und das "https" durchgestrichen.

Beachten Sie, dass Sie bei diesem Vorgang nach Ihrem Land, Ihrem Bundesland / Ihrer Vorsehung, Ihrem Ort, Ihrer Organisation, Ihrer Organisationseinheit und Ihren allgemeinen Namen sowie Ihrer E-Mail-Adresse gefragt werden. All dies ist in jedem Browser verfügbar, der über HTTPS eine Verbindung zu Ihrer Website herstellt.

Beachten Sie außerdem, dass Sie, wenn Sie Zertifikate für virtuelle Hosts vergeben, unten unterschiedliche Dateinamen angeben und in Ihren Konfigurationen für virtuelle Hosts darauf verweisen müssen.

Wechseln Sie in das richtige Verzeichnis für Ihren Webserver.

Wenn Sie Apache installiert haben:

$ cd /etc/httpd/conf

Wenn Sie Nginx installiert haben:

$ cd /etc/nginx

Generieren Sie im richtigen Verzeichnis einen privaten Schlüssel ( server.key) und ein selbstsigniertes Zertifikat ( server.crt):

# openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 825

Legen Sie schreibgeschützte Berechtigungen fest und lassen Sie nur zu, dass der private Schlüssel von root gelesen wird:

# chmod 400 server.key
# chmod 444 server.crt

Alternativ können Sie ein von einer vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat erhalten. Sie können verschiedene Unternehmen (Zertifizierungsstellen) bezahlen, um Ihr Zertifikat für Sie zu unterschreiben. Bei der Prüfung von Zertifizierungsstellen kann es wichtig sein, zu prüfen, welche Browser und welche Versionen sie erkennen. Einige neuere Zertifizierungsstellen werden möglicherweise nicht als offizieller anerkannt als ein selbstsigniertes Zertifikat in alten Browserversionen.

In der Regel benötigen Sie nicht nur eine öffentliche IP-Adresse, sondern auch einen Domainnamen. Einige Zertifizierungsstellen können ein Zertifikat an eine öffentliche IP-Adresse ausstellen, dies wird jedoch selten durchgeführt.

Viele Anbieter bieten eine kostenlose 30-Tage-Testversion an, die zunächst empfohlen wird, damit Sie sicherstellen können, dass der Prozess für Sie funktioniert, bevor Sie dafür bezahlen. Die Preise können von einigen Dollar pro Jahr bis zu Hunderten variieren, je nachdem, um welchen Typ es sich handelt und um Optionen wie mehrere Domains oder Subdomains. Ein Standardzertifikat zeigt nur an, dass die Signaturbehörde überprüft hat, ob die Person, die das Zertifikat erhält, Änderungen an der Domäne vornehmen kann. Ein erweitertes Validierungszertifikat zeigt auch an, dass die Signaturbehörde eine Due Diligence-Prüfung des Anforderers durchgeführt hat, und zeigt in modernen Browsern einen grünen Balken in oder in der Nähe der URL an. Wenn Sie überprüfen, ob Sie Änderungen an der Domain vornehmen können, müssen Sie von einigen Signaturbehörden eine E-Mail an eine wichtige Adresse unter dem Domainnamen erhalten, z[email protected]. Viele bieten alternative Überprüfungen an, z. B. das Bereitstellen einer Datei auf Ihrem Server, z. B. das Ablegen der Datei /srv/http/.well-known/pki-validation/für Apache oder /usr/share/nginx/html/.well-known/pki-validation/Nginx für Konfigurationen einzelner Hostverzeichnisse. oder vorübergehend einen CNAME-Eintrag erstellen, den Sie in den DNS-Einträgen Ihrer Domain erhalten.

Die von Ihnen ausgewählte Signaturberechtigung kann leicht unterschiedliche Schritte ausführen, die meisten akzeptieren jedoch das folgende Verfahren:

Generieren Sie im richtigen Verzeichnis einen privaten Schlüssel ( server.key):

# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out server.key

Setzen Sie den privaten Schlüssel auf schreibgeschützt, nur für root:

# chmod 400 server.key

Generieren Sie eine Zertifikatsignierungsanforderung ( server.csr). Sie müssen Ihren Domain-Namen Common Nameeingeben, wenn Sie danach gefragt werden , und Sie können das Challenge-Passwort leer lassen:

# openssl req -new -sha256 -key server.key -out server.csr

Setzen Sie die Zertifikatsignierungsanforderung auf schreibgeschützt, nur für root:

# chmod 400 server.csr

Zeigen Sie den Inhalt der Zertifikatsignierungsanforderung an. Diese Informationen sind base64-codiert und sehen daher wie zufällige Zeichen aus:

# cat server.csr
-----BEGIN CERTIFICATE REQUEST-----
.....
-----END CERTIFICATE REQUEST-----

Führen Sie den Prozess Ihrer Signaturbehörde durch, und kopieren Sie die gesamte Datei einschließlich der -----Zeilen , wenn Sie aufgefordert werden, sie in Ihre CSR einzufügen . Abhängig von der von Ihnen ausgewählten Signaturberechtigung und der Art des Zertifikats erhalten Sie möglicherweise sofort das signierte Zertifikat, oder es kann einige Tage dauern. Wenn Sie das signierte Zertifikat erhalten haben, kopieren Sie es (einschließlich der -----BEGIN CERTIFICATE-----und -----END CERTIFICATE-----Zeilen) in eine Datei mit dem Namen server.crtim richtigen Verzeichnis, das oben für Ihren Webserver angegeben wurde, und setzen Sie es auf schreibgeschützt:

# chmod 444 server.crt

Konfigurieren Sie Ihren Webserver für die Verwendung des privaten Schlüssels und des Zertifikats

Wenn Sie eine Firewall verwenden, müssen Sie den eingehenden TCP-Verkehr für den Port aktivieren 443.

Für Apache

Bearbeiten /etc/httpd/conf/httpd.confund kommentieren Sie diese Zeilen:

LoadModule ssl_module modules/mod_ssl.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
Include conf/extra/httpd-ssl.conf

Beachten Sie, dass bei Verwendung der virtuellen Hosts bei der obigen Änderung /etc/httpd/conf/httpd.confauf allen Hosts dasselbe Zertifikat verwendet wird. Um jedem Host ein eigenes Zertifikat zu geben, damit Browser sich nicht darüber beschweren, dass das Zertifikat nicht mit dem Domänennamen übereinstimmt, müssen Sie jede ihrer Konfigurationsdateien so bearbeiten, dass sie /etc/httpd/conf/vhosts/auf ihr eigenes Zertifikat und ihren eigenen privaten Schlüssel verweisen:

• Wechseln Sie <VirtualHost *:80>zu <VirtualHost *:80 *:443>.

• Fügen Sie innerhalb des VirtualHostAbschnitts Folgendes hinzu:

  SSLEngine on
  SSLCertificateFile "/etc/httpd/conf/YOUR-DOMAIN-NAME.com.crt"
  SSLCertificateKeyFile "/etc/httpd/conf/YOUR-DOMAIN-NAME.com.key"
  

Starten Sie Apache neu:

# systemctl restart httpd

Für Nginx

Bearbeiten /etc/nginx/nginx.confund entfernen Sie den HTTPS serverAbschnitt in der Nähe des unteren Bereichs und ändern Sie die Zeilen wie folgt:

ssl_certificate      server.crt;
ssl_certificate_key  server.key;
root                /usr/share/nginx/html;

Hinweis: Wenn Sie virtuelle Hosts verwenden, werden durch Ausführen der obigen Änderung an /etc/nginx/nginx.confalle Hosts an diesen Speicherort gesendet. Um jedem Host ein eigenes Zertifikat zu geben, müssen Sie jede seiner Konfigurationsdateien bearbeiten /etc/nginx/sites-enabled/, um einen zusätzlichen Serverblock zu haben, der auf sein eigenes Zertifikat und seinen eigenen privaten Schlüssel verweist:

server {
    listen 443 ssl;
    server_name YOUR-DOMAIN-NAME.com;

    ssl_certificate      YOUR-DOMAIN-NAME.com.crt;
    ssl_certificate_key  YOUR-DOMAIN-NAME.com.key;

    ssl_session_cache   shared:SSL:1m;
    ssl_session_timeout 5m;

    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;

    location / {
        root /usr/share/nginx/YOUR-DOMAIN-NAME.com;
        index  index.html index.htm;
    }
}

Starten Sie Nginx neu:

# systemctl restart nginx