Tutorial: SSL/TLS unter Amazon Linux 2 konfigurieren - Amazon Elastic Compute Cloud

Tutorial: SSL/TLS unter Amazon Linux 2 konfigurieren

Secure Sockets Layer/Transport Layer Security (SSL/TLS) erstellt einen verschlüsselten Kanal zwischen einem Webserver und einem Webclient, der Daten in der Übertragung davor schützt, abgefangen zu werden. In diesem Tutorial wird erläutert, wie Sie manuell Support für SSL/TLS auf einer einzelnen Instance mit Amazon Linux 2 und Apache-Webserver hinzufügen können. Wenn Sie Services in handelsüblicher Qualität bereitstellen möchten, stellt der AWS Certificate Manager eine gute Option dar, der hier jedoch nicht behandelt wird.

Aus historischen Gründen wird die Webverschlüsselung häufig einfach als SSL bezeichnet. Auch wenn Webbrowser SSL weiterhin unterstützen, ist das Nachfolgeprotokoll TLS weniger anfällig für Angriffe. Amazon Linux 2 deaktiviert standardmäßig die serverseitige Unterstützung für alle Versionen von SSL. Organe für Sicherheitsstandards betrachten TLS 1.0 als unsicher und sowohl TLS 1.0 als auch TLS 1.1 werden vom IETF demnächst formell als veraltet eingestuft. Dieses Tutorial enthält Empfehlungen, die ausschließlich auf der Aktivierung von TLS 1.2 basieren. (Es ist ein neueres TLS 1.3-Protokoll vorhanden, aber es ist nicht standardmäßig auf Amazon Linux 2 installiert.) Weitere Informationen zum aktualisierten Verschlüsselungsstandard finden Sie unter RFC 7568 und RFC 8446.

Dieses Tutorial bezieht sich auf TLS als moderne Web-Verschlüsselung.

Wichtig

Diese Verfahren sind für die Verwendung mit Amazon Linux 2 gedacht. Es wird auch angenommen, dass Sie mit einer neuen Amazon EC2-Instance beginnen. Wenn Sie versuchen, einen LAMP-Webserver auf einer Instance mit einer anderen Distribution einzurichten, oder wenn Sie eine ältere, vorhandene Instance verwenden, funktionieren einige Prozeduren in diesem Tutorial möglicherweise nicht. Weitere Informationen über LAMP-Webserver auf Ubuntu finden Sie in der Ubuntu-Community-Dokumentation unter dem Thema ApacheMySQLPHP. Informationen zu Red Hat Enterprise Linux finden Sie im Thema Webserver im Kundenportal.

Voraussetzungen

Bevor Sie mit diesem Tutorial beginnen, führen Sie die folgenden Schritte aus:

  • Starten Sie eine EBS-gestützte Amazon Linux 2-Instance. Weitere Informationen finden Sie unter Schritt 1: Starten einer Instance.

  • Konfigurieren Sie Ihre Sicherheitsgruppen so, dass Verbindungen auf den folgenden TCP-Ports akzeptiert werden:

    • SSH (Port 22)

    • HTTP (Port 80)

    • HTTPS (Port 443)

    Weitere Informationen finden Sie unter Autorisieren von eingehendem Datenverkehr für Linux-Instances.

  • Installieren Sie den Apache-Webserver. Schrittweise Anleitungen finden Sie im Tutorial: Installieren eines LAMP-Webservers auf Amazon Linux 2. Es werden nur das httpd-Paket und die zugehörigen Abhängigkeiten benötigt, sodass die Anleitungen mit PHP und MariaDB ignoriert werden können.

  • Zum Identifizieren und Authentifizieren von Websites verwendet die Public Key-Infrastruktur (PKI) TLS das Domain Name System (DNS). Wenn Sie Ihre EC2-Instance zum Hosten einer öffentlichen Website verwenden möchten, müssen Sie einen Domänennamen für Ihren Webserver registrieren oder einen vorhandenen Domänennamen an Ihren Amazon EC2-Host übertragen. Dafür sind zahlreiche Drittanbieterservices für die Domänenregistrierung und das DNS-Hosting verfügbar. Oder Sie verwenden Amazon Route 53.

Schritt 1: Aktivieren von TLS auf dem Server

Im folgenden Verfahren wird die Einrichtung von TLS in Amazon Linux 2 mit einem selbstsignierten digitalen Zertifikat erläutert.

Anmerkung

Ein selbstsigniertes Zertifikat kann zu Testzwecken, jedoch nicht für die Produktion verwendet werden. Wenn Sie Ihr selbstsigniertes Zertifikat im Internet bereitstellen, werden den Besuchern Ihrer Website Sicherheitswarnungen angezeigt.

So aktivieren Sie TLS auf einem Server

  1. Verbinden Sie sich mit der Instance und stellen Sie sicher, dass Apache ausgeführt wird.

    [ec2-user ~]$ sudo systemctl is-enabled httpd

    Wenn der zurückgegebene Wert nicht „enabled“ (aktiviert) ist, starten Sie Apache und richten es so ein, dass es bei jedem Neustart des Systems gestartet wird.

    [ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd
  2. Um sicherzustellen, dass alle Ihre Softwarepakete aktuell sind, führen Sie ein schnelles Softwareupdate auf Ihrer Instance aus. Dieser Vorgang kann einige Minuten dauern. Es ist jedoch wichtig, sicherzustellen, dass Sie über die aktuellen Sicherheitsaktualisierungen und Fehlerbehebungen verfügen.

    Anmerkung

    Mit der Option -y werden die Updates installiert, ohne um Bestätigung zu bitten. Wenn Sie die Aktualisierungen vor der Installation überprüfen möchten, können Sie diese Option auslassen.

    [ec2-user ~]$ sudo yum update -y
  3. Wenn Ihre Instance jetzt aktuell ist, fügen Sie TLS-Unterstützung hinzu, indem Sie das Apache-Modul mod_ssl installieren.

    [ec2-user ~]$ sudo yum install -y mod_ssl

    Ihre Instance verfügt nun über die folgenden Dateien, mit denen Sie Ihren sicheren Server konfigurieren und ein Zertifikat zum Testen erstellen:

    • /etc/httpd/conf.d/ssl.conf

      Die Konfigurationsdatei für mod_ssl. Diese enthält Richtlinien, die Apache mitteilen, wo Verschlüsselungsschlüssel und Zertifikate, die zu genehmigenden TLS-Protokollversionen und die zu akzeptierenden Verschlüsselungschiffren gefunden werden können.

    • /etc/pki/tls/certs/make-dummy-cert

      Ein Skript zum Generieren eines selbstsignierten X.509-Zertifikats und privaten Schlüssels für Ihren Server-Host. Dieses Zertifikat ist nützlich zum Testen, ob Apache ordnungsgemäß für die Verwendung von TLS eingerichtet ist. Da es keinen Identitätsnachweis liefert, sollte es in der Produktion nicht verwendet werden. Wenn es in der Produktion eingesetzt wird, löst es Warnungen in Web-Browsern aus.

  4. Führen Sie das Skript aus, um ein selbstsigniertes Dummy-Zertifikat und einen Schlüssel für die Überprüfung zu generieren.

    [ec2-user ~]$ cd /etc/pki/tls/certs sudo ./make-dummy-cert localhost.crt

    Dadurch wird eine neue Datei localhost.crt im Verzeichnis /etc/pki/tls/certs/ erstellt. Der angegebene Dateiname entspricht dem Standard, der in der SSLCertificateFile-Direktive in /etc/httpd/conf.d/ssl.conf zugewiesen ist.

    Die Datei enthält sowohl ein selbstsigniertes Zertifikat als auch den privaten Schlüssel des Zertifikats. Für Apache müssen das Zertifikat und der Schlüssel im PEM-Format sein. Diese bestehen aus Base64-kodierten ASCII-Zeichen, die durch „BEGIN” und „END”-Zeilen eingerahmt werden, wie im folgendem, verkürzten Beispiel dargestellt.

    -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q 3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT ... 56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs 27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo 4QQvAqOa8UheYeoXLdWcHaLP -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE-----

    Die Dateinamen und Erweiterungen dienen der Einfachheit und haben keinerlei Auswirkungen auf die Funktion. Sie können beispielsweise ein Zertifikat mit cert.crt, cert.pem oder einem beliebigen anderen Dateinamen benennen, solange die zugehörige Richtlinie in der Datei ssl.conf denselben Namen verwendet.

    Anmerkung

    Wenn Sie die TLS-Standarddateien mit Ihren eigenen benutzerdefinierten Dateien ersetzen, müssen diese das PEM-Format aufweisen.

  5. Öffnen Sie die /etc/httpd/conf.d/ssl.conf-Datei und kommentieren Sie die folgende Zeile aus, da das selbstsignierte Dummy-Zertifikat auch den Schlüssel enthält. Wenn Sie diese Zeile nicht auskommentieren, bevor Sie den nächsten Schritt abschließen, kann der Apache-Service nicht gestartet werden.

    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
  6. Starten Sie Apache erneut.

    [ec2-user ~]$ sudo systemctl restart httpd
    Anmerkung

    Stellen Sie wie zuvor beschrieben sicher, dass auf den TCP-Port 443 über Ihre EC2-Instance zugegriffen werden kann.

  7. Ihr Apache-Webserver sollte jetzt HTTPS (sicheres HTTP) über Port 443 unterstützen. Dies können Sie testen, indem Sie die IP-Adresse oder den vollständig qualifizierten Domänennamen Ihrer EC2-Instance mit dem Präfix https:// in einer Browser-URL-Leiste eingeben.

    Da Sie eine Verbindung mit einer Website mit einem selbstsignierten, nicht vertrauenswürdigen Host-Zertifikat herstellen, zeigt Ihr Browser möglicherweise eine Reihe von Sicherheitswarnungen an. Setzen Sie die Warnmeldungen außer Kraft und fahren Sie mit der Website fort.

    Wenn die Apache-Standardtestseite geöffnet wird, bedeutet dies, dass Sie TLS erfolgreich auf Ihrem Server konfiguriert haben. Alle Daten, die zwischen dem Browser und dem Server übertragen werden, sind nun verschlüsselt.

    Anmerkung

    Damit den Besuchern keine Warnbildschirme angezeigt werden, müssen Sie ein vertrauenswürdiges, CA-signiertes Zertifikat abrufen, das nicht nur verschlüsselt, sondern Sie auch öffentlich als den Besitzer der Website authentifiziert.

Schritt 2: Abrufen eines CA-signierten Zertifikats

Sie können das folgende Verfahren verwenden, um ein CA-signiertes Zertifikat zu erhalten:

  • Erzeugen Sie aus dem privaten Schlüssel eine Zertifikatssignierungsanforderung (Certificate Signing Request, CSR)

  • Senden Sie die CSR an eine Zertifizierungsstelle (CA)

  • Sie erhalten ein signiertes Host-Zertifikat

  • Konfigurieren Sie Apache, um das Zertifikat zu verwenden

Ein selbstsigniertes TLS-X.509-Host-Zertifikat ist kryptologisch mit einem CA-signierten Zertifikat identisch. Der Unterschied liegt im sozialen, nicht im mathematischen Bereich. Eine CA validiert zumindest den Besitzer einer Domäne, bevor ein Zertifikat für einen Antragsteller ausgegeben wird. Jeder Webbrowser enthält eine Liste von CAs, die der Browseranbieter dafür als vertrauenswürdig erachtet. Ein X.509-Zertifikat besteht hauptsächlich aus einem öffentlichen Schlüssel, der Ihrem privaten Serverschlüssel entspricht, sowie einer Signatur durch die CA, die kryptografisch an den öffentlichen Schlüssel gebunden ist. Wenn ein Browser eine Verbindung mit einem Webserver über HTTPS herstellt, stellt der Server ein Zertifikat für den Browser bereit, das anhand der Liste der vertrauenswürdigen CAs überprüft wird. Wenn sich der Aussteller auf der Liste befindet oder über eine Vertrauenskette aus anderen vertrauenswürdigen Ausstellern zugänglich ist, handelt der Browser einen schnellen verschlüsselten Datenkanal mit dem Server aus und lädt die Seite.

Wichtig

Im Allgemeinen sind Zertifikate aufgrund der Arbeit im Zusammenhang mit der Validierung der Anforderungen kostenpflichtig, deshalb lohnt es sich, die Angebote zu vergleichen. Eine Liste bekannter CAs finden Sie unter dmoztools.net. Einige CAs bieten grundlegende Zertifikate kostenlos an. Die namhafteste dieser CAs ist das Let's Encrypt-Projekt, das auch die Automatisierung des Prozesses zur Erstellung und Verlängerung von Zertifikaten unterstützt. Weitere Informationen zur Verwendung von Let's Encrypt als CA finden Sie unter Zertifikatsautomatisierung: Let's Encrypt mit Certbot auf Amazon Linux 2.

Dem Host-Zertifikat liegt der Schlüssel zugrunde. Seit 2019 empfehlen Regierungs- und Branchengruppen eine Schlüssel(-Modul)-Mindestgröße von 2048 Bits für RSA-Schlüssel, die Dokumente bis 2030 schützen sollen. Die von OpenSSL in Amazon Linux 2 generierte Modul-Standardgröße beträgt 2048 Bits, was für die Verwendung in CA-signierten Zertifikaten geeignet ist. Im folgenden Verfahren ist ein optionaler Schritt für diejenigen vorgesehen, die einen benutzerdefinierten Schlüssel verwenden möchten, z.B. einen mit einem größeren Modul oder mit einem anderen Verschlüsselungsalgorithmus.

Diese Anweisungen zum Erwerb eines CA-signierten Host-Zertifikats funktioniert nur, wenn Sie eine registrierte und gehostete DNS-Domäne besitzen.

So rufen Sie ein CA-signierten Zertifikat ab

  1. Verbinden Sie sich mit der Instance und navigieren Sie zu /etc/pki/tls/private/. Dies ist das Verzeichnis, in dem Sie den privaten Schlüssel des Servers für TLS speichern. Wenn Sie lieber Ihren vorhandenen Host-Schlüssel zum Generieren der CSR verwenden möchten, fahren Sie mit Schritt 3 fort.

  2. (Optional) Generieren Sie einen neuen privaten Schlüssel. Hier sind einige Beispiele für Schlüsselkonfigurationen. Jeder der resultierenden Schlüssel funktioniert mit Ihrem Webserver, aber sie unterscheiden sich durch den Grad und die Art der Sicherheit, die sie implementieren.

    • Beispiel 1: Erstellen Sie einen Standard-RSA-Hostschlüssel. Bei der erstellten Datei, custom.key, handelt es sich um einen privaten 2048-Bit-RSA-Schlüssel.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key
    • Beispiel 2: Erstellen Sie einen stärkeren RSA-Schlüssel mit einem größeren Modul. Bei der erstellten Datei, custom.key, handelt es sich um einen privaten 4096-Bit-RSA-Schlüssel.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096
    • Beispiel 3: Erstellen Sie einen 4096-Bit-verschlüsselten RSA-Schlüssel mit Passwortschutz. Die resultierende Datei, custom.key, ist ein privater 4096-Bit-RSA-Schlüssel, der mit der AES-128-Verschlüsselung verschlüsselt ist.

      Wichtig

      Die Verschlüsselung des Schlüssels bietet höhere Sicherheit. Da für einen verschlüsselten Schlüssel ein Passwort erforderlich ist, können von diesem abhängige Services jedoch nicht automatisch gestartet werden. Jedes Mal, wenn Sie diesen Schlüssel verwenden, müssen Sie das Passwort (im vorhergehenden Beispiel „abcde12345“) über eine SSH-Verbindung bereitstellen.

      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096
    • Beispiel 4: Erstellen Sie einen Schlüssel mit einer Nicht-RSA-Verschlüsselung. Die RSA-Kryptografie kann aufgrund der Größe ihrer öffentlichen Schlüssel, die auf dem Produkt aus zwei großen Primzahlen basieren, relativ langsam sein. Es ist jedoch möglich, Schlüssel für TLS zu erstellen, die andere Verschlüsselungschiffren als RSA verwenden. Schlüssel, die auf der Mathematik von Ellipsenkurven basieren, sind kleiner und bieten eine schnellere Rechenleistung bei der Bereitstellung einer gleichwertigen Sicherheitsebene.

      [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey

      Das Ergebnis ist ein privater Ellipsenkurvenschlüssel mit 256-Bit, der prime256v1 verwendet, einer „benannten Kurve“, die OpenSSL unterstützt. Die kryptografische Stärke ist hierbei laut NIST etwas höher als bei einem 2048-Bit-RSA-Schlüssel.

      Anmerkung

      Nicht alle CAs bieten denselben Support für Ellipsenkurven-basierte Schlüssel wie für RSA-Schlüssel.

    Stellen Sie sicher, dass der neue private Schlüssel stark einschränkende Eigentümerschaft und Berechtigungen aufweist (Eigentümer=root, Gruppe=root, Lesen/Schreiben nur für Eigentümer). Führen Sie die Befehle wie im folgenden Beispiel veranschaulicht aus.

    [ec2-user ~]$ sudo chown root:root custom.key [ec2-user ~]$ sudo chmod 600 custom.key [ec2-user ~]$ ls -al custom.key

    Die vorhergehenden Befehle erzeugen das folgende Ergebnis.

    -rw------- root root custom.key

    Wenn Sie einen zufriedenstellenden Schlüssel erstellt und konfiguriert haben, können Sie eine CSR erstellen.

  3. Erstellen Sie eine CSR mit Ihrem bevorzugten Schlüssel. Im folgenden Beispiel wird custom.key verwendet.

    [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

    OpenSSL öffnet einen Dialog und fordert Sie auf, die in der folgenden Tabelle aufgeführten Informationen einzugeben. Alle Felder außer Common Name (Allgemeiner Name) sind bei einem grundlegenden, domänenvalidierten Host-Zertifikat optional.

    Name Beschreibung Beispiel
    Ländername Die zweistellige ISO-Abkürzung für Ihr Land US (=United States, Vereinigte Staaten)
    State or Province Name Der Name des Bundesstaats oder der Provinz, in dem bzw. der sich Ihre Organisation befindet. Dieser Name darf nicht abgekürzt werden. Washington
    Locality Name Der Standort Ihrer Organisation, wie beispielsweise eine Stadt. Seattle
    Name der Organisation Der vollständige, offizielle Name Ihrer Organisation. Kürzen Sie den Namen Ihrer Organisation nicht ab. Beispielunternehmen
    Organizational Unit Name Zusätzliche Informationen zu Ihrer Organisation, sofern vorhanden. Beispielabteilung
    Common Name

    Dieser Wert muss genau der Webadresse entsprechen, die Ihre Benutzer in einen Browser eingeben sollen. Dies ist in der Regel ein Domänenname mit einem vorangestellten Hostnamen oder Alias in der Form www.example.com. Bei Tests mit einem selbstsignierten Zertifikat und ohne DNS-Auflösung kann dieser allgemeine Name nur aus dem Hostnamen bestehen. CAs bieten darüber hinaus teurere Zertifikate an, die Platzhalternamen wie beispielsweise *.example.com akzeptieren.

    www.example.com
    Email Address Die E-Mail-Adresse des Serveradministrators. someone@example.com

    Zuletzt fordert OpenSSL Sie zur Eingabe eines optionalen Challenge-Passworts auf. Dieses Passwort gilt nur für die CSR und für Transaktionen zwischen Ihnen und Ihrer CA. Befolgen Sie daher die Empfehlungen Ihrer CA diesbezüglich und in Bezug auf das andere optionale Feld, den optionalen Unternehmensnamen. Das CSR-Challenge-Passwort wirkt sich nicht auf den Serverbetrieb aus.

    Die erstellte Datei csr.pem enthält Ihren öffentlichen Schlüssel, die digitale Signatur Ihres öffentlichen Schlüssels und die von Ihnen eingegebenen Metadaten.

  4. Übermitteln Sie die CSR an eine CA. Dies besteht in der Regel daraus, Ihre CSR-Datei in einem Texteditor zu öffnen und den Inhalt in ein Webformular zu kopieren. Zu diesem Zeitpunkt werden Sie möglicherweise aufgefordert, einen oder mehrere alternative „Subject”-Namen (SANs) bereitzustellen, die auf dem Zertifikat angegeben werden sollen. Wenn www.example.com der allgemeine Name ist, wäre example.com ein guter SAN und umgekehrt. Ein Besucher Ihrer Website, der einen dieser Namen eingibt, wird eine fehlerfreie Verbindung sehen. Wenn dies auf Ihrem CA-Webformular möglich ist, geben Sie den allgemeinen Namen in der Liste der SANs an. Einige CAs fügen diesen automatisch ein.

    Nachdem Ihre Anfrage genehmigt wurde, erhalten Sie ein neues, von der CA unterzeichnetes Host-Zertifikat. Möglicherweise werden Sie auch dazu aufgefordert, eine Zwischenzertifikatsdatei herunterzuladen, die zusätzliche Zertifikate enthält, welche zum Fertigstellen der Vertrauenskette der CA benötigt werden.

    Anmerkung

    Ihre CA kann Ihnen Dateien in verschiedenen Formaten für verschiedene Zwecke zusenden. Für dieses Tutorial sollten Sie nur eine Zertifikatsdatei im PEM-Format verwenden, die in der Regel (aber nicht immer) mit der Dateierweiterung .pem oder .crt gekennzeichnet ist. Wenn Sie sich nicht sicher sind, welche Datei Sie verwenden sollen, öffnen Sie die Dateien mit einem Texteditor und suchen Sie die Datei, die einen oder mehrere Blöcke enthält, die mit der folgenden Zeile beginnen.

    - - - - -BEGIN CERTIFICATE - - - - -

    Die Datei sollte darüber hinaus mit der folgenden Zeile enden.

    - - - -END CERTIFICATE - - - - -

    Sie können die Datei auch in der Befehlszeile testen, wie im Folgenden gezeigt.

    [ec2-user certs]$ openssl x509 -in certificate.crt -text

    Vergewissern Sie sich, dass diese Zeilen in der Datei erscheinen. Verwenden Sie keine Dateien, die mit .p7b, .p7c oder ähnlichen Dateiendungen enden.

  5. Platzieren Sie ein neues CA-signiertes Zertifikat und alle Zwischenzertifikate im /etc/pki/tls/certs-Verzeichnis.

    Anmerkung

    Es gibt mehrere Möglichkeiten, Ihr neues Zertifikat in Ihre EC2-Instance hochzuladen. Der einfachste und informativste Weg ist jedoch, einen Texteditor (vi, nano oder notepad usw.) sowohl auf Ihrem lokalen Computer als auch auf Ihrer Instance zu öffnen, und dann den Dateiinhalt zwischen ihnen zu kopieren und einzufügen. Sie benötigen Root [sudo]-Berechtigungen, wenn Sie diese Operationen auf der EC2-Instance ausführen. Auf diese Weise können Sie sofort erkennen, ob es Probleme mit Berechtigungen oder mit dem Pfad gibt. Achten Sie jedoch darauf, beim Kopieren der Inhalte keine zusätzlichen Zeilen einzufügen und die Inhalte nicht zu ändern.

    Prüfen Sie im Verzeichnis /etc/pki/tls/certs, dass die Einstellungen zu Dateieigentümerschaft, Gruppe und Berechtigung mit den stark einschränkenden Amazon Linux 2-Standards übereinstimmen (Eigentümer=root, Gruppe=root, Lesen/Schreiben nur für Eigentümer). Das folgende Beispiel zeigt die zu verwendenden Befehle.

    [ec2-user certs]$ sudo chown root:root custom.crt [ec2-user certs]$ sudo chmod 600 custom.crt [ec2-user certs]$ ls -al custom.crt

    Diese Befehle sollten das folgende Ergebnis hervorrufen.

    -rw------- root root custom.crt

    Die Berechtigungen für die Zwischenzertifikatsdatei sind weniger strikt (Eigentümer=root, Gruppe=root, Eigentümer kann schreiben, Gruppe kann lesen, die restliche Welt kann lesen). Das folgende Beispiel zeigt die zu verwendenden Befehle.

    [ec2-user certs]$ sudo chown root:root intermediate.crt [ec2-user certs]$ sudo chmod 644 intermediate.crt [ec2-user certs]$ ls -al intermediate.crt

    Diese Befehle sollten das folgende Ergebnis hervorrufen.

    -rw-r--r-- root root intermediate.crt
  6. Legen Sie den privaten Schlüssel, den Sie zum Erstellen der CSR verwendet haben, in das Verzeichnis /etc/pki/tls/private/.

    Anmerkung

    Es gibt mehrere Möglichkeiten, Ihren benutzerdefinierten Schlüssel in Ihre EC2-Instance hochzuladen. Der einfachste und informativste Weg ist jedoch, einen Texteditor (vi, nano oder notepad usw.) sowohl auf Ihrem lokalen Computer als auch auf Ihrer Instanz zu öffnen, und dann den Dateiinhalt zwischen ihnen zu kopieren und einzufügen. Sie benötigen Root [sudo]-Berechtigungen, wenn Sie diese Operationen auf der EC2-Instance ausführen. Auf diese Weise können Sie sofort erkennen, ob es Probleme mit Berechtigungen oder mit dem Pfad gibt. Achten Sie jedoch darauf, beim Kopieren der Inhalte keine zusätzlichen Zeilen einzufügen und die Inhalte nicht zu ändern.

    Verwenden Sie die folgenden Befehle innerhalb des /etc/pki/tls/private-Verzeichnisses, um sicherzustellen, dass die Einstellungen zu Dateibesitzer, Gruppe und Berechtigung mit den stark einschränkenden Amazon Linux 2-Standardwerten übereinstimmen (Besitzer=root, Gruppe=root, Lesen/Schreiben nur Besitzer).

    [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ ls -al custom.key

    Diese Befehle sollten das folgende Ergebnis hervorrufen.

    -rw------- root root custom.key
  7. Bearbeiten Sie die Datei /etc/httpd/conf.d/ssl.conf so, dass sie Ihr neues Zertifikat und Ihre Schlüsseldateien widerspiegelt.

    1. Geben Sie den Pfad und Dateinamen des CA-signierten Host-Zertifikats im SSLCertificateFile-Verzeichnis von Apache an.

      SSLCertificateFile /etc/pki/tls/certs/custom.crt
    2. Wenn Sie eine Zwischenzertifikatsdatei erhalten haben (intermediate.crt in diesem Beispiel), stellen Sie den entsprechenden Pfad und Dateinamen über das SSLCACertificateFile-Verzeichnis in Apache bereit:

      SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
      Anmerkung

      Einige CAs kombinieren das Host-Zertifikat und die Zwischenzertifikate in einer einzelnen Datei, wodurch das SSLCACertificateFile-Verzeichnis überflüssig wird. Informieren Sie sich in den von Ihrer CA bereitgestellten Anweisungen.

    3. Geben Sie den Pfad und Dateinamen des privaten Schlüssels (in diesem Beispiel custom.key) in der SSLCertificateKeyFile-Direktive von Apache an:

      SSLCertificateKeyFile /etc/pki/tls/private/custom.key
  8. Speichern Sie /etc/httpd/conf.d/ssl.conf und starten Sie Apache erneut.

    [ec2-user ~]$ sudo systemctl restart httpd
  9. Testen Sie Ihren Server, indem Sie Ihren Domainnamen in eine Browser-URL-Leiste mit dem Präfix https:// eingeben. Ihr Browser sollte die Testseite über HTTPS laden, ohne Fehler zu erzeugen.

Schritt 3: Testen und Verstärken der Sicherheitskonfiguration

Wenn Ihre TLS betriebsbereit und öffentlich zugänglich ist, sollten Sie testen, wie sicher sie wirklich ist. Dies ist ganz einfach möglich mithilfe von Online-Services wie beispielsweise Qualys SSL Labs, der eine kostenlose und gründliche Analyse Ihrer Sicherheitseinrichtung durchführt. Basierend auf den Ergebnissen entscheiden Sie sich möglicherweise dafür, die Standard-Sicherheitskonfiguration zu verstärken, indem Sie kontrollieren, welche Protokolle akzeptiert werden sollen, welche Chiffren Sie bevorzugen und welche ausgeschlossen werden soll. Um weitere Informationen zu erhalten, sehen Sie sich an, wie Qualys seine Skalen gestaltet.

Wichtig

Reale Tests sind außerordentlich wichtig für die Sicherheit Ihres Servers. Kleine Konfigurationsfehler führen möglicherweise zu ernsten Sicherheitsverstößen und Datenverlusten. Da sich die empfohlenen Sicherheitsmaßnahmen aufgrund von Forschungen und neuartigen Bedrohungen ständig ändern, sind regelmäßige Sicherheitsprüfungen wichtig für eine gute Serveradministration.

Geben Sie auf der Website von Qualys SSL Labs den vollständigen Domänennamen Ihres Servers ein, in der Form www.example.com. Nach ungefähr zwei Minuten erhalten Sie eine Note (von A bis F) für Ihre Website sowie eine detaillierte Auflistung der Ergebnisse. Die folgende Tabelle fasst den Bericht für eine Domäne mit identischen Einstellungen wie die Standard-Apache-Konfiguration auf Amazon Linux 2 und mit einem Standard-Certbot-Zertifikat zusammen.

Gesamtbewertung B
Zertifikat 100 %
Protokollunterstützung 95 %
Schlüsselaustausch 70 %
Chiffrestärke 90 %

Obwohl die Übersicht zeigt, dass die Konfiguration größtenteils intakt ist, zeigt der detaillierte Bericht einige potenzielle Probleme, die hier nach Schweregrad geordnet aufgelistet werden:

Die RC4-Chiffre kann bestimmten älteren Browsern verwendet werden. Eine Chiffre ist der mathematische Kern eines Verschlüsselungsalgorithmus. RC4, eine schnelle Chiffre zur Verschlüsselung von TLS-Daten-Streams, ist für gravierende Schwachstellen bekannt. Wenn Sie nicht sehr gute Gründe haben, veraltete Browser zu unterstützen, sollten Sie dies deaktivieren.

Alte TLS-Versionen werden unterstützt. Die Konfiguration unterstützt TLS 1.0 (bereits veraltet) und TLS 1.1 (demnächst veraltet). Seit 2018 wurde nur TLS 1.2 empfohlen.

Forward Secrecy wird nicht vollständig unterstützt. Forward Secrecy ist eine Funktion von Algorithmen zur Verschlüsselung mit temporären (flüchtigen) Sitzungsschlüsseln, die von dem privaten Schlüssel abgeleitet werden. In der Praxis bedeutet dies, dass Angreifen HTTPS-Daten nicht entschlüsseln können, selbst wenn sie den langfristigen privaten Schlüssel eines Webservers besitzen.

So korrigieren Sie die TLS-Konfiguration und machen Sie zukunftssicher

  1. Öffnen Sie die Konfigurationsdatei /etc/httpd/conf.d/ssl.conf in einem Texteditor und kommentieren Sie die folgende Zeile aus, indem Sie „#“ am Anfang der Zeile eingeben.

    #SSLProtocol all -SSLv3
  2. Fügen Sie die folgende Richtlinie hinzu:

    #SSLProtocol all -SSLv3 SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    Diese Richtlinie deaktiviert die SSL-Versionen 2 und 3 explizit sowie auch die TLS-Versionen 1.0 und 1.1. Der Server akzeptiert jetzt keine verschlüsselten Verbindungen mit Clients, die eine andere Version als TLS 1.2 verwenden. Der Verbose-Wortlaut in der Richtlinie teilt einem menschlichen Leser genauer mit, wofür der Server konfiguriert ist.

    Anmerkung

    Durch eine solche Deaktivierung der TLS-Versionen 1.0 und 1.1 wird ein kleiner Prozentsatz von veralteten Webbrowsern daran gehindert, auf Ihre Website zuzugreifen.

So ändern Sie die Liste der zulässigen Chiffren

  1. Suchen Sie in der Konfigurationsdatei /etc/httpd/conf.d/ssl.conf den Abschnitt mit der SSLCipherSuite-Richtlinie und kommentieren Sie die bestehende Zeile aus, indem Sie „#“ am Anfang der Zeile eingeben.

    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
  2. Geben Sie explizite Verschlüsselungssammlungen und eine Verschlüsselungsreihenfolge an, die Forward Secrecy unterstützt und unsichere Verschlüsselungen vermeidet. Die hier verwendete Richtlinie SSLCipherSuite basiert auf der Ausgabe aus dem Mozilla SSL-Konfigurationsgenerator, der eine TLS-Konfiguration an die spezifische Software, die auf Ihrem Server ausgeführt wird, angepasst wird. (Weitere Informationen finden Sie in der nützlichen Ressource Security/Server Side TLS von Mozilla.) Bestimmen Sie zunächst Ihre Apache- und OpenSSL-Versionen, indem Sie die Ausgabe der folgenden Befehle verwenden.

    [ec2-user ~]$ yum list installed | grep httpd [ec2-user ~]$ yum list installed | grep openssl

    Wenn die zurückgegebenen Informationen beispielsweise Apache 2.4.34 und OpenSSL 1.0.2 sind, geben wir diese in den Generator ein. Wenn Sie das „moderne“ Kompatibilitätsmodell auswählen, wird dadurch eine SSLCipherSuite-Richtlinie erstellt, die die Sicherheit aggressiv durchsetzt, aber dennoch für die meisten Browser funktioniert. Wenn die Modemkonfiguration von der Software nicht unterstützt wird, können Sie Ihre Software aktualisieren oder stattdessen die „fortgeschrittene“ Konfiguration wählen.

    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

    Die ausgewählten Chiffren weisen ECDHE im Namen auf, eine Abkürzung für Elliptic Curve Diffie-Hellman Ephemeral. Der Begriff Ephemeralität (Flüchtigkeit) gibt die "Forward Secrecy (Folgenlosigkeit)" an. Als Nebenprodukt unterstützten diese Chiffren RC4 nicht.

    Wir empfehlen, eine explizite Liste von Chiffren zu verwenden, anstatt sich auf Standardeinstellungen oder knappe Richtlinien zu verlassen, deren Inhalt nicht sichtbar ist.

    Kopieren Sie die erzeugte Richtlinie in /etc/httpd/conf.d/ssl.conf.

    Anmerkung

    Obwohl dies hier zur besseren Lesbarkeit auf mehrere Zeilen verteilt ist, muss die Richtlinie in einer einzelnen Zeile mit nur einem Doppelpunkt (ohne Leerstellen) aufgeführt werden, wenn sie nach /etc/httpd/conf.d/ssl.conf kopiert wird.

  3. Entfernen Sie schließlich die Kommentarzeichen in der folgende Zeile, indem Sie das „#“ am Anfang der Zeile löschen.

    #SSLHonorCipherOrder on

    Diese Richtlinie zwingt den Server, hochrangige Chiffren zu bevorzugen, einschließlich derjenigen (in diesem Fall), die Forward Secrecy unterstützen. Wenn diese Richtlinie aktiviert ist, versucht der Server, eine hochgradig sichere Verbindung herzustellen, bevor er auf Chiffren mit geringerer Sicherheit zurückgreift.

Nach Abschluss dieser beiden Verfahren speichern Sie die Änderungen in /etc/httpd/conf.d/ssl.conf und starten Sie Apache neu.

Wenn Sie die Domäne auf Qualys SSL Labs erneut testen, sollten Sie sehen, dass die Schwachstelle in Bezug auf RC4 und andere Warnungen nicht mehr vorhanden sind und dass die Übersicht in etwa wie folgt aussieht.

Gesamtbewertung A
Zertifikat 100 %
Protokollunterstützung 100 %
Schlüsselaustausch 90 %
Chiffrestärke 90 %
Wichtig

Mit jeder Aktualisierung von OpenSSL werden neue Chiffren eingeführt und die Unterstützung für ältere entfernt. Halten Sie Ihre EC2-Amazon Linux 2-Instance immer auf dem neuesten Stand, achten Sie auf Sicherheitsankündigungen von OpenSSL sowie auf Berichte zu neuen Sicherheitslücken in der Fachpresse. Weitere Informationen finden Sie unter Vordefinierte SSL-Sicherheitsrichtlinien für Elastic Load Balancing im Benutzerhandbuch für Classic Load Balancer.

Fehlersuche

  • Mein Apache-Webserver startet erst, wenn ich ein Passwort eingebe

    Dieses Verhalten wird erwartet, wenn Sie einen verschlüsselten, passwortgeschützten privaten Serverschlüssel installiert haben.

    Sie können die Verschlüsselungs- und Passwortanforderung vom Schlüssel entfernen. Angenommen, Sie haben einen privaten verschlüsselten RSA-Schlüssel namens custom.key im Standardverzeichnis und das Passwort darauf ist abcde12345, dann führen Sie die folgenden Befehle auf Ihrer EC2-Instance aus, um eine unverschlüsselte Version des Schlüssels zu erzeugen.

    [ec2-user ~]$ cd /etc/pki/tls/private/ [ec2-user private]$ sudo cp custom.key custom.key.bak [ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt [ec2-user private]$ sudo mv custom.key.nocrypt custom.key [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ sudo systemctl restart httpd

    Apache sollte jetzt starten, ohne Sie zur Eingabe eines Passworts aufzufordern.

  • Ich erhalten Fehlermeldungen, wenn ich sudo yum install -y mod_ssl ausführe.

    Wenn Sie die für SSL erforderlichen Pakete installieren, treten möglicherweise Fehler wie die folgenden auf.

    Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64

    Dies bedeutet normalerweise, dass Ihre EC2-Instance Amazon Linux 2 nicht ausführt. Dieses Tutorial unterstützt nur von einer offiziellen Amazon Linux 2-AMI neu erstellte Instances.

Zertifikatsautomatisierung: Let's Encrypt mit Certbot auf Amazon Linux 2

Die Let's Encrypt-Zertifizierungsstelle ist das Kernstück einer Bemühung der Electronic Frontier Foundation (EFF), das gesamte Internet zu verschlüsseln. Im Einklang mit diesem Ziel wurden die Host-Zertifikate von Let's Encrypt so erstellt, dass sie mit nur geringen menschlichen Eingriffen entwickelt, validiert, installiert und verwaltet werden können. Die automatisierten Aspekte der Zertifikatsverwaltung werden von einem Software-Agenten auf Ihrem Webserver ausgeführt. Wenn Sie den Agenten installiert und konfiguriert haben, kommuniziert er sicher mit Let's Encrypt und führt administrative Aufgaben auf Apache und dem Schlüsselverwaltungssystem aus. Dieses Tutorial verwendet den kostenlosen Certbot-Agenten, da Sie mit diesem entweder einen benutzerdefinierten Verschlüsselungsschlüssel als Basis für Ihre Zertifikate bereitstellen oder dem Agenten erlauben können, basierend auf den Standardwerten selbst einen Schlüssel zu erstellen. Sie können Certbot auch so konfigurieren, dass Ihre Zertifikate regelmäßig ohne menschliche Eingriffe erneuert werden, wie in So automatisieren Sie Certbot beschrieben. Weitere Informationen finden Sie im Benutzerhandbuch und auf der Man-Page von Certbot.

Certbot wird in Amazon Linux 2 nicht offiziell unterstützt, steht aber für den Download zur Verfügung und funktioniert nach der Installation ordnungsgemäß. Wir empfehlen, die folgenden Backups durchzuführen, um Ihre Daten zu schützen und Unannehmlichkeiten zu vermeiden:

  • Bevor Sie beginnen, machen Sie einen Snapshot Ihres Amazon EBS-Root-Volumes. Dies ermöglicht Ihnen, den ursprünglichen Zustand Ihrer EC2-Instance wiederherzustellen. Informationen zum Erstellen von EBS-Snapshots finden Sie unter Erstellen von Amazon EBS-Snapshots.

  • Für das nachfolgende Verfahren müssen Sie Ihre httpd.conf-Datei bearbeiten, die die Ausführung von Apache steuert. Certbot nimmt automatisch eigene Änderungen an dieser und anderen Konfigurationsdateien vor. Erstellen Sie eine Sicherungskopie Ihres gesamten /etc/httpd-Verzeichnisses, falls Sie es wiederherstellen müssen.

Vorbereitung auf die Installation

Führen Sie die folgenden Verfahren aus, bevor Sie Certbot installieren.

  1. Laden Sie die Repository-Pakete "Extra Packages for Enterprise Linux (EPEL) 7" herunter. Sie brauchen sie, um die von Certbot benötigten Abhängigkeiten bereitzustellen.

    1. Navigieren Sie zum Stammverzeichnis /home/ec2-user. Laden Sie EPEL mit dem folgenden Befehl herunter.

      [ec2-user ~]$ sudo wget -r --no-parent -A 'epel-release-*.rpm' http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/
    2. Installieren Sie die Repository-Pakete wie im folgenden Befehl gezeigt.

      [ec2-user ~]$ sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm
    3. Aktivieren Sie EPEL wie im folgenden Befehl gezeigt.

      [ec2-user ~]$ sudo yum-config-manager --enable epel*

      Mit dem folgenden Befehl können Sie überprüfen, ob EPEL aktiviert ist. Die Ausgabe sollte in etwa folgendermaßen aussehen.

      [ec2-user ~]$ sudo yum repolist all ... epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 enabled: 12949+175 epel-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Debug enabled: 2890 epel-source/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Source enabled: 0 epel-testing/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 enabled: 778+12 epel-testing-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug enabled: 107 epel-testing-source/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source enabled: 0 ...
  2. Bearbeiten Sie die Apache-Hauptkonfigurationsdatei, /etc/httpd/conf/httpd.conf. Suchen Sie die Anweisung „Listen 80“ und fügen Sie hinter ihr die folgenden Zeilen hinzu. Ersetzen Sie dabei die Beispiel-Domänennamen durch den tatsächlichen Common Name und den Subject Alternative Name (SAN).

    <VirtualHost *:80> DocumentRoot "/var/www/html" ServerName "example.com" ServerAlias "www.example.com" </VirtualHost>

    Speichern Sie die Datei und starten Sie Apache neu.

    [ec2-user ~]$ sudo systemctl restart httpd

Installieren und Ausführen von Certbot

Dieses Verfahren basiert auf der EFF-Dokumentation zur Installation von Certbot auf Fedora und RHEL 7. Es beschreibt die Standardverwendung von Certbot, deren Ergebnis ein Zertifikat basierend auf einem 2048-Bit-RSA-Schlüssel ist.

  1. Installieren Sie Certbot-Pakete und -Abhängigkeiten unter Verwendung des folgenden Befehls.

    [ec2-user ~]$ sudo yum install -y certbot python2-certbot-apache
  2. Führen Sie Certbot aus.

    [ec2-user ~]$ sudo certbot
  3. Geben Sie in der Eingabeaufforderung „Enter email address (used for urgent renewal and security notices)” eine Kontaktadresse an und drücken Sie die Eingabetaste.

  4. Stimmen Sie den Nutzungsbedingungen von Let's Encrypt zu, wenn Sie dazu aufgefordert werden. Geben Sie „A” ein und drücken Sie die Eingabetaste, um fortzufahren.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: A
  5. Geben Sie bei der Abfrage der Genehmigung, ob EFF Sie auf ihre Mailingliste setzen darf, „Y” (Ja) oder „N” (Nein) ein, und drücken Sie die Eingabetaste.

  6. Certbot zeigt den Common Name und den Subject Alternative Name (SAN) an, die Sie im VirtualHost-Block angegeben haben.

    Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: example.com 2: www.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel):

    Lassen Sie das Feld leer und drücken Sie die Eingabetaste.

  7. Certbot zeigt die folgende Ausgabe an, während es Zertifikate erstellt und Apache konfiguriert. Anschließend fordert es Sie auf, HTTP-Anfragen an HTTPS umzuleiten.

    Obtaining a new certificate Performing the following challenges: http-01 challenge for example.com http-01 challenge for www.example.com Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/httpd/conf/httpd-le-ssl.conf Deploying Certificate for example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Enabling site /etc/httpd/conf/httpd-le-ssl.conf by adding Include to root configuration Deploying Certificate for www.example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

    Um Besuchern die Verbindung zu Ihrem Server über unverschlüsseltes HTTP zu ermöglichen, geben Sie „1“ ein. Wenn Sie nur verschlüsselte Verbindungen über HTTPS akzeptieren wollen, geben Sie „2“ ein. Drücken Sie die Eingabetaste, um Ihre Auswahl abzusenden.

  8. Certbot schließt die Konfiguration von Apache ab und gibt eine Nachricht über den erfolgreichen Abschluss sowie weitere Informationen zurück.

    Congratulations! You have successfully enabled https://example.com and https://www.example.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=example.com https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/privkey.pem Your cert will expire on 2019-08-01. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
  9. Testen und optimieren Sie die Sicherheit Ihres Servers nach Abschluss der Installation wie in Schritt 3: Testen und Verstärken der Sicherheitskonfiguration beschrieben.

Konfigurieren der automatischen Zertifikatserneuerung

Certbot ist darauf ausgelegt, ein unsichtbarer, fehlerresistenter Teil Ihres Serversystems zu werden. Dieses Tools generiert standardmäßig Host-Zertifikate mit einer kurzen Ablaufzeit von 90 Tagen. Wenn Sie Ihr System nicht so konfiguriert haben, dass es den Befehl automatisch aufruft, müssen Sie den Befehl certbot vor Ablauf erneut manuell ausführen. Diese Anleitung zeigt, wie Sie Certbot automatisieren können, indem Sie einen Cron-Auftrag einrichten.

So automatisieren Sie Certbot

  1. Öffnen Sie die Datei /etc/crontab mithilfe von sudo in einem Texteditor, z. B. vim oder nano. Als alternative Vorgehensweise verwenden Sie sudo crontab -e.

  2. Fügen Sie eine Zeile ähnlich der folgenden hinzu und speichern Sie die Datei.

    39 1,13 * * * root certbot renew --no-self-upgrade

    Im Folgenden finden Sie eine Erläuterung der einzelnen Komponenten:

    39 1,13 * * *

    Plant einen Befehl, der jeden Tag um 01:39 Uhr und um 13:39 Uhr ausgeführt wird. Die ausgewählten Werte sind beliebig, die Certbot-Entwickler empfehlen jedoch, den Befehl mindestens zweimal täglich auszuführen. Damit wird garantiert, dass jedes beschädigte Zertifikat sofort widerrufen und ersetzt wird.

    root

    Der Befehl wird mit Root-Berechtigungen ausgeführt.

    certbot renew --no-self-upgrade

    Der auszuführende Befehl. Der Unterbefehl renew bewirkt, dass Certbot alle zuvor bezogenen Zertifikate prüft und diejenigen erneuert, die kurz vor dem Ablauf stehen. Die Markierung --no-self-upgrade verhindert, dass Certbot ohne Ihren Eingriff ein Upgrade durchführt.

  3. Starten Sie den Cron-Daemon erneut.

    [ec2-user ~]$ sudo systemctl restart crond