So erstellen Sie ein selbstsigniertes SSL-Zertifikat für Nginx unter CentOS 7

Einführung

TLS oder Transport Layer Security und sein VorgängerSSL, der für Secure Sockets Layer steht, sind Webprotokolle, mit denen normaler Datenverkehr in einen geschützten, verschlüsselten Wrapper eingeschlossen wird.

Mithilfe dieser Technologie können Server Datenverkehr sicher zwischen Server und Clients senden, ohne dass die Nachrichten von Dritten abgefangen werden können. Das Zertifikatsystem unterstützt Benutzer auch bei der Überprüfung der Identität der Sites, mit denen sie eine Verbindung herstellen.

In diesem Handbuch zeigen wir Ihnen, wie Sie ein selbstsigniertes SSL-Zertifikat für die Verwendung mit einem Nginx-Webserver auf einem CentOS 7-Server einrichten.

[.Hinweis]##

Note: Ein selbstsigniertes Zertifikat verschlüsselt die Kommunikation zwischen Ihrem Server und allen Clients. Da es jedoch nicht von einer der vertrauenswürdigen Zertifizierungsstellen signiert ist, die in den Webbrowsern enthalten sind, können Benutzer das Zertifikat nicht verwenden, um die Identität Ihres Servers automatisch zu überprüfen.

Ein selbstsigniertes Zertifikat ist möglicherweise geeignet, wenn Sie keinen Domänennamen mit Ihrem Server verknüpft haben und wenn die verschlüsselte Webschnittstelle nicht für Benutzer sichtbar ist. Wenn Siedo einen Domainnamen haben, ist es in vielen Fällen besser, ein CA-signiertes Zertifikat zu verwenden. Befolgen Sie unsere Anleitung zusetting up Nginx with a Let’s Encrypt certificate on CentOS 7.
, um zu erfahren, wie Sie ein kostenloses vertrauenswürdiges Zertifikat einrichten

Voraussetzungen

Zunächst sollte ein Benutzer ohne Rootberechtigung mit den Berechtigungen vonsudokonfiguriert sein. Sie können lernen, wie Sie ein solches Benutzerkonto einrichten, indem Sie unsereninitial server setup for CentOS 7 folgen.

Wenn Sie bereit sind, melden Sie sich bei Ihrem Server als Benutzer vonsudoan.

Schritt 1: Installieren Sie Nginx und passen Sie die Firewall an

Bevor wir beginnen, sollten wir sicherstellen, dass der Nginx-Webserver auf unserem Computer installiert ist.

Während Nginx in den Standard-Repositorys von CentOS nicht verfügbar ist, ist esisim EPEL-Repository (Extra Packages for Enterprise Linux) vorhanden. Wir können es dem EPEL-Repository ermöglichen, unserem Server Zugriff auf das Nginx-Paket zu gewähren, indem wir Folgendes eingeben:

sudo yum install epel-release

Als nächstes können wir Nginx installieren, indem wir Folgendes eingeben:

sudo yum install nginx

Starten Sie den Nginx-Dienst, indem Sie Folgendes eingeben:

sudo systemctl start nginx

Überprüfen Sie, ob der Dienst aktiv ist, indem Sie Folgendes eingeben:

systemctl status nginx
Output● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-01-06 17:27:50 UTC; 28s ago

. . .

Jan 06 17:27:50 centos-512mb-nyc3-01 systemd[1]: Started The nginx HTTP and reverse proxy server.

Sie möchten auch Nginx aktivieren, damit es beim Booten Ihres Servers gestartet wird:

sudo systemctl enable nginx
OutputCreated symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.

Als nächstes müssen wir sicherstellen, dass wir den Zugriff auf Port 80 und 443 nicht mit einer Firewall blockieren. Wenn Sie keine Firewall verwenden, können Sie mit dem nächsten Abschnitt fortfahren.

Wenn einefirewalld-Firewall ausgeführt wird, können Sie diese Ports öffnen, indem Sie Folgendes eingeben:

sudo firewall-cmd --add-service=http
sudo firewall-cmd --add-service=https
sudo firewall-cmd --runtime-to-permanent

Wenn eineiptables-Firewall ausgeführt wird, hängen die Befehle, die Sie ausführen müssen, stark von Ihrem aktuellen Regelsatz ab. Für einen grundlegenden Regelsatz können Sie HTTP- und HTTPS-Zugriff hinzufügen, indem Sie Folgendes eingeben:

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

Sie sollten nun in der Lage sein, über einen Webbrowser auf die Standard-Nginx-Seite zuzugreifen.

Schritt 2: Erstellen Sie das SSL-Zertifikat

TLS/SSL works by using a combination of a public certificate and a private key. Der SSL-Schlüssel wird auf dem Server geheim gehalten. Es wird zum Verschlüsseln von an Clients gesendeten Inhalten verwendet. Das SSL-Zertifikat wird öffentlich für alle Benutzer freigegeben, die den Inhalt anfordern. Es kann verwendet werden, um den mit dem zugehörigen SSL-Schlüssel signierten Inhalt zu entschlüsseln.

Das Verzeichnis/etc/ssl/certs, in dem das öffentliche Zertifikat gespeichert werden kann, sollte bereits auf dem Server vorhanden sein. Erstellen wir auch ein/etc/ssl/private-Verzeichnis, um die private Schlüsseldatei aufzunehmen. Da die Geheimhaltung dieses Schlüssels für die Sicherheit unerlässlich ist, werden die Berechtigungen gesperrt, um unbefugten Zugriff zu verhindern:

sudo mkdir /etc/ssl/private
sudo chmod 700 /etc/ssl/private

Jetzt können wir mit OpenSSL in einem einzigen Befehl ein selbstsigniertes Paar aus Schlüssel und Zertifikat erstellen, indem wir Folgendes eingeben:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Sie werden eine Reihe von Fragen gestellt. Bevor wir darauf eingehen, werfen wir einen Blick darauf, was in dem Befehl passiert, den wir ausgeben:

  • openssl: Dies ist das grundlegende Befehlszeilentool zum Erstellen und Verwalten von OpenSSL-Zertifikaten, Schlüsseln und anderen Dateien.

  • req: Dieser Unterbefehl gibt an, dass die CSR-Verwaltung (X.509 Certificate Signing Request) verwendet werden soll. Der „X.509“ ist ein Infrastrukturstandard für öffentliche Schlüssel, den SSL und TLS für die Verwaltung von Schlüsseln und Zertifikaten einhalten. Wir möchten ein neues X.509-Zertifikat erstellen und verwenden daher diesen Unterbefehl.

  • -x509: Dadurch wird der vorherige Unterbefehl weiter geändert, indem dem Dienstprogramm mitgeteilt wird, dass ein selbstsigniertes Zertifikat erstellt werden soll, anstatt wie normalerweise eine Zertifikatsignierungsanforderung zu generieren.

  • -nodes: Dies weist OpenSSL an, die Option zum Sichern unseres Zertifikats mit einer Passphrase zu überspringen. Wir brauchen Nginx, um die Datei ohne Benutzereingriff lesen zu können, wenn der Server gestartet wird. Eine Passphrase würde dies verhindern, da wir sie nach jedem Neustart eingeben müssten.

  • -days 365: Diese Option legt fest, wie lange das Zertifikat als gültig angesehen wird. Wir setzen es für ein Jahr hier.

  • -newkey rsa:2048: Dies gibt an, dass gleichzeitig ein neues Zertifikat und ein neuer Schlüssel generiert werden sollen. Wir haben in einem vorherigen Schritt nicht den Schlüssel erstellt, der zum Signieren des Zertifikats erforderlich ist, und müssen ihn daher zusammen mit dem Zertifikat erstellen. Der Teilrsa:2048 weist ihn an, einen RSA-Schlüssel mit einer Länge von 2048 Bit zu erstellen.

  • -keyout: Diese Zeile teilt OpenSSL mit, wo die generierte private Schlüsseldatei, die wir erstellen, abgelegt werden soll.

  • -out: Hiermit wird OpenSSL mitgeteilt, wo das von uns erstellte Zertifikat abgelegt werden soll.

Wie oben erwähnt, werden mit diesen Optionen sowohl eine Schlüsseldatei als auch ein Zertifikat erstellt. Wir werden einige Fragen zu unserem Server stellen, um die Informationen korrekt in das Zertifikat einzubetten.

Füllen Sie die Eingabeaufforderungen entsprechend aus. The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name associated with your server or your server’s public IP address.

Die gesamten Eingabeaufforderungen sehen ungefähr so ​​aus:

OutputCountry Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:server_IP_address
Email Address []:admin@your_domain.com

Beide von Ihnen erstellten Dateien werden in den entsprechenden Unterverzeichnissen des Verzeichnisses/etc/sslabgelegt.

Während wir OpenSSL verwenden, sollten wir auch eine starke Diffie-Hellman-Gruppe erstellen, die bei der Aushandlung vonPerfect Forward Secrecy mit Clients verwendet wird.

Wir können dies tun, indem wir Folgendes eingeben:

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 bei/etc/ssl/certs/dhparam.pem, die wir in unserer Konfiguration verwenden können.

Schritt 3: Konfigurieren Sie Nginx für die Verwendung von SSL

Die Standardkonfiguration von Nginx in CentOS ist recht unstrukturiert, und der Standard-HTTP-Serverblock befindet sich in der Hauptkonfigurationsdatei. Nginx sucht im Verzeichnis/etc/nginx/conf.dnach Dateien, die auf.conf enden, um weitere Konfigurationen zu erhalten.

In diesem Verzeichnis wird eine neue Datei erstellt, um einen Serverblock zu konfigurieren, der mithilfe der von uns generierten Zertifikatdateien Inhalte bereitstellt. Anschließend können wir optional den Standardserverblock so konfigurieren, dass HTTP-Anforderungen an HTTPS umgeleitet werden.

Erstellen Sie den TLS / SSL-Serverblock

Erstellen und öffnen Sie eine Datei mit dem Namenssl.conf im Verzeichnis/etc/nginx/conf.d:

sudo vi /etc/nginx/conf.d/ssl.conf

Beginnen Sie im Inneren mit dem Öffnen einesserver-Blocks. Standardmäßig verwenden TLS / SSL-Verbindungen Port 443, daher sollte dies unserlisten-Port sein. server_name sollten auf den Domänennamen oder die IP-Adresse des Servers festgelegt werden, die Sie beim Generieren Ihres Zertifikats als allgemeinen Namen verwendet haben. Verwenden Sie als Nächstes die Anweisungenssl_certificate,ssl_certificate_key undssl_dhparam, um den Speicherort der von uns generierten SSL-Dateien festzulegen:

/etc/nginx/conf.d/ssl.conf

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name server_IP_address;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
}

Als Nächstes werden wir einige zusätzliche SSL-Optionen hinzufügen, die die Sicherheit unserer Site erhöhen. Die Optionen, die wir verwenden werden, sind Empfehlungen vonRemy van Elst auf derCipherli.st-Seite. Diese Website wurde entwickelt, um benutzerfreundliche Verschlüsselungseinstellungen für gängige Software bereitzustellen. Sie können mehr über seine Entscheidungen bezüglich der Nginx-Auswahl erfahren, indem SieStrong SSL Security on nginx lesen.

[.Hinweis]##

Note: Die vorgeschlagenen Standardeinstellungen fürCipherli.st bieten hohe Sicherheit. Dies geht manchmal zu Lasten einer größeren Client-Kompatibilität. Wenn Sie ältere Clients unterstützen müssen, gibt es eine alternative Liste, auf die Sie zugreifen können, indem Sie auf den Link "Ja, geben Sie mir eine Verschlüsselungssuite, die mit älterer / alter Software funktioniert" klicken.

Die Kompatibilitätsliste kann anstelle der Standardvorschläge in der obigen Konfiguration zwischen den beiden Kommentarblöcken verwendet werden. Die Wahl der verwendeten Konfiguration hängt weitgehend davon ab, was Sie unterstützen müssen.

Es gibt einige Teile der Konfiguration, die Sie möglicherweise ändern möchten. Zunächst können Sie Ihren bevorzugten DNS-Resolver für Upstream-Anforderungen zur Direktiveresolverhinzufügen. Für diesen Leitfaden haben wir Google verwendet. Sie können dies jedoch ändern, wenn Sie andere Einstellungen haben.

Schließlich sollten Sie sich einen Moment Zeit nehmen, umHTTP Strict Transport Security, or HSTS und insbesondere“preload” functionality zu lesen. 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/conf.d/ssl.conf

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name server_IP_address;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ########################################################################
    # 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 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    # Disable preloading HSTS for now.  You can use the commented out header line that includes
    # the "preload" directive if you understand the implications.
    #add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    ##################################
    # END https://cipherli.st/ BLOCK #
    ##################################
}

Da wir ein selbstsigniertes Zertifikat verwenden, wird die SSL-Heftung nicht verwendet. Nginx gibt einfach eine Warnung aus, deaktiviert das Heften für unser selbstsigniertes Zertifikat und funktioniert weiterhin ordnungsgemäß.

Fügen Sie abschließend den Rest der Nginx-Konfiguration für Ihre Site hinzu. Dies hängt von Ihren Anforderungen ab. Wir werden nur einige der Anweisungen kopieren, die im Standardverzeichnisblock für unser Beispiel verwendet werden. Dabei werden der Dokumentstamm und einige Fehlerseiten festgelegt:

/etc/nginx/conf.d/ssl.conf

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name server_IP_address;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

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

    . . .

    ##################################
    # END https://cipherli.st/ BLOCK #
    ##################################

    root /usr/share/nginx/html;

    location / {
    }

    error_page 404 /404.html;
    location = /404.html {
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

Wenn Sie fertig sind, speichern und beenden Sie. Dadurch wird Nginx so konfiguriert, dass unser generiertes SSL-Zertifikat zum Verschlüsseln des Datenverkehrs verwendet wird. Die angegebenen SSL-Optionen stellen sicher, dass nur die sichersten Protokolle und Verschlüsselungen verwendet werden. Beachten Sie, dass diese Beispielkonfiguration lediglich die Standard-Nginx-Seite darstellt. Sie können sie also an Ihre Anforderungen anpassen.

(Optional) Erstellen Sie eine Umleitung von HTTP zu HTTPS

In unserer aktuellen Konfiguration antwortet Nginx mit verschlüsseltem Inhalt für Anforderungen an Port 443, antwortet jedoch mit unverschlüsseltem Inhalt für Anforderungen an Port 80. Dies bedeutet, dass unsere Website eine Verschlüsselung bietet, ihre Verwendung jedoch nicht erzwingt. Für einige Anwendungsfälle mag dies in Ordnung sein, normalerweise ist es jedoch besser, eine Verschlüsselung zu fordern. Dies ist besonders wichtig, wenn vertrauliche Daten wie Passwörter zwischen dem Browser und dem Server übertragen werden können.

Glücklicherweise können wir mit der Standard-Nginx-Konfigurationsdatei einfach Anweisungen zum Standard-Port 80-Serverblock hinzufügen, indem wir Dateien im Verzeichnis/etc/nginx/default.dhinzufügen. Erstellen Sie eine neue Datei mit dem Namenssl-redirect.conf und öffnen Sie sie zur Bearbeitung mit diesem Befehl:

sudo vi /etc/nginx/default.d/ssl-redirect.conf

Dann fügen Sie diese Zeile ein:

/etc/nginx/default.d/ssl-redirect.conf

return 301 https://$host$request_uri/;

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Dadurch wird der HTTP-Serverblock auf Port 80 (Standard) so konfiguriert, dass eingehende Anforderungen an den von uns konfigurierten HTTPS-Serverblock umgeleitet werden.

Schritt 4: Aktivieren Sie die Änderungen in Nginx

Nachdem wir unsere Änderungen vorgenommen haben, können wir Nginx neu starten, um unsere neue Konfiguration 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: [warn] "ssl_stapling" ignored, issuer certificate not found
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Beachten Sie die Warnung am Anfang. Wie bereits erwähnt, wird bei dieser Einstellung eine Warnung ausgegeben, da unser selbstsigniertes Zertifikat kein SSL-Stapling verwenden kann. Dies wird erwartet und unser Server kann weiterhin Verbindungen korrekt verschlüsseln.

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

Der Nginx-Prozess wird neu gestartet, wobei die von uns konfigurierten SSL-Einstellungen implementiert werden.

Schritt 5: Testen Sie die Verschlüsselung

Jetzt können Sie Ihren SSL-Server testen.

Öffnen Sie Ihren Webbrowser und geben Siehttps:// gefolgt vom Domainnamen oder der IP Ihres Servers in die Adressleiste ein:

https://server_domain_or_IP

Da das von uns erstellte Zertifikat nicht von einer der vertrauenswürdigen Zertifizierungsstellen Ihres Browsers signiert ist, wird wahrscheinlich eine beängstigend aussehende Warnung wie die folgende angezeigt:

Nginx self-signed cert warning

Dies ist zu erwarten und normal. Wir interessieren uns nur für den Verschlüsselungsaspekt unseres Zertifikats, nicht für die Überprüfung der Authentizität unseres Hosts durch Dritte. Klicken Sie auf "ERWEITERT" und dann auf den angegebenen Link, um trotzdem zu Ihrem Host zu gelangen:

Nginx self-signed override

Sie sollten zu Ihrer Site weitergeleitet werden. Wenn Sie in die Adressleiste des Browsers schauen, werden Sie Hinweise auf eine teilweise Sicherheit sehen. Dies kann ein Schloss mit einem „x“ oder ein Dreieck mit einem Ausrufezeichen sein. In diesem Fall bedeutet dies nur, dass das Zertifikat nicht validiert werden kann. Es verschlüsselt immer noch Ihre Verbindung.

Wenn Sie Nginx so konfiguriert haben, dass HTTP-Anforderungen an HTTPS umgeleitet werden, können Sie auch überprüfen, ob die Umleitung ordnungsgemäß funktioniert:

http://server_domain_or_IP

Wenn das gleiche Symbol angezeigt wird, hat Ihre Umleitung ordnungsgemäß funktioniert.

Fazit

Sie haben Ihren Nginx-Server so konfiguriert, dass für Clientverbindungen eine starke Verschlüsselung verwendet wird. Auf diese Weise können Sie Anfragen sicher bedienen und verhindern, dass Dritte Ihren Datenverkehr lesen.