So erstellen Sie ein selbstsigniertes SSL-Zertifikat für Apache in Debian 10

Einführung

TLS (Transport Layer Security) und sein Vorgänger SSL (Secure Sockets Layer) sind Webprotokolle, mit denen der normale Datenverkehr in einem geschützten, verschlüsselten Wrapper verpackt wird.

Mithilfe dieser Technologie können Server Datenverkehr sicher zwischen Servern und Clients senden, ohne dass 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 Apache-Webserver unter Debian 10 einrichten.

Voraussetzungen

Bevor Sie beginnen, sollten Sie einen Nicht-Root-Benutzer mit den Rechten "+ sudo +" konfiguriert haben. Sie können lernen, wie Sie ein solches Benutzerkonto einrichten, indem Sie unseren Initial Server Setup with Debian 10 folgen.

Außerdem muss der Apache-Webserver installiert sein. Wenn Sie einen kompletten LAMP-Stack (Linux, Apache, MariaDB, PHP) auf Ihrem Server installieren möchten, können Sie unserem Leitfaden unter https://www.digitalocean.com/community/tutorials/how-to-install-linux folgen -apache-mariadb-php-lamp-stack-on-debian-10 [LAMP unter Debian 10 einrichten]. Wenn Sie nur den Apache-Webserver benötigen, überspringen Sie die Schritte zu PHP und MariaDB.

Wenn Sie diese 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 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.

Wir können mit OpenSSL in einem einzigen Befehl ein selbstsigniertes Paar aus Schlüssel und Zertifikat 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. 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 (Certificate Signing Request) von X.509 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 *: Hierdurch 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 Apache, um die Datei ohne Benutzereingriff lesen zu können, wenn der Server startet. 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 Abschnitt "+ rsa: 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 abgelegt werden soll, die wir erstellen.

  • * -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. * Die wichtigste Zeile ist die, die den allgemeinen Namen `+ anfordert (z. Server-FQDN oder IHR Name) + `. Sie müssen den Domänennamen eingeben, der Ihrem Server zugeordnet ist, oder wahrscheinlich die öffentliche IP-Adresse Ihres Servers. *

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

OutputCountry Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Beide von Ihnen erstellten Dateien werden in den entsprechenden Unterverzeichnissen unter "+ / etc / ssl +" abgelegt.

Schritt 2 - Konfigurieren von 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 auszunutzen.

Wir werden einige Anpassungen an unserer Konfiguration vornehmen:

  1. Wir werden ein Konfigurations-Snippet erstellen, um sichere SSL-Standardeinstellungen festzulegen.

  2. Wir werden die enthaltene SSL Apache Virtual Host-Datei so ändern, dass sie auf unsere generierten SSL-Zertifikate verweist.

  3. (Empfohlen) Die unverschlüsselte Virtual Host-Datei wird so geändert, dass Anforderungen automatisch an den verschlüsselten Virtual Host umgeleitet werden.

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

Erstellen eines Apache-Konfigurations-Snippets mit starken Verschlüsselungseinstellungen

Zunächst 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 + benennen, um den Zweck zu verdeutlichen:

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

Um Apache SSL sicher einzurichten, verwenden wir die Empfehlungen von Remy van Elst auf der Website https://cipherli.st [Cipherli.st]. Diese Website wurde entwickelt, um benutzerfreundliche Verschlüsselungseinstellungen für gängige Software bereitzustellen.

Für unsere Zwecke können wir die bereitgestellten Einstellungen vollständig kopieren. Wir nehmen nur eine kleine Änderung vor und deaktivieren den Header "+ Strict-Transport-Security +" (HSTS).

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 aktiviert, aber Sie können dies ändern, wenn Sie sicher sind, dass Sie die Auswirkungen verstehen.

Fügen Sie die folgende Konfiguration in die Datei + ssl-params.conf + ein, die wir geöffnet haben:

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

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On


Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
SSLSessionTickets Off

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

Ändern der standardmäßigen virtuellen Apache SSL-Hostdatei

Als nächstes ändern wir "+ / etc / apache2 / sites-available / default-ssl.conf +", die Standarddatei für den virtuellen Apache SSL-Host. Wenn Sie eine andere Serverblockdatei verwenden, ersetzen Sie deren Namen in den folgenden Befehlen.

Bevor wir fortfahren, sichern wir die ursprüngliche SSL Virtual Host-Datei:

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

Öffnen Sie nun die SSL Virtual Host-Datei, um Anpassungen vorzunehmen:

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

Wenn die meisten Kommentare entfernt sind, sollte der Virtual Host-Block standardmäßig so aussehen:

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

<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>

       </VirtualHost>
</IfModule>

Wir werden einige kleinere Anpassungen an der Datei vornehmen. Wir werden die normalen Einstellungen für eine Virtual Host-Datei (ServerAdmin-E-Mail-Adresse, Servername usw.) vornehmen und die SSL-Anweisungen so anpassen, dass sie auf unsere Zertifikat- und Schlüsseldateien verweisen. Wenn Sie ein anderes Dokumentenstammverzeichnis verwenden, müssen Sie auch hier die Direktive "+ DocumentRoot +" aktualisieren.

Nach diesen Änderungen sollte Ihr Serverblock ungefähr so ​​aussehen:

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

<IfModule mod_ssl.c>
       <VirtualHost _default_:443>
               ServerAdmin


               DocumentRoot /var/www/html

               ErrorLog ${APACHE_LOG_DIR}/error.log
               CustomLog ${APACHE_LOG_DIR}/access.log combined

               SSLEngine on

               SSLCertificateFile      /etc/ssl/certs/
               SSLCertificateKeyFile /etc/ssl/private/

               <FilesMatch "\.(cgi|shtml|phtml|php)$">
                               SSLOptions +StdEnvVars
               </FilesMatch>
               <Directory /usr/lib/cgi-bin>
                               SSLOptions +StdEnvVars
               </Directory>

       </VirtualHost>
</IfModule>

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

(Empfohlen) Ändern der HTTP-Hostdatei zur Umleitung auf HTTPS

Derzeit wird der Server sowohl unverschlüsselten HTTP- als auch verschlüsselten HTTPS-Datenverkehr bereitstellen. In den meisten Fällen wird empfohlen, HTTP aus Sicherheitsgründen automatisch zu HTTPS umzuleiten. Wenn Sie diese Funktionalität nicht möchten oder benötigen, können Sie diesen Abschnitt ohne Bedenken überspringen.

Um die unverschlüsselte Virtual Host-Datei so anzupassen, dass der gesamte zu verschlüsselnde Datenverkehr umgeleitet wird, öffnen Sie die Datei + / etc / apache2 / sites-available / 000-default.conf +:

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

Fügen Sie in den Konfigurationsblöcken "+ VirtualHost " eine Direktive " Redirect +" hinzu, die den gesamten Datenverkehr auf die SSL-Version der Site verweist:

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

<VirtualHost *:80>
       . . .

       Redirect "/" "https:///"

       . . .
</VirtualHost>

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

Dies sind alle Konfigurationsänderungen, die Sie an Apache vornehmen müssen. Als nächstes werden wir diskutieren, wie Firewall-Regeln mit "+ ufw +" aktualisiert werden, um verschlüsselten HTTPS-Verkehr zu Ihrem Server zuzulassen.

Schritt 3 - Anpassen der Firewall

Wenn Sie die Firewall "+ ufw " aktiviert haben, wie in den vorausgesetzten Handbüchern empfohlen, müssen Sie möglicherweise die Einstellungen anpassen, um SSL-Datenverkehr zuzulassen. Glücklicherweise enthält ` ufw +` bei der Installation unter Debian 10 App-Profile, mit denen Sie Ihre Firewall-Einstellungen anpassen können

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

sudo ufw app list

Sie sollten eine solche Liste mit den folgenden vier Profilen am unteren Rand der Ausgabe sehen:

OutputAvailable applications:
. . .
 WWW
 WWW Cache
 WWW Full
 WWW Secure
. . .

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

sudo ufw status

Wenn Sie früher nur normalen HTTP-Datenverkehr zugelassen haben, sieht Ihre Ausgabe möglicherweise folgendermaßen aus:

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
WWW                        ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
WWW (v6)                   ALLOW       Anywhere (v6)

Wenn Sie zusätzlich HTTPS-Verkehr zulassen möchten, lassen Sie das Profil "WWW Full" zu und löschen Sie dann die überflüssige Berechtigung für das Profil "WWW":

sudo ufw allow 'WWW Full'
sudo ufw delete allow 'WWW'

Ihr Status sollte jetzt so aussehen:

sudo ufw status
OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)

Wenn Ihre Firewall so konfiguriert ist, dass HTTPS-Datenverkehr zugelassen wird, können Sie mit dem nächsten Schritt fortfahren. Hier wird erläutert, wie Sie einige Module und Konfigurationsdateien aktivieren, damit SSL ordnungsgemäß funktioniert.

Schritt 4 - Aktivieren der Ä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, um diese Änderungen zu übernehmen.

Aktivieren Sie "+ mod_ssl ", das Apache-SSL-Modul und " mod_headers ", die von einigen Einstellungen in unserem SSL-Snippet benötigt werden, mit dem Befehl " a2enmod +":

sudo a2enmod ssl
sudo a2enmod headers

Aktivieren Sie als Nächstes Ihren virtuellen SSL-Host mit dem Befehl "+ a2ensite +":

sudo a2ensite default-ssl

Sie müssen auch Ihre "+ ssl-params.conf" -Datei aktivieren, um die von Ihnen festgelegten Werte einzulesen:

sudo a2enconf ssl-params

Zu diesem Zeitpunkt sind die Site und die erforderlichen Module aktiviert. Wir sollten überprüfen, ob unsere Dateien Syntaxfehler enthalten. Tun Sie dies, indem Sie Folgendes eingeben:

sudo apache2ctl configtest

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

OutputSyntax OK

Solange Ihre Ausgabe "+ Syntax OK +" enthält, enthält Ihre Konfigurationsdatei keine Syntaxfehler, und Sie können Apache problemlos neu starten, um die Änderungen zu implementieren:

sudo systemctl restart apache2

Damit ist Ihr selbstsigniertes SSL-Zertifikat fertig. Sie können jetzt testen, ob Ihr Server den Datenverkehr ordnungsgemäß verschlüsselt.

Schritt 5 - Testen der Verschlüsselung

Jetzt können Sie Ihren SSL-Server testen.

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

https://

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

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 * ADVANCED * und dann auf den angegebenen Link, um trotzdem zu Ihrem Host zu gelangen:

image: https://assets.digitalocean.com/articles/apache_ssl_1604/warning_override.png [Selbstsignierte Überschreibung durch Apache]

Sie sollten zu Ihrer Site weitergeleitet werden. Wenn Sie in die Adressleiste des Browsers schauen, sehen Sie ein Schloss mit einem "x" oder einem ähnlichen "nicht sicheren" Hinweis. 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 zu HTTPS umgeleitet wird, können Sie auch prüfen, ob die Umleitung ordnungsgemäß funktioniert:

http://

Wenn das gleiche Symbol angezeigt wird, hat Ihre Umleitung ordnungsgemäß funktioniert. Die zuvor erstellte Umleitung ist jedoch nur eine temporäre Umleitung. Wenn Sie die Umleitung zu HTTPS dauerhaft machen möchten, fahren Sie mit dem letzten Schritt fort.

Schritt 6 - Zu einer permanenten Umleitung wechseln

Wenn Ihre Umleitung ordnungsgemäß 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 Umleitung dauerhaft zu machen.

Öffnen Sie die Konfigurationsdatei für den Serverblock erneut:

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

Suchen Sie die zuvor hinzugefügte Zeile "+ Redirect ". Fügen Sie dieser Zeile " permanent +" hinzu, wodurch die Umleitung von einer temporären 302-Umleitung in eine permanente 301-Umleitung geändert wird:

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

<VirtualHost *:80>
       . . .

       Redirect  "/" "https:///"

       . . .
</VirtualHost>

Speichern und schließen Sie die Datei.

Überprüfen Sie Ihre Konfiguration auf Syntaxfehler:

sudo apache2ctl configtest

Wenn dieser Befehl keine Syntaxfehler meldet, starten Sie Apache neu:

sudo systemctl restart apache2

Dadurch wird die Umleitung permanent, und Ihre Site wird nur Datenverkehr über HTTPS bedienen.

Fazit

Sie haben Ihren Apache-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.