Schritt-für-Schritt-Anleitung zur Einrichtung von SSL auf einem Apache-Server

SSL 10 Min. Lesezeit

Diese Anleitung zeigt Ihnen, wie Sie ein bereits vorhandenes SSL-Zertifikat manuell auf dem Apache-Webserver eines Linux-Servers ohne Control Panel installieren können, beispielsweise auf unseren KVM-VPS-Servern. Die Schritte funktionieren unter Debian und Ubuntu sowie unter AlmaLinux, Rocky Linux und anderen Red-Hat-basierten Systemen; wo sich die beiden Varianten unterscheiden, geben wir beide Versionen an.

Eine manuelle Konfiguration ist nicht in jedem Fall erforderlich:

  • Bei cPanel-Hosting-Paketen und Webhosting-Paketen wird das Zertifikat vom Control Panel installiert (bei Let’s Encrypt automatisch); Sie müssen keine Änderungen an den Einstellungen des Webservers vornehmen.
  • Wenn Sie ein kostenloses Let’s Encrypt-Zertifikat für Ihren eigenen Server wünschen, übernimmt Certbot sowohl die Beantragung des Zertifikats als auch die Konfiguration von Apache und die Verlängerung.

Eine manuelle Installation ist erforderlich, wenn Sie ein kostenpflichtiges Zertifikat erworben haben oder das Zertifikat von einer anderen Quelle erhalten haben und die Dateien selbst auf den Server hochladen müssen. Allgemeine Informationen zum Zertifikatstyp, zur Erstellung der CSR und zur Installation über cPanel finden Sie in unserem Blogbeitrag zur Installation von SSL-Zertifikaten.

Was Sie benötigen

  • Root- oder sudo-Rechte auf dem Server.
  • Apache ist bereits in Betrieb, und die Domain ist über HTTP erreichbar (der A-Eintrag der Domain verweist auf die IP-Adresse des Servers). Falls die Installation noch nicht erfolgt ist, lesen Sie bitte: Installation von Apache und PHP-FPM unter AlmaLinux 9.
  • Port 443 ist in der Firewall geöffnet (siehe: Wie richte ich eine Firewall auf meinem VPS ein?).
  • Drei Dateien im PEM-Format (Textformat):
    • das Zertifikat der Domain (z. B. pelda.hu.crt), das Sie von der Zertifizierungsstelle erhalten haben;
    • das** Zertifikat** oder CA-Bundle (z. B. „ca-bundle.crt“), das zum Zertifikat gehört;
    • Der private Schlüssel (z. B. „pelda.hu.key“), der zusammen mit dem CSR erstellt wurde. Dieser wird von der Zertifizierungsstelle nicht versendet, da sie ihn nie erhalten hat: Er befindet sich dort, wo der CSR erstellt wurde (siehe: Erstellung von CSR und privatem Schlüssel).

Falls Sie das Zertifikat im PFX- oder P7B-Format erhalten haben, konvertieren Sie es bitte zunächst gemäß dem Artikel über Zertifikatsformate in das PEM-Format. Eine PEM-Datei beginnt, wenn sie in einem Texteditor geöffnet wird, mit der Zeile „-----BEGIN CERTIFICATE-----“ (beim Schlüssel mit „-----BEGIN PRIVATE KEY-----“).

In den Beispielen wird die Domain „pelda.hu“ verwendet; bitte passen Sie die Befehle und Einstellungen an Ihre eigene Domain an.

1. Aktivierung des SSL-Moduls

Debian, Ubuntu: Das SSL-Modul (mod_ssl) ist Teil des apache2-Pakets und muss nicht separat installiert werden, sondern lediglich aktiviert werden:

sudo a2enmod ssl

AlmaLinux, Rocky Linux, CloudLinux: Das Modul ist in einem separaten Paket enthalten:

sudo dnf install -y mod_ssl

Das Paket erstellt die Datei „/etc/httpd/conf.d/ssl.conf“ mit einem standardmäßigen virtuellen HTTPS-Host, der ein selbstsigniertes Zertifikat verwendet, das von Browsern nicht akzeptiert wird. Behalten Sie diese Datei bei (sie enthält auch die allgemeinen Einstellungen des Moduls); für Ihre Domain wird in Schritt 3 eine separate Datei erstellt.

2. Das Hochladen der Dateien

Fügen Sie das Domain-Zertifikat und das Zwischenzertifikat in einer Datei zusammen. Die Reihenfolge ist wichtig: zuerst das Domain-Zertifikat, dann das Zwischenzertifikat:

cat pelda.hu.crt ca-bundle.crt > pelda.hu-fullchain.crt

Kopieren Sie anschließend die Dateien an den üblichen Speicherort des Systems und legen Sie die Zugriffsrechte fest. Der private Schlüssel darf nur von root gelesen werden; Apache liest den Schlüssel beim Start ebenfalls mit root-Rechten ein.

Debian, Ubuntu:

sudo cp pelda.hu-fullchain.crt /etc/ssl/certs/
sudo cp pelda.hu.key /etc/ssl/private/
sudo chown root:root /etc/ssl/private/pelda.hu.key
sudo chmod 600 /etc/ssl/private/pelda.hu.key

AlmaLinux, Rocky Linux, CloudLinux:

sudo cp pelda.hu-fullchain.crt /etc/pki/tls/certs/
sudo cp pelda.hu.key /etc/pki/tls/private/
sudo chown root:root /etc/pki/tls/private/pelda.hu.key
sudo chmod 600 /etc/pki/tls/private/pelda.hu.key
sudo restorecon -Rv /etc/pki/tls

Der letzte Befehl stellt die SELinux-Markierung der Dateien wieder her. Wenn Sie die Dateien statt mit „cp“ mit dem Befehl „mv“ verschieben (beispielsweise aus Ihrem eigenen Verzeichnis), bleibt ihre alte Markierung erhalten, und Apache kann sie aufgrund von SELinux nicht öffnen, selbst wenn die Berechtigungen korrekt sind.

Legen Sie den privaten Schlüssel nicht auf der Website ab (z. B. unter /var/www) und versenden Sie ihn nicht per E-Mail. Sollte er dennoch in unbefugte Hände geraten sein, finden Sie im Artikel zum Thema „Verlorener privater Schlüssel“ eine Beschreibung der zu ergreifenden Maßnahmen.

3. Einrichtung eines HTTPS-virtuellen Hosts

Erstellen Sie eine neue Konfigurationsdatei für die Domain.

Debian, Ubuntu: /etc/apache2/sites-available/pelda.hu-ssl.conf

AlmaLinux, Rocky Linux, CloudLinux: /etc/httpd/conf.d/pelda.hu-ssl.conf

Der Inhalt (geben Sie den Pfad zu den Dateien entsprechend Ihrem System an):

<VirtualHost *:443>
    ServerName pelda.hu
    ServerAlias www.pelda.hu
    DocumentRoot /var/www/pelda.hu

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/pelda.hu-fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/pelda.hu.key

    ErrorLog  /var/log/apache2/pelda.hu-ssl-error.log
    CustomLog /var/log/apache2/pelda.hu-ssl-access.log combined
</VirtualHost>

Auf einem Red-Hat-basierten System befindet sich das Zertifikat unter „/etc/pki/tls/certs/pelda.hu-fullchain.crt“, der Schlüssel unter „/etc/pki/tls/private/pelda.hu.key“ und die Protokolldateien unter „/var/log/httpd/...“.

Der DocumentRoot muss mit dem des virtuellen Hosts für HTTP (Port 80) übereinstimmen. Sollten dort weitere Einstellungen vorhanden sein (<Directory>-Block, PHP-FPM-Manager), kopieren Sie diese ebenfalls hierher; andernfalls funktioniert die Website über HTTPS anders.

In älteren Anleitungen taucht noch eine dritte Zeile auf, „SSLCertificateChainFile“, mit der das Zwischenzertifikat in einer separaten Datei angegeben werden konnte. Apache betrachtet dies seit Version 2.4.8 als veraltet; heute wird bei allen unterstützten Linux-Distributionen eine neuere Apache-Version mitgeliefert, weshalb es ausreicht, wenn das Zwischenzertifikat in der Datei „SSLCertificateFile“ direkt nach dem Domain-Zertifikat aufgeführt ist. Warum die Seite auf bestimmten Geräten nicht funktioniert, wenn das Zwischenzertifikat fehlt, wird im Artikel über das Zwischenzertifikat erläutert.

Debian, Ubuntu: Aktivieren Sie die neue Seite:

sudo a2ensite pelda.hu-ssl

Auf einem Red-Hat-basierten System lädt Apache die .conf-Dateien im Verzeichnis „conf.d“ automatisch ein.

Nur sichere Protokolle

SSL 3.0, TLS 1.0 und TLS 1.1 sind veraltet und anfällig für Sicherheitslücken (siehe: Was ist der Unterschied zwischen TLS und SSL?). Die Standardeinstellungen heutiger Distributionen lassen diese Protokolle meist nicht mehr zu, es empfiehlt sich jedoch, ausdrücklich nur TLS 1.2 und TLS 1.3 zuzulassen. Suchen Sie unter Debian und Ubuntu in der Datei „/etc/apache2/mods-available/ssl.conf“ und auf Red-Hat-basierten Systemen in der Datei „/etc/httpd/conf.d/ssl.conf“ nach der Zeile „SSLProtocol“ (falls diese mit einem #-Zeichen auskommentiert ist, entfernen Sie das Zeichen; falls keine solche Zeile vorhanden ist, fügen Sie sie ein) und ändern Sie sie wie folgt:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Unter AlmaLinux und Rocky Linux werden die Verschlüsselungseinstellungen auch durch die systemweite Kryptografie-Richtlinie (update-crypto-policies) geregelt, deren DEFAULT-Stufe nur noch TLS 1.2 und neuere Versionen zulässt. Für die detaillierte Konfiguration der Verschlüsselungsalgorithmen bietet der Mozilla SSL Configuration Generator eine aktuelle Vorlage, die auf Ihre jeweiligen Apache- und OpenSSL-Versionen abgestimmt ist.

4. Überprüfung und Neustart

Bevor Sie Apache neu starten, überprüfen Sie bitte die Syntax der Einstellungen:

sudo apachectl configtest

Wenn die Antwort „Syntax OK“ lautet, starten Sie den Webserver bitte neu:

sudo systemctl reload apache2   # Debian, Ubuntu
sudo systemctl reload httpd     # AlmaLinux, Rocky Linux, CloudLinux

Beim ersten Start des Moduls ist statt „reload“ ein „restart“ erforderlich. Sollte Apache nicht starten, wird die Fehlerursache durch den Befehl „sudo journalctl -u apache2 -n 50“ (auf Red-Hat-basierten Systemen „-u httpd“) bzw. im Fehlerprotokoll angezeigt.

5. Weiterleitung von HTTP zu HTTPS

Nach der Installation des Zertifikats ist die Website auch über HTTPS erreichbar, die Adresse http:// funktioniert jedoch weiterhin. Sie können Besucher und Suchmaschinen im virtuellen Host auf Port 80 mittels einer permanenten (301) Weiterleitung auf HTTPS umleiten. Ändern Sie den Inhalt des HTTP-virtuellen Hosts wie folgt:

<VirtualHost *:80>
    ServerName pelda.hu
    ServerAlias www.pelda.hu
    Redirect permanent / https://pelda.hu/
</VirtualHost>

Falls Sie die Weiterleitung lieber in der .htaccess-Datei einrichten möchten oder wissen möchten, welche Schritte nach der Umstellung erforderlich sind (interne Links, gemischte Inhalte, Google Search Console), lesen Sie bitte: Wie kann ich meine Website auf HTTPS umleiten? Wenn alles ordnungsgemäß funktioniert, können Sie mit dem HSTS-Header die Browser anweisen, die Seite von vornherein nur über HTTPS zu öffnen.

6. Überprüfung der Installation

Öffnen Sie die Seite in Ihrem Browser unter der Adresse https:// und prüfen Sie, ob in der Adressleiste eine Warnung angezeigt wird. Dies allein reicht jedoch nicht aus: Browser füllen das fehlende Zertifikat oft automatisch aus, andere Programme und ältere Mobiltelefone hingegen nicht.

Unser kostenloses SSL-Prüftool ist zuverlässiger: Es zeigt Ihnen an, ob das SSL-Zertifikat gültig ist, für welche Namen es gilt, wann es abläuft und ob die Zertifikatskette vollständig ist. Geben Sie die Adressen „pelda.hu, www.pelda.hu“ gleichzeitig ein, damit Sie beide Varianten in einem Schritt überprüfen können.

Über die Befehlszeile können Sie mit OpenSSL überprüfen, welche Zertifikatskette der Server übermittelt:

openssl s_client -connect pelda.hu:443 -servername pelda.hu -showcerts </dev/null

Am Anfang der Ausgabe müssen unter „Certificate chain“ mindestens zwei Zertifikate aufgeführt sein (das der Domain und das Zwischenzertifikat), am Ende muss die Zeile „Verify return code: 0 (ok)“ erscheinen.

Häufige Fehler

Apache startet nicht, im Protokoll wird der Fehler „AH02565“ oder „key values mismatch“ angezeigt. Das Zertifikat und der private Schlüssel passen nicht zusammen, beispielsweise weil das Zertifikat mit einer anderen, später erstellten CSR beantragt wurde. Ob sie zusammenpassen, können Sie durch einen Abgleich der öffentlichen Schlüssel überprüfen; die beiden Befehle müssen denselben Wert ausgeben:

openssl x509 -in pelda.hu-fullchain.crt -noout -pubkey | openssl sha256
openssl pkey -in pelda.hu.key -pubout | openssl sha256

Sollten diese abweichen, suchen Sie bitte den zum Zertifikat gehörenden Schlüssel oder erstellen Sie einen neuen Schlüssel und eine neue CSR und lassen Sie das Zertifikat neu ausstellen. Bei einem bei aWh erworbenen Zertifikat können Sie dies im Kundenbereich vornehmen (siehe: Einrichtung und Neuausstellung eines kostenpflichtigen SSL-Zertifikats).

Apache fordert beim Start ein Passwort an, oder der Befehl „systemctl“ kann den Dienst nicht starten. Der private Schlüssel ist durch ein Passwort geschützt. Auf dem Server wird der Schlüssel üblicherweise ohne Passwort gespeichert (der Schutz erfolgt durch die Berechtigung 600); das Passwort können Sie wie folgt entfernen:

sudo openssl pkey -in pelda.hu.key -out pelda.hu-nopass.key
sudo chmod 600 pelda.hu-nopass.key

Der Befehl fordert Sie zur Eingabe des Passworts für den Schlüssel auf und schreibt den Schlüssel ohne Passwort in die neue Datei. Geben Sie anschließend in der Zeile „SSLCertificateKeyFile“ diese Datei an und löschen Sie die alte.

Die Seite zeigt auf bestimmten Geräten, in bestimmten Programmen oder auf Mobiltelefonen einen Zertifikat-Fehler an, im Browser funktioniert sie jedoch einwandfrei. Das Zwischenzertifikat fehlt: Bitte überprüfen Sie, ob in der durch „SSLCertificateFile“ angegebenen Datei nach dem Domain-Zertifikat auch das Zwischenzertifikat enthalten ist.

Der Browser erkennt das Zertifikat nicht als für die Domain ausgestellt oder zeigt das selbstsignierte Zertifikat an. Apache verwendet für die Anfrage einen anderen virtuellen Host. Bitte überprüfen Sie, ob „ServerName“ und „ServerAlias“ genau mit der aufgerufenen Adresse übereinstimmen (einschließlich der „www“-Variante), und überprüfen Sie mit dem Befehl „sudo apachectl -S“, welche virtuellen Hosts in welcher Datei auf Port 443 eingerichtet sind. Die Bedeutung der Fehlermeldungen der Browser wird im Artikel zum Fehler „Ihre Verbindung ist nicht privat“ erläutert.

Der Befehl „apachectl configtest“ gibt die Fehlermeldung „Invalid command ‘SSLEngine’“ aus. Das SSL-Modul ist nicht aktiviert oder nicht installiert: Führen Sie den Befehl aus Schritt 1 aus.

Über HTTPS kann der Browser keine Verbindung herstellen (Zeitüberschreitung oder „Verbindung abgelehnt“), über HTTP funktioniert die Seite jedoch einwandfrei. Die Firewall lässt Port 443 nicht zu. Unter AlmaLinux und Rocky Linux muss der Dienst „https“ in der Ausgabe von „sudo firewall-cmd --list-services“ aufgeführt sein; unter Ubuntu zeigt bei Verwendung der ufw-Firewall der Befehl „sudo ufw status“ die offenen Ports an.

Verlängerung des Zertifikats

Bezahlte Zertifikate sind maximal 200 Tage gültig; daher muss das Zertifikat im Rahmen eines Jahresabonnements mindestens einmal erneuert werden (siehe: Warum sind SSL-Zertifikate nicht mehr ein Jahr lang gültig?). Ersetzen Sie in diesem Fall gemäß Schritt 2 die Zertifikatsdatei und starten Sie Apache neu; Sie müssen die Einstellungen des virtuellen Hosts nicht ändern, sofern Sie den Dateinamen beibehalten. Falls Sie einen neuen privaten Schlüssel erstellt haben, ersetzen Sie diesen ebenfalls.

Sie können auf den manuellen Austausch verzichten, wenn Sie ein kostenpflichtiges Zertifikat mit ACME-Abonnement verwenden: Dieses wird von Certbot ebenso automatisch erneuert wie die Let’s Encrypt-Zertifikate (siehe Ende des Artikels über Certbot). Das Ablaufdatum können Sie gemäß dem Artikel zur Überprüfung des Zertifikatsablaufs verfolgen.

Sollten Sie bei der Einrichtung auf Schwierigkeiten stoßen, schreiben Sie uns bitte unter Angabe Ihres Domainnamens und der Fehlermeldung.

Zurück: SSL-Artikel (35)