• Articles
• admin

Einführung

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

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

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

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

Ein selbstsigniertes Zertifikat kann angebracht sein, wenn Ihrem Server kein Domänenname zugeordnet ist und die verschlüsselte Weboberfläche nicht für den Benutzer zugänglich ist. Wenn Sie einen Domainnamen haben, ist es in vielen Fällen besser, ein von einer Zertifizierungsstelle signiertes Zertifikat zu verwenden. Hier erfahren Sie, wie Sie mit dem Let’s Encrypt-Projekt ein kostenloses vertrauenswürdiges Zertifikat einrichten.

Voraussetzungen

Bevor Sie beginnen, sollten Sie einen Nicht-Root-Benutzer mit sudo Berechtigungen konfiguriert haben. Sie können lernen, wie Sie ein solches Benutzerkonto einrichten, indem Sie unserem ersten Server-Setup für Ubuntu 16.04 folgen.

Sie müssen auch den Apache-Webserver installiert haben. Wenn Sie einen ganzen LAMP-Stack (Linux, Apache, MySQL, PHP) auf Ihrem Server installieren möchten, können Sie unserer Anleitung zum Einrichten von LAMP unter Ubuntu 16.04 folgen. Wenn Sie nur den Apache-Webserver verwenden möchten, überspringen Sie die Schritte zu PHP und MySQL im Handbuch.

Wenn Sie die Voraussetzungen erfüllt haben, fahren Sie unten fort.

Schritt 1: SSL-Zertifikat erstellen

TLS/SSL verwendet eine Kombination aus einem öffentlichen Zertifikat und einem privaten Schlüssel. Der SSL-Schlüssel wird auf dem Server geheim gehalten. Es wird verwendet, um an Clients gesendete Inhalte zu verschlüsseln. Das SSL-Zertifikat wird öffentlich für jeden freigegeben, der den Inhalt anfordert. Es kann verwendet werden, um den mit dem zugehörigen SSL-Schlüssel signierten Inhalt zu entschlüsseln.

Wir können ein selbstsigniertes Schlüssel- und Zertifikatspaar mit OpenSSL in einem einzigen Befehl erstellen:

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

Sie werden eine Reihe von Fragen gestellt werden. 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.
• Anforderung: Dieser Unterbefehl gibt an, dass wir die Verwaltung von X.509-Zertifikatsignieranforderungen (CSR) verwenden möchten. Der „X.509“ ist ein Public-Key-Infrastructure-Standard, dem SSL und TLS für die Schlüssel- und Zertifikatsverwaltung folgen. Wir möchten ein neues X.509-Zertifikat erstellen, daher verwenden wir diesen Unterbefehl.
• -x509: Dadurch wird der vorherige Unterbefehl weiter geändert, indem dem Dienstprogramm mitgeteilt wird, dass wir ein selbstsigniertes Zertifikat erstellen möchten, anstatt wie normalerweise eine Zertifikatsignierungsanforderung zu generieren.
• -nodes: Dies weist OpenSSL an, die Option zum Sichern unseres Zertifikats mit einer Passphrase zu überspringen. Wir benötigen Apache, um die Datei beim Start des Servers ohne Benutzereingriff lesen zu können. Eine Passphrase würde dies verhindern, da wir sie nach jedem Neustart eingeben müssten.
• -Tage 365: Diese Option legt fest, wie lange das Zertifikat als gültig betrachtet wird. Wir haben es hier für ein Jahr festgelegt.
• -newkey rsa: 2048: Dies gibt an, dass wir gleichzeitig ein neues Zertifikat und einen neuen Schlüssel generieren möchten. Wir haben den Schlüssel, der zum Signieren des Zertifikats erforderlich ist, in einem vorherigen Schritt nicht erstellt, daher müssen wir ihn zusammen mit dem Zertifikat erstellen. Der rsa:2048 -Teil 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 abgelegt werden soll, die wir erstellen.
• -aus: Dies teilt OpenSSL mit, wo das Zertifikat platziert werden soll, das wir erstellen.

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

Füllen Sie die Eingabeaufforderungen entsprechend aus. Die wichtigste Zeile ist diejenige, die Common Name (e.g. server FQDN or YOUR name) anfordert. Sie müssen den mit Ihrem Server verknüpften Domainnamen oder, wahrscheinlicher, die öffentliche IP-Adresse Ihres Servers eingeben.

Die Gesamtheit der Eingabeaufforderungen wird ungefähr so aussehen:

Output
Country Name (2 letter code) :USState or Province Name (full name) :New YorkLocality Name (eg, city) :New York CityOrganization Name (eg, company) :Bouncy Castles, Inc.Organizational Unit Name (eg, section) :Ministry of Water SlidesCommon Name (e.g. server FQDN or YOUR name) :server_IP_addressEmail Address :admin@your_domain.com

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

Während wir OpenSSL verwenden, sollten wir auch eine starke Diffie-Hellman-Gruppe schaffen, die bei der Aushandlung von Perfect Forward Secrecy mit Kunden 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 Sie fertig sind, haben Sie eine starke DH-Gruppe bei /etc/ssl/certs/dhparam.pem, die wir in unserer Konfiguration verwenden können.

Schritt 2: Konfigurieren Sie Apache für die Verwendung von SSL

Wir haben unsere Schlüssel- und Zertifikatsdateien im Verzeichnis /etc/ssl erstellt. Jetzt müssen wir nur noch unsere Apache-Konfiguration ändern, um diese zu nutzen.

Wir werden einige Anpassungen an unserer Konfiguration vornehmen:

1. Wir werden ein Konfigurations-Snippet erstellen, um starke Standard-SSL-Einstellungen anzugeben.
2. Wir werden die mitgelieferte SSL Apache Virtual Host-Datei so ändern, dass sie auf unsere generierten SSL-Zertifikate verweist.
3. (Empfohlen) Wir ändern die unverschlüsselte virtuelle Hostdatei, um Anforderungen automatisch an den verschlüsselten virtuellen Host umzuleiten.

Wenn wir fertig sind, sollten wir eine sichere SSL-Konfiguration haben.

Erstellen Sie ein Apache-Konfigurations-Snippet mit starken Verschlüsselungseinstellungen

Zuerst erstellen wir ein Apache-Konfigurations-Snippet, um einige SSL-Einstellungen zu definieren. Dies wird Apache 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 von allen virtuellen Hosts verwendet werden, die SSL aktivieren.

Erstellen Sie ein neues Snippet im Verzeichnis /etc/apache2/conf-available. Wir werden die Datei ssl-params.conf nennen, um ihren Zweck klar zu machen:

sudo nano /etc/apache2/conf-available/ssl-params.conf

Um Apache SSL sicher einzurichten, verwenden wir die Empfehlungen von Remy van Elst auf der Cipherli.st website. Diese Website wurde entwickelt, um einfach zu verwendende Verschlüsselungseinstellungen für gängige Software bereitzustellen. Sie können hier mehr über seine Entscheidungen bezüglich der Apache-Entscheidungen lesen.

Die vorgeschlagenen Einstellungen auf der oben verlinkten Website bieten eine hohe Sicherheit. Manchmal geht dies auf Kosten 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 auf der Seite mit der Bezeichnung „Ja, geben Sie mir eine Ciphersuite, die mit älterer / alter Software funktioniert.“ Diese Liste kann durch die unten kopierten Elemente ersetzt werden.

Die Wahl der Konfiguration, die Sie verwenden, hängt weitgehend davon ab, was Sie unterstützen müssen. Beide bieten große Sicherheit.

Für unsere Zwecke können wir die bereitgestellten Einstellungen vollständig kopieren. Wir werden nur zwei kleine Änderungen vornehmen.

Setzen Sie die Direktive SSLOpenSSLConfCmd DHParameters auf die Diffie-Hellman-Datei, die wir zuvor generiert haben. Nehmen Sie sich auch einen Moment Zeit, um sich über HTTP Strict Transport Security oder HSTS und speziell über die „Preload“ -Funktionalität zu informieren. Das Vorladen von HSTS bietet eine erhöhte Sicherheit, kann jedoch weitreichende Folgen haben, wenn es versehentlich oder falsch aktiviert wird. In diesem Handbuch werden wir die Einstellungen nicht vorab laden, aber Sie können dies ändern, wenn Sie sicher sind, dass Sie die Auswirkungen verstehen:

# from https://cipherli.st/# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.htmlSSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDHSSLProtocol All -SSLv2 -SSLv3SSLHonorCipherOrder On# Disable preloading HSTS for now. You can use the commented out header line that includes# the "preload" directive if you understand the implications.#Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"Header always set X-Frame-Options DENYHeader always set X-Content-Type-Options nosniff# Requires Apache >= 2.4SSLCompression off SSLSessionTickets OffSSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)"SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

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

Ändern Sie die standardmäßige virtuelle Apache SSL-Hostdatei

Als nächstes ändern wir /etc/apache2/sites-available/default-ssl.conf, die standardmäßige virtuelle Apache SSL-Hostdatei. Wenn Sie eine andere Serverblockdatei verwenden, ersetzen Sie den Namen in den folgenden Befehlen.

Bevor wir weiter gehen, sichern wir die ursprüngliche Datei des virtuellen SSL-Hosts:

sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

Öffnen Sie nun die virtuelle SSL-Hostdatei, um Anpassungen vorzunehmen:

sudo nano /etc/apache2/sites-available/default-ssl.conf

Wenn die meisten Kommentare entfernt sind, sollte die virtuelle Hostdatei standardmäßig folgendermaßen aussehen:

<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # BrowserMatch "MSIE " \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost></IfModule>

Wir werden einige kleinere Anpassungen an der Datei vornehmen. Wir werden die normalen Dinge, die wir anpassen möchten, in einer virtuellen Hostdatei festlegen (ServerAdmin-E-Mail-Adresse, ServerName usw.), passen Sie die SSL-Direktiven so an, dass sie auf unsere Zertifikat- und Schlüsseldateien verweisen, und kommentieren Sie einen Abschnitt aus, der Kompatibilität für ältere Browser bietet.

Nachdem Sie diese Änderungen vorgenommen haben, sollte Ihr Serverblock folgendermaßen aussehen:

<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin [email protected] ServerName server_domain_or_IP DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE " \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost></IfModule>

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

(Empfohlen) Ändern Sie die unverschlüsselte virtuelle Hostdatei so, dass sie auf HTTPS umgeleitet wird

Der Server stellt sowohl unverschlüsselten HTTP- als auch verschlüsselten HTTPS-Datenverkehr bereit. Für eine bessere Sicherheit wird in den meisten Fällen empfohlen, HTTP automatisch auf HTTPS umzuleiten. Wenn Sie diese Funktionalität nicht wünschen oder benötigen, können Sie diesen Abschnitt sicher überspringen.

Um die unverschlüsselte virtuelle Hostdatei so anzupassen, dass der gesamte SSL-verschlüsselte Datenverkehr umgeleitet wird, können wir die Datei /etc/apache2/sites-available/000-default.conf öffnen:

sudo nano /etc/apache2/sites-available/000-default.conf

Innerhalb der VirtualHost Konfigurationsblöcke müssen wir nur eine Redirect Direktive hinzufügen, die den gesamten Datenverkehr auf die SSL-Version der Site verweist:

<VirtualHost *:80> . . . Redirect "/" "https://your_domain_or_IP/" . . .</VirtualHost>

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

Schritt 3: Anpassen der Firewall

Wenn Sie die Firewall ufw aktiviert haben, wie in den erforderlichen Handbüchern empfohlen, müssen Sie möglicherweise die Einstellungen anpassen, um SSL-Datenverkehr zuzulassen. Glücklicherweise registriert Apache bei der Installation einige Profile mit ufw .

Wir können die verfügbaren Profile sehen, indem wir Folgendes eingeben:

sudo ufw app list

Sie sollten eine Liste wie diese sehen:

Output
Available applications: Apache Apache Full Apache Secure OpenSSH

Sie können die aktuelle Einstellung anzeigen, indem Sie Folgendes eingeben:

sudo ufw status

Wenn Sie zuvor nur regulären HTTP-Datenverkehr zugelassen haben, könnte Ihre Ausgabe folgendermaßen aussehen:

Output
Status: activeTo Action From-- ------ ----OpenSSH ALLOW AnywhereApache ALLOW AnywhereOpenSSH (v6) ALLOW Anywhere (v6)Apache (v6) ALLOW Anywhere (v6)

Um zusätzlich HTTPS-Datenverkehr einzulassen, können wir das „Apache Full“ -Profil zulassen und dann das redundante „Apache“ -Profil löschen.:

 
sudo ufw allow 'Apache Full'
 
sudo ufw delete allow 'Apache'
 

Ihr Status sollte jetzt so aussehen:

sudo ufw status

Output
Status: activeTo Action From-- ------ ----OpenSSH ALLOW AnywhereApache Full ALLOW AnywhereOpenSSH (v6) ALLOW Anywhere (v6)Apache Full (v6) ALLOW Anywhere (v6)

Schritt 4: Aktivieren Sie die Änderungen in Apache

Nachdem wir unsere Änderungen vorgenommen und unsere Firewall angepasst haben, können wir die SSL- und Header-Module in Apache aktivieren, unseren SSL-fähigen virtuellen Host aktivieren und Apache neu starten.

Wir können mod_ssl, das Apache SSL-Modul, und mod_headers, die von einigen Einstellungen in unserem SSL-Snippet benötigt werden, mit dem Befehl a2enmod aktivieren:

 
sudo a2enmod ssl
 
sudo a2enmod headers
 

Als nächstes können wir unseren virtuellen SSL-Host mit dem Befehl a2ensite aktivieren:

sudo a2ensite default-ssl

Wir müssen auch unsere ssl-params.conf -Datei aktivieren, um die von uns festgelegten Werte einzulesen:

sudo a2enconf ssl-params

An dieser Stelle sind unsere Website und die erforderlichen Module aktiviert. Wir sollten überprüfen, ob unsere Dateien keine Syntaxfehler enthalten. Wir können dies tun, indem wir eingeben:

sudo apache2ctl configtest

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

Output
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this messageSyntax OK

Die erste Zeile ist nur eine Nachricht, die Ihnen mitteilt, dass die Direktive ServerName nicht global festgelegt ist. Wenn Sie diese Nachricht entfernen möchten, können Sie ServerName auf den Domänennamen oder die IP-Adresse Ihres Servers in /etc/apache2/apache2.conf . Dies ist optional, da die Nachricht keinen Schaden anrichtet.

Wenn Ihre Ausgabe Syntax OK enthält, weist Ihre Konfigurationsdatei keine Syntaxfehler auf. Wir können Apache sicher neu starten, um unsere Änderungen zu implementieren:

sudo systemctl restart apache2

Schritt 5: Verschlüsselung testen

Jetzt können wir unseren SSL-Server testen.

Öffnen Sie Ihren Webbrowser und geben Sie https:// gefolgt vom Domänennamen oder der IP Ihres Servers in die Adressleiste ein:

https://server_domain_or_IP

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

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

Sie sollten zu Ihrer Site weitergeleitet werden. Wenn Sie in die Adressleiste des Browsers schauen, sehen Sie ein Schloss mit einem „x“ darüber. In diesem Fall bedeutet dies nur, dass das Zertifikat nicht validiert werden kann. Es verschlüsselt immer noch Ihre Verbindung.

Wenn Sie Apache so konfiguriert haben, dass HTTP auf HTTPS umgeleitet wird, können Sie auch überprüfen, ob die Umleitung korrekt funktioniert:

http://server_domain_or_IP

Wenn dies zu demselben Symbol führt, bedeutet dies, dass Ihre Weiterleitung korrekt funktioniert hat.

Schritt 6: Wechseln zu einer permanenten Weiterleitung

Wenn Ihre Weiterleitung korrekt funktioniert hat und Sie sicher sind, dass Sie nur verschlüsselten Datenverkehr zulassen möchten, sollten Sie den unverschlüsselten virtuellen Apache-Host erneut ändern, um die Weiterleitung dauerhaft zu machen.

Öffnen Sie Ihre Serverblock-Konfigurationsdatei erneut:

sudo nano /etc/apache2/sites-available/000-default.conf

Suchen Sie die Zeile Redirect, die wir zuvor hinzugefügt haben. Fügen Sie dieser Zeile permanent hinzu, wodurch die Umleitung von einer temporären 302-Umleitung zu einer permanenten 301-Umleitung geändert wird:

<VirtualHost *:80> . . . Redirect permanent "/" "https://your_domain_or_IP/" . . .</VirtualHost>

Speichern und schließen Sie die Datei.

Überprüfen Sie Ihre Konfiguration auf Syntaxfehler:

sudo apache2ctl configtest

Wenn Sie bereit sind, starten Sie Apache neu, um die Umleitung dauerhaft zu machen:

sudo systemctl restart apache2

Fazit

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