SSL-Zertifikat installieren auf Apache, nginx und Plesk

Ein Zertifikat zu installieren heißt, dem Webserver zu sagen, wo sein privater Schlüssel und sein Zertifikat liegen, und ihn auf Port 443 für HTTPS lauschen zu lassen. Das sind wenige Zeilen Konfiguration. Die meisten Fehler entstehen an den Rändern: Der Schlüssel passt nicht zum Zertifikat, die Zwischenzertifikate fehlen, oder die Dateien liegen in der falschen Reihenfolge. Diese Anleitung geht die Schritte für Apache, nginx und Plesk durch.

Wenn du ein kostenloses Zertifikat von Let's Encrypt nutzt, holt ein Programm wie Certbot die Dateien und baut sie oft gleich selbst ein. Das beschreibt der Artikel Let's Encrypt: kostenlose Zertifikate einrichten. Hier geht es um den allgemeinen Weg, der auch für gekaufte Zertifikate gilt.

Die drei Teile eines Zertifikats

Für eine funktionierende HTTPS-Verbindung braucht der Server drei Dinge:

• den privaten Schlüssel, der den Server ausweist und auf dem Server bleibt,
• das Serverzertifikat mit dem öffentlichen Schlüssel und den Namen, für die es gilt,
• die Zwischenzertifikate der Zertifizierungsstelle, die die Kette vom Serverzertifikat bis zu einem Stammzertifikat im Browser schließen.

Der Server schickt dem Browser nur die Zertifikate. Der private Schlüssel ist ein Geheimnis und gehört in eine Datei mit eingeschränkten Rechten, die nur der Webserver lesen darf ^[2]. Steht der Schlüssel in derselben Datei wie das Zertifikat, braucht auch diese Datei eingeschränkte Rechte ^[2]. Auf einem Linux-Server heißt das in der Regel: Eigentümer ist root, andere Benutzer dürfen die Datei nicht lesen. Der Webserver liest sie beim Start mit seinem Hauptprozess, der dafür die nötigen Rechte hat. Bei Certbot heißen die Dateien privkey.pem für den Schlüssel und fullchain.pem für Zertifikat und Zwischenzertifikate zusammen ^[3].

Schlüssel und Zertifikatsantrag erzeugen

Kaufst du ein Zertifikat, erzeugst du zuerst den Schlüssel und einen Zertifikatsantrag (Certificate Signing Request, CSR). Den Antrag reichst du bei der Zertifizierungsstelle ein, den Schlüssel behältst du. Mit OpenSSL geht beides in einem Befehl ^[4]:

openssl req -newkey rsa:2048 -keyout key.pem -out req.pem

Der Befehl erzeugt einen RSA-Schlüssel mit 2048 Bit in key.pem und den Antrag in req.pem. Ohne weitere Angabe verschlüsselt OpenSSL den Schlüssel mit einem Kennwort. Dann fragt der Webserver beim Start nach diesem Kennwort, was bei einem Neustart ohne Aufsicht stört. Mit der Option -noenc bleibt der Schlüssel unverschlüsselt. Die ältere Option -nodes gilt seit OpenSSL 3.0 als veraltet ^[4]. Einen unverschlüsselten Schlüssel schützt du über die Dateirechte.

Viele Hoster und Plesk erzeugen Schlüssel und Antrag auch über die Weboberfläche. Das ist bequemer, solange der Schlüssel auf dem Server bleibt, auf dem er gebraucht wird.

Apache

Bei Apache übernimmt das Modul mod_ssl die Verschlüsselung. Es ist für den Hauptserver und alle virtuellen Hosts zunächst ausgeschaltet und wird je virtuellem Host mit SSLEngine on eingeschaltet ^[1]. Ein Eintrag für Port 443 sieht so aus:

Seit Apache 2.4.8 darf die Datei in SSLCertificateFile auch die Zwischenzertifikate enthalten, sortiert vom Serverzertifikat bis zur Wurzel. Die frühere Anweisung SSLCertificateChainFile ist damit überholt ^[1]. Findest du sie in alten Anleitungen, ersetzt du sie durch eine Datei mit der ganzen Kette. Zu jeder SSLCertificateKeyFile-Zeile gehört eine passende SSLCertificateFile-Zeile ^[1].

Bei den Protokollen ist die Grundeinstellung von Apache all -SSLv3 ^[1]. Das schließt SSL 3.0 aus, lässt aber TLS 1.0 und 1.1 zu, die seit 2021 nicht mehr verwendet werden sollen ^[6]. Die Anweisung nimmt Protokolle mit vorangestelltem Plus oder Minus entgegen, und all steht für alle unterstützten Protokolle. Mit SSLProtocol -all +TLSv1.2 +TLSv1.3 lässt du deshalb nur die beiden aktuellen Versionen zu; TLS 1.3 setzt OpenSSL 1.1.1 oder neuer voraus ^[1].

Prüfe die Konfiguration vor dem Neuladen mit apachectl configtest. Der Befehl meldet Syntax Ok oder nennt den Fehler. Danach startet apachectl graceful den Server neu, ohne offene Verbindungen abzubrechen, und prüft die Konfiguration vorher noch einmal selbst ^[7].

nginx

Bei nginx steht alles im server-Block. Die Zeile listen 443 ssl schaltet HTTPS ein, ssl_certificate zeigt auf das Zertifikat und ssl_certificate_key auf den Schlüssel ^[2]:

Hat dir die Zertifizierungsstelle Zertifikat und Zwischenzertifikate als getrennte Dateien geschickt, hängst du sie zusammen, das Serverzertifikat zuerst: cat www.example.com.crt bundle.crt > www.example.com.chained.crt. Stimmt die Reihenfolge nicht, startet nginx nicht und meldet, dass Schlüssel und Zertifikat nicht zusammenpassen. nginx hat dann versucht, den Schlüssel mit dem ersten Zertifikat aus dem Bündel zu verwenden ^[2].

Neuere Versionen von nginx nutzen ab Werk nur TLS 1.2 und TLS 1.3 ^[2]. Seit Version 1.27.3 sind TLS 1.0 und TLS 1.1 standardmäßig abgeschaltet ^[10]. Die Zeile ssl_protocols brauchst du dann nur, wenn du davon abweichen willst. Vor dem Neuladen prüft nginx -t die Syntax und ob sich die genannten Dateien öffnen lassen. Danach übernimmt nginx -s reload die neue Konfiguration: Neue Arbeitsprozesse starten, die alten laufen geordnet aus ^[8].

Plesk

In Plesk installierst du Zertifikate über die Erweiterung SSL It!. Unter Websites & Domains wählst du die Domain und öffnest SSL/TLS-Zertifikate. Für ein kostenloses Zertifikat von Let's Encrypt genügt "Get it free". Dabei legst du fest, ob www, Webmail und der Mailserver mit abgesichert werden. Ein gekauftes Zertifikat lädst du als PEM-Datei über "Upload" hoch ^[5].

Auf derselben Seite schaltest du die dauerhafte Weiterleitung von HTTP auf HTTPS ein, die Plesk als 301 einrichtet. Dort findest du auch HSTS und OCSP Stapling, wobei OCSP Stapling nur für Websites wirkt, die nginx ausliefert. Kostenlose Zertifikate von Let's Encrypt und DigiCert erneuert SSL It! 30 Tage vor Ablauf selbst. Gekaufte Zertifikate kann Plesk nicht automatisch verlängern, sie lassen sich aber beim Ablauf durch ein kostenloses ersetzen ^[5]. Die übrigen Funktionen der Oberfläche beschreibt Plesk: Domains, Subdomains und Zertifikate verwalten.

Zertifikat erneuern und austauschen

Jedes Zertifikat läuft ab, und die erlaubte Laufzeit wird kürzer. Seit dem 15.03.2026 dürfen neue Zertifikate höchstens 200 Tage gelten, ab dem 15.03.2027 höchstens 100 Tage ^[9]. Plane den Austausch deshalb von Anfang an mit ein. Was die Fristen im Einzelnen bedeuten, erklärt Laufzeit von SSL-Zertifikaten.

Bei einem gekauften Zertifikat erzeugst du für die Verlängerung am besten einen neuen Schlüssel und einen neuen Antrag. Das neue Zertifikat legst du unter einem neuen Dateinamen ab, trägst die Pfade in die Konfiguration ein und prüfst sie, bevor du den Webserver neu lädst. Die alten Dateien bleiben liegen, bis die Seite mit dem neuen Zertifikat läuft. Geht etwas schief, kannst du so sofort zurück.

Bei Certbot ist das einfacher. Die Pfade unter /etc/letsencrypt/live/ bleiben gleich, die Erneuerung tauscht nur die Dateien dahinter aus ^[3]. Deshalb verweist die Konfiguration auf diese Pfade und nicht auf Kopien. Der Webserver liest ein neues Zertifikat aber erst, wenn er neu geladen wird. Mit dem Apache- oder nginx-Plugin übernimmt Certbot den Einbau selbst; wer nur mit certonly arbeitet, sorgt über ein Skript im Ordner /etc/letsencrypt/renewal-hooks/post dafür, dass der Webserver nach jeder Erneuerung neu lädt ^[3].

Nach der Installation prüfen

Ruf die Seite im Browser über https:// auf und sieh dir über das Symbol links neben der Adresse die Zertifikatsdetails an. Stimmen Name, Aussteller und Ablaufdatum, ist die Grundeinrichtung geschafft. Der Browser verzeiht allerdings manches, weil er Zwischenzertifikate speichert, die er schon einmal empfangen hat ^[2]. Ein Test von außen ist deshalb zuverlässiger. Unser SSL-Check zeigt das Zertifikat einer Domain mit Laufzeit und Namen. Plesk bietet auf der Zertifikatsseite außerdem einen Test bei SSL Labs an ^[5].

Danach kommt der Umstieg der ganzen Website: Weiterleitung aller HTTP-Adressen, Links ohne gemischte Inhalte, angepasste Sitemap. Diese Schritte stehen in Von HTTP auf HTTPS umstellen. Zeigt der Browser trotz allem eine Warnung, hilft Zertifikatsfehler im Browser verstehen und beheben bei der Suche nach der Ursache.

1. Organisation Apache Module mod_ssl. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
2. Organisation Configuring HTTPS servers. nginx. Stand 2026. abgerufen am 29.10.2026
3. Organisation User Guide: Where are my certificates?. Electronic Frontier Foundation (Certbot). Stand 2026. abgerufen am 29.10.2026
4. Organisation openssl-req (OpenSSL 3.0 Manual). OpenSSL Project. Stand 2026. abgerufen am 29.10.2026
5. Organisation Securing Connections with the SSL It! Extension (Plesk Obsidian Customer Guide). Plesk. Stand 2026. abgerufen am 29.10.2026
6. Gesetz RFC 8996: Deprecating TLS 1.0 and TLS 1.1. IETF. Stand 2021. abgerufen am 29.10.2026
7. Organisation apachectl: Apache HTTP Server Control Interface. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
8. Organisation Command-line parameters. nginx. Stand 2026. abgerufen am 29.10.2026
9. Organisation Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1, Abschnitt 6.3.2. CA/Browser Forum. Stand 04.10.2026. abgerufen am 29.10.2026
10. Organisation Changes with nginx 1.27.3 (Änderungsliste). nginx. Stand 26.11.2024. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.