In diesem Tutorial sehen wir, wie Sie ein Let’s Encrypt SSL-Zertifikat erstellen, installieren und verwalten und den Apache-Webserver entsprechend konfigurieren, um Internetnutzern eine durch https gesicherte Website anzubieten.
Contents
Über Let’s Encrypt
Let’s encrypt ist eine Open-Source-Initiative der ISRG, deren zusammengefasstes Ziel es ist, jedem kostenlos SSL-Zertifikate anzubieten, um eine Website über https abzusichern.
Wir müssen zugeben, dass Let’s Encrypt die kleine Revolution der letzten 2 Jahre ist. Jeder fängt an. Und dies aus 2 Hauptgründen: Die Tatsache, dass es einfach UND kostenlos ist, und zumal Google auf ein sicheres Web drängt.
Zum Beispiel die Entwicklung der Forschung von „Let’s Encrypt“ in den letzten 5 Jahren:
Kontext
Wir werden also sehen, wie wir Let’s Encrypt auf unserem Apache-Server bereitstellen, jedoch auf besondere Weise.
Tatsächlich bietet die Certbot-Software, die wir verwenden werden, verschiedene Plugins und Assistenten, einschließlich für Apache, mit denen Sie automatisch Zertifikate installieren, Apache-Konfigurationen ändern usw. All dies automatisch.
Es wird für die größte Anzahl perfekt sein, muss gesagt werden.
Aber ich persönlich mag: 1 / wissen, was los ist, 2 / wissen, wie es funktioniert, 3 / die Kontrolle über die Einstellungen behalten.
Und vor allem hasse ich es, dass jede Software ihr eigenes Ding macht, meine Konfigurationen ändert, Dienste neu startet usw … Umso mehr auf einem Server in der Produktion.
Indem ich es manuell mache, weiß ich zumindest, wenn etwas schief geht, wo ich suchen und eingreifen muss.
Für dieses Tutorial gehe ich davon aus, dass wir eine klassische Apache-Konfiguration haben und es keine Sonderfälle gibt.
Ich gehe auch davon aus, dass auf unserem Server mehrere Sites gehostet werden und eine oder mehrere von ihnen von http zu https wechseln.
Beachten Sie schließlich, dass dieses Tutorial auf einem Debian 7 und Apache 2.2 erstellt wurde. Unter Debian 8 und Apache 2.4 funktioniert es genau gleich.
Voraussetzungen
Haben einen Apache – 2 – Server installiert ist und dass es funktionsfähig ist mit SSL und Rewrite – Mods aktiviert.
Um zu überprüfen, ob sie aktiv sind, führen Sie Folgendes aus:
root @ g: ~ # apachectl -M Geladene Module: ... rewrite_module (freigegeben) ssl_module (freigegeben) ... Syntax OK
Sie sehen in Fettdruck die 2 geladenen Module.
Wenn nicht, führen Sie nach:
root @ g: ~ # a2enmod ssl Aktivierungsmodul ssl. Siehe /usr/share/doc/apache2.2-common/README.Debian.gz zur Konfiguration von SSL und zum Erstellen selbstsignierter Zertifikate. Um die neue Konfiguration zu aktivieren, müssen Sie Folgendes ausführen: Dienst Apache2 Neustart root @ g: ~ # a2enmod rewrite Aktivieren des Modul-Rewrites. Um die neue Konfiguration zu aktivieren, müssen Sie Folgendes ausführen: Dienst Apache2 Neustart root @ g: ~ # service Apache2 Neustart [ok] Neustart des Webservers: apache2 ... wartet.
Denken Sie daran, Apache neu zu starten, sobald die Module aktualisiert wurden.
Methodik
Die Installation erfolgt in 6 Hauptschritten:
- Installieren Sie das Certbot-Programm, das die Zertifikate generiert
- Erstellen Sie ein erstes Let’s Encrypt-Zertifikat
- Ändern Sie die Konfiguration eines Apache-vhosts, um die Zertifikate zu integrieren
- Überprüfen Sie die Konfiguration und die Qualität der SSL-Einstellung
- Erfahren Sie, wie Sie ein Zertifikat erneuern
- Erfahren Sie, wie Sie ein Zertifikat widerrufen
Certbot installieren
Zu Beginn laden wir Certbot herunter und machen es ausführbar:
wget https://dl.eff.org/certbot-auto chmod a + x certbot-auto
Es ist eine einfache Datei, speichern Sie sie an einem geeigneten Ort. Im /opt zum Beispiel.
Führen Sie es zum ersten Mal „leer“ aus, damit es seine Abhängigkeiten herunterlädt und sich selbst installiert.
./certbot-auto
Wenn es fertig ist, bietet es Ihnen an, mit der Erstellungsarbeit zu beginnen. Aufhören. Wir werden später darauf zurückkommen.
Die Hauptdateien werden installiert. Alles ist drin /etc/letsencrypt .
In diesem Ordner gibt es 3 Speicherordner für die Zertifikate::
archive Basisordner, in dem die Zertifikate gespeichert werden
live : Ordner mit aktiven Zertifikaten. Symbolische Links zum Archivordner.
renewal : Ordner, der Informationen zur Zertifikatserneuerung enthält.
Erstellung des Let’s Encrypt-Zertifikats
Führen Sie den folgenden Befehl aus und stellen Sie sicher, dass Sie die Werte durch die richtigen Informationen ersetzen:
./certbot-auto certonly --webroot --webroot-path /srv/www/domain.tld/ --domain domain.tld --domain www.domain.tld --email [email protected]
Erklärungen:
certonly : Es wird nur die Erstellung des Zertifikats angefordert.
--webroot : Wir verwenden das Webroot-Plugin, das einfach Dateien in den Ordner hinzufügt, der über definiert wurde --webroot-path .
--webroot-path : der Pfad zu Ihrem Apache „DocumentRoot“. Certbot legt seine Dateien $DocumentRoot/.well-known/ für Tests und Überprüfungen ab
--domain : den zu zertifizierenden Domainnamen.
--email : die Adresse, die Let’s Encrypt-Benachrichtigungen erhält. Hauptsächlich als Erinnerung daran, das Zertifikat zu erneuern, wenn es soweit ist.
Erstellungsoptionen
In Bezug auf die Erstellungsparameter ist das Wesentliche da. Ich lade Sie ein, das Dokument zu konsultieren, um die anderen verfügbaren Optionen zu sehen.
Wir könnten das Zertifikat möglicherweise härten, indem wir es in 4096 Bit (standardmäßig 2048 Bit) übergeben, indem wir das Flag hinzufügen, --rsa-key-size 4096 aber es ist ein wenig unverhältnismäßig. Es liegt an Ihnen.
Um auf die Flagge zurückzukommen --domain , sei vorsichtig! Let’s encrypt verwaltet die Wildcard derzeit nicht. Denken Sie daher unbedingt daran, die Domain UND die Subdomain „www“ zu deklarieren. Wenn Sie sich in einer klassischen Konfiguration befinden, ist Ihre Site offensichtlich von http://domain.tld und http://www.domain.tld erreichbar.
Zertifikate erhalten
Wenn Sie Ihre Zertifikate suchen, befinden sie sich in den Ordnern: Sie haben 4 Dateien für jedes Zertifikat: /etc/letsencrypt/live/domain.tld/
privkey.pem : Der private Schlüssel Ihres Zertifikats. Unter allen Umständen vertraulich zu bleiben und niemandem unter allen Umständen mitzuteilen. Du wurdest gewarnt!
cert.pem : Das Serverzertifikat und für Apache-Versionen <2.4.8 anzugeben. Was hier bei uns der Fall ist.
chain.pem : Die anderen Zertifikate, AUSSER dem Serverzertifikat. Zum Beispiel Zwischenzertifikate. Auch für Apache-Versionen <2.4.8.
fullchain.pem : Logischerweise alle Zertifikate. Die Verkettung von cert.pem und chain.pem . Diesmal zu verwenden für Apache-Versionen> = 2.4.8.
Der Fall von Zertifikaten für verschiedene Subdomains
Für eine vereinfachte Verwaltung Ihrer Zertifikate rate ich Ihnen, nicht alle Ihre Subdomains in ein und dasselbe Zertifikat zu integrieren.
Wenn Sie mehrere verschiedene Sites auf verschiedenen Subdomains und damit auf verschiedenen vhost verwalten: zum Beispiel blog.domain.com und forum.domain.com, erstellen Sie zu diesem Zeitpunkt 2 separate Zertifikate. Auf diese Weise wird im Falle einer Änderung, Verschiebung oder Löschung einer Ihrer Websites alles unterteilt und es gibt keine Auswirkungen auf die anderen Zertifikate.
Integrieren Sie das Let’s Encrypt-Zertifikat in Apache
Nun, da wir das Zertifikat haben, müssen wir es nur noch in den Apache vhost integrieren und so Inhalte in https ausliefern.
Zunächst müssen Sie den vhost bearbeiten, um alle notwendigen Einstellungen zu deklarieren.
Ich gehe davon aus, dass wir uns hier in einem klassischen Fall befinden, in dem unsere Site sowohl von domain.com als auch von www.domain.com aus zugänglich ist. Der große Klassiker.
Modifikation des vhost
Im Moment sieht der vhost ungefähr so aus:
<VirtualHost *: 80> ServerName domain.tld ServerAlias www.domain.tld DocumentRoot / Pfad / zu / Dateien LogLevel-Warnung ErrorLog $ {APACHE_LOG_DIR} /domain.tld-error.log CustomLog $ {APACHE_LOG_DIR} /domain.tld-access.log kombiniert RewriteEngine Ein RewriteCond% {HTTP_HOST}! ^ Www . [NC] RewriteRule ^ (. *) $ Http: //www.% {HTTP_HOST} $ 1 [R = 301, L] <Verzeichnis / Pfad / zu / Dateien> Optionen -Indizes -MultiViews ZulassenAlles überschreiben Bestellung erlauben, verweigern von allen zulassen </Verzeichnis> </VirtualHost> Dabei spielt das Detail dieser Konfiguration keine Rolle. Wichtig ist, dass die Site sowohl von domain.tld als auch von www.domain.tld aus zugänglich ist und dass, wenn jemand nach http://domain.tld: fragt, eine automatische 301-Weiterleitung auf die Subdomain http erfolgt ://www.domain.com.
Wir werden dasselbe in der https-Version reproduzieren. Ich biete folgende neue Konfiguration an:
<VirtualHost *: 80> ServerName domain.tld ServerAlias www.domain.tld RewriteEngine an RewriteCond% {HTTPS}! Ein RewriteRule (. *) Https: //% {HTTP_HOST}% {REQUEST_URI} </VirtualHost> <VirtualHost *: 443> ServerName domain.tld ServerAlias www.domain.tld DocumentRoot /path/to/files/www.domain.tld <Verzeichnis / Pfad / zu / Dateien> Optionen -Indizes ZulassenAlles überschreiben Bestellung erlauben, verweigern von allen zulassen </Verzeichnis> SSLEngine an SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem SSLProtokoll alle -SSLv2 -SSLv3 SSLHonorCipherOrder on SSL-Komprimierung aus SSLOptions + StrictRequire SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES256-GCM-SHA384: DHE-RSA-SHA256-AES .126: DHE-RSA-SHA256-AES .126 -DSS-AES128-GCM-SHA256: kEDH + AESGCM: ECDHE-RSA-AES128-SHA256: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA: ECDHE-ECDSA-AES128HE-RSA: ECD -AES256-SHA38 : ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA: ECDHE-ECDSA-AES256-SHA: DHE-RSA-AES128-SHA256: DHE-RSA-AES128-SHA: DHE128-DSS-AES -SHA256: DHE -RSA-AES256-SHA256: DHE-DSS-AES256-SHA: DHE-RSA-AES256-SHA: AES128-GCM-SHA256: AES256-GCM-SHA384: AES128-SHA256: AES256-SHA256: : AES256-SHA: AES: CAMELLIA: DES-CBC3-SHA:! ANULL:! ENULL:! EXPORT:! DES:! RC4:! MD5:! PSK:! AECDH:! EDH-DSS-DES-CBC3-SHA:!! EDH-RSA-DES- CBC3-SHA: KRB5-DES-CBC3-SHA Header immer Strict-Transport-Security setzen "max-age = 31536000; includeSubDomains" LogLevel-Warnung ErrorLog $ {APACHE_LOG_DIR} /www.domain.tld-error.log CustomLog $ {APACHE_LOG_DIR} /www.domain.tld-access.log kombiniert </VirtualHost> Wir sehen jetzt, dass wir 2 vhost in einem vhost haben! Eine für Port 80 und http (<VirtualHost *: 80>) und eine für Port 443 und https (<VirtualHost *: 443>).
Der erste Port 80 vhost macht nichts anderes als eine automatische Umleitung vom http auf das https. WENN jemand fragt.
Ansonsten gibt es nichts. Kein Root-Dokument, keine Protokolle usw. Es ist eine Wahl. Da ich möchte, dass 100% des Datenverkehrs über https laufen, sind alle zusätzlichen Informationen unnötig, beginnend mit den Protokollen.
Dann gibt es die Deklaration des https-vhost. Wie Sie sehen, ist der erste Teil identisch mit der Ersteinrichtung, und es gibt keinen Grund, warum es anders sein sollte. Auf der anderen Seite gibt es im zweiten Teil alle SSL-Deklarationen:
SSLEngine an SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem SSLProtokoll alle -SSLv2 -SSLv3 SSLHonorCipherOrder on SSL-Komprimierung aus SSLOptions + StrictRequire SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256 [...] # Hinweis: Es wird auch empfohlen, HTTP Strict Transport Security (HSTS) zu aktivieren. Header immer Strict-Transport-Security setzen "max-age = 31536000; includeSubDomains"
Erklärungen:
SSLEngine on : Aktivierung des SSL-Moduls
SSLCertificateFile : Pfad zur Datei cert.pem
SSLCertificateKeyFile : Pfad zur Datei privkey.pem
SSLCertificateChainFile : Pfad zur Datei chain.pem
SSLProtocol : Aktiviert die Unterstützung aller SSL-Versionen außer SSLv2 und v3, die nicht mehr ausreichend sicher sind.
SSLHonorCipherOrder : Wenn aktiviert, erzwingt der Server seine Protokolleinstellungen und nicht den Browser des Clients.
SSLCompression : Aktiviert die SSL-Komprimierung
SSLOptions +StrictRequire : Erfordert eine strikte SSL-Verbindung
SSLCipherSuite : Liste der verfügbaren Verschlüsselungsalgorithmen
Header always set Strict-Transport-Security : oder HSTS. Zeigt Browsern an, dass nur https unterstützt wird und erzwingt dies durch Einstellen einer (langen) Anwendungsdauer. Ziel: „Man-in-the-Middle“-Angriffe vermeiden.
Überprüfen der vhost-Konfiguration
Jetzt müssen wir unsere Konfiguration testen:
apachectl configtest
Logischerweise sollten Sie ein „Syntax OK“ zurückgeben. Wenn dies der Fall ist, muss Apache neu laden / neu starten, damit die Änderungen berücksichtigt werden.
Dienst Apache2 Neustart
Und dort haben Sie möglicherweise den folgenden Fehler:
[....] Webserver-Konfiguration wird neu geladen: apache2 [Sa. Okt 08 11:17:49 2016] [warn] _default_ VirtualHost Überlappung auf Port 443, ersteres hat Vorrang. ... warten [Sa. Okt 08 11:17:49 2016] [warn] _default_ VirtualHost Überlappung auf Port 443, ersteres hat Vorrang OK
Wir haben gerade einen neuen Vhost hinzugefügt, der auf Port 443 lauscht, aber wir haben auch den “default-ssl” -Vhost, der bereits vorhanden ist. Also 2 vhost, 2 Sites für den gleichen Port ist nicht in Ordnung. Apache muss spezifische Angaben erhalten, damit er weiß, was er verwenden soll.
Im Kontext von namensbasierten Servern fügen Sie diese Anweisung zur Datei hinzu ports.conf , die standardmäßig wie folgt aussieht:
<IfModule mod_ssl.c> # Wenn Sie hier NameVirtualHost *: 443 hinzufügen, müssen Sie auch ändern # die VirtualHost-Anweisung in /etc/apache2/sites-available/default-ssl # zu <VirtualHost *: 443> # Server Name Indication für SSL benannte virtuelle Hosts ist derzeit nicht # von MSIE unter Windows XP unterstützt. Hören 443 </IfModule>
Wir werden die Anweisung hinzufügen, die NameVirtualHost *:443 uns Folgendes gibt:
<IfModule mod_ssl.c> # Wenn Sie hier NameVirtualHost *: 443 hinzufügen, müssen Sie auch ändern # die VirtualHost-Anweisung in /etc/apache2/sites-available/default-ssl # zu <VirtualHost *: 443> # Server Name Indication für SSL benannte virtuelle Hosts ist derzeit nicht # von MSIE unter Windows XP unterstützt. Hören 443 NameVirtualHost *: 443 </IfModule>
Sie werden feststellen, dass die Dinge gut gemacht sind, schauen Sie sich die Kommentare an. NameVirtualHost *:443 Uns wird gesagt, dass wir, wenn wir hier hinzufügen , auch die vhost default-ssl ändern müssen, um sie <VirtualHost _default_:443> durch zu ersetzen <VirtualHost *:443> .
Wir bearbeiten die Datei /etc/apache2/sites-available/default-ssl in den ersten 2 Zeilen, die sind:
IfModule mod_ssl.c> <VirtualHost _default_: 443> ...
Und wer wird dann:
IfModule mod_ssl.c> <VirtualHost *: 443> ...
Wir starten Apache ein letztes Mal neu und es sollte keine Probleme mehr geben. Gehen Sie zu Ihrer Website und Sie können überprüfen, ob alles mit aktiviertem https funktioniert und funktioniert. Und vor allem ohne Vorwarnung.
Sicherheitskontrolle
Letzter Punkt bei der Konfiguration: die Qualität unserer SSL-Verbindungssicherheit.
Abhängig von den Parametern, die unter anderem in unserem vhost definiert sind, ist die Sicherheit möglicherweise nicht optimal. Es besteht daher potenziell die Gefahr eines Identitätsdiebstahls oder sogar eines Angriffs vom Typ „Man-in-the-Middle“.
Mit den oben definierten Parametern gibt es kein Problem. Sie sollten eine „A+“-Bewertung erhalten. Dies sind die Standardeinstellungen für Let’s Encrypt. Aber dieser Hinweis ist nicht ohne Rücksicht.
Beginnen Sie mit dem Testen Ihrer Site im SSL-Servertest: https://www.ssllabs.com/ssltest/
Wenn Sie dieses Tutorial befolgt haben, sollten Sie das berühmte “A +” haben:
Jetzt ist alles eine Frage des Kompromisses.
Je mehr Sie Ihre Regeln verschärfen, desto besser werden Sie, desto mehr Kompatibilität verlieren Sie mit älteren Browsern. IE8 auf XP zum Beispiel.
Schauen Sie sich also vorher Ihre Besuchsstatistiken genau an, um die Konfigurationen Ihrer Besucher zu kennen und entsprechend anzupassen.
Sicherheit ist gut, aber wenn Sie Ihre Besucher verlieren, ist das auch keine Lösung.
Erneuern Sie ein Let’s Encrypt-Zertifikat
An dieser Stelle haben wir ein Let’s Encrypt-Zertifikat installiert und unseren Server gut konfiguriert.
Sie sollten wissen, dass die Lebensdauer des Let’s Encrypt-Zertifikats nur 90 Tage, also 3 Monate beträgt.
Wir werden die Befehle sehen, um es manuell und automatisch zu erneuern.
Um Ihr Zertifikat manuell zu erneuern, führen Sie einfach den Befehl aus:
./certbot-auto renew
Dieser Befehl fragt die Let’s Encrypt-Server ab und sie werden feststellen, ob Ihr Zertifikat erneuert werden muss oder nicht.
Beachten Sie, dass Let’s encrypt es nicht verlängert, solange Sie nicht innerhalb der letzten 30 Tage vor dem Ablaufdatum sind. Sie können aber bei Bedarf die Verlängerung erzwingen, indem Sie das Flag hinzufügen --force-renewal .
Bei der Verlängerung können Sie auch die Änderung der Stärke des RSA-Schlüssels anfordern. Wenn Sie Ihr Zertifikat mit 2048 Bit erstellt haben, können Sie es in 4096 ändern und umgekehrt. Dazu fügen Sie das Flag hinzu --rsa-key-size 4096 .
Der Befehl wäre dann:
./certbot-auto renew --rsa-key-size 4096 --force-renewal
Dies sind die wichtigsten Optionen. Je nach Bedarf stehen weitere zur Verfügung. Auch hier lade ich Sie ein, die Dokumentation zu konsultieren.
Um die Erneuerung zu beenden, ist es wichtig darauf hinzuweisen, dass der Befehl ./certbot-auto renew alle auf dem Computer verfügbaren Let’s Encrypt-Zertifikate erneuert.
Derzeit ist es nicht möglich, eine bestimmte Domain zu verlängern. Dieser wird wahrscheinlich in Zukunft verfügbar sein.
Zertifikat automatisch erneuern
Jetzt werden wir sehen, wie Sie die Erneuerung unseres Zertifikats mit automatisieren können CRON .
Persönlich habe ich ein kleines Skript erstellt, das ich in den Ordner cron.monthly . Basic. Und zwar „monatlich“, denn wie oben gesehen wird das Zertifikat nur in den letzten 30 Tagen erneuert. Es ist daher nicht erforderlich, jede Woche und noch weniger jeden Tag anzuwenden.
Beispieldatei renew-certificate.sh :
#! / bin / bash / Pfad / zu / certbot-auto renew
Sie können die Flagge hinzufügen, --quiet wenn Sie keine Rücksendung der Bestellung wünschen.
In jedem Fall keine Panik, da wir unsere E-Mail-Adresse beim Erstellen des Zertifikats hinzugefügt haben. Wenn es ein Problem gibt, werden Sie per E-Mail benachrichtigt.
Ein Let’s Encrypt-Zertifikat widerrufen
Letzter Betreff: Löschung, Widerruf eines Zertifikats. Wenn Sie es nicht mehr brauchen.
Wir verwenden den Befehl, certbot-auto revoke indem wir ihm eine Reihe von Parametern übergeben: das zu widerrufende Zertifikat, den Pfad zum privaten Schlüssel und den Pfad zum Zertifikat:
./certbot-auto widerrufen --domain domain.tld --cert-path /etc/letsencrypt/live/domain.tld --key-path /etc/letsencrypt/live/domain.tld
Ihr Zertifikat wird widerrufen. Aber das ist nicht genug.
Wenn Sie sich Ihre /etc/letsencrypt/live/, /archive/ und /renewal/Ordner ansehen, finden Sie immer noch die Ordner/Dateien darin.
Um alles sauber zu halten, löschen wir alles mit dem folgenden Befehl:
rm -rf /etc/letsencrypt/live/domain.tld/ && rm -rf /etc/letsencrypt/archive/domain.tld/ && rm /etc/letsencrypt/renewal/domain.tld.conf
Apache-Konfiguration wiederherstellen
Letzte Änderung, stellen Sie die Konfiguration des Apache vhost in seiner ursprünglichen Konfiguration wieder her und entfernen Sie vor allem alle Verweise auf SSL und Zertifikate.
Beachten Sie hierzu einfach die Grundkonfiguration weiter oben auf dieser Seite. Ich überlasse es dir.
Fazit
Ich hoffe, dass dieses Tutorial für Sie nützlich ist und Sie ein wenig mehr über die Funktionsweise von Let’s Encrypt und insgesamt die Integration eines SSL-Zertifikats für Apache erfahren haben. Denn für diesen letzten Teil, Let’s Encrypt oder anderen, ist es genau dasselbe.
Wenn Sie Kommentare oder Fragen haben, können Sie gerne einen Kommentar posten.
