Plesk: Domains, Subdomains und Zertifikate verwalten

Plesk ist eine Verwaltungsoberfläche für Webserver. Hoster setzen sie auf Shared Hosting ein, viele Betreiber installieren sie auch auf dem eigenen vServer. Die aktuelle Reihe heißt Plesk Obsidian. Diese Seite zeigt die drei Aufgaben, die fast jeder regelmäßig erledigt: eine Domain anlegen, Subdomains einrichten und die Seiten mit Zertifikaten absichern. Die Menünamen sind die der englischen Oberfläche, wie sie auch in der Dokumentation von Plesk stehen. Je nach Edition und Rechten deines Kontos sehen einzelne Masken etwas anders aus ^[1].

Eine Domain anlegen

Bevor du eine Domain wie beispiel.de in Plesk anlegst, muss sie registriert sein, entweder über deinen Hoster oder bei einem anderen Registrar ^[1]. Danach öffnest du "Websites & Domains", klickst auf "Add Domain" und folgst den Schritten. Zu einer Domain gehören in Plesk Domain-Aliase, Subdomains, eigene FTP-Zugänge, Postfächer, Mailinglisten und eine Besucherstatistik ^[1].

Soll Plesk auch das DNS der Domain beantworten, trägst du beim Registrar die Nameserver von Plesk ein. Die Adresse findest du unter "Websites & Domains", dann die Domain, dann "DNS Settings". Dort steht ein NS-Eintrag, etwa ns.beispiel.de, und dazu ein A-Eintrag mit der IP-Adresse dieses Nameservers ^[1]. Wie der Wechsel der Nameserver beim Registrar abläuft, beschreibt Nameserver ändern.

Subdomains einrichten

Eine Subdomain wie shop.beispiel.de legst du unter "Websites & Domains" mit "Add Subdomain" an. Du gibst den vorderen Teil des Namens ein und wählst das Dokumentverzeichnis. Das kann das Verzeichnis der Hauptseite sein, das bei Plesk httpdocs heißt, oder ein eigenes Verzeichnis ^[2]. Für eine eigenständige Website bietet sich ein eigenes Verzeichnis an, damit die Dateien der beiden Seiten getrennt bleiben.

Subdomains haben in Plesk denselben Stand wie weitere Domains. Du kannst also Zertifikate, Statistiken und dieselben Werkzeuge nutzen ^[2]. Kann Plesk den Namen beim Anlegen nicht auflösen, erscheint unter "DNS Settings" ein Warnhinweis. Dann stimmt meist der Eintrag beim Registrar oder beim externen DNS-Anbieter noch nicht ^[2].

Gibst du als Namen einen Stern (*) ein, entsteht eine Wildcard-Subdomain. Jeder Aufruf einer Subdomain, die in Plesk nicht angelegt ist, landet dann dort. Das geht auch auf tieferen Ebenen, etwa *.laden.beispiel.de ^[2]. Damit das funktioniert, braucht die DNS-Zone einen passenden Wildcard-Eintrag. Den allgemeinen Ablauf ohne Plesk zeigt Subdomain einrichten.

DNS-Zonen für Subdomains

Standardmäßig schreibt Plesk die Einträge einer Subdomain in die DNS-Zone der Hauptdomain. Auf Servern, die du selbst verwaltest, kann jede Subdomain eine eigene Zone bekommen. Der Befehl dafür lautet plesk bin server_pref -u -subdomain-dns-zone own, zurück geht es mit dem Wert parent. Die Einstellung gilt für alle vorhandenen und alle neuen Domains auf dem Server ^[3]. Plesk nennt zwei Gründe dafür: Eine Subdomain soll einen anderen Nameserver nutzen, oder die Zone der Hauptdomain soll weniger Einträge haben ^[3].

Eigene Zonen bringen eine Fehlerquelle mit. Eine Subdomain mit eigener Zone wird über NS-Einträge an Nameserver weitergereicht. Kennen diese Nameserver die Zone nicht, spricht man von einer Lame Delegation. Im schlimmsten Fall bleibt der Name unaufgelöst und die Subdomain ist nicht erreichbar ^[9]. Let's Encrypt fragt bei jeder Prüfung das DNS ab und scheitert dann ebenfalls. Prüfe nach so einer Umstellung mit dem DNS-Check, ob die Subdomain eine Adresse liefert, bevor du ein Zertifikat beantragst.

Zertifikate mit SSL It!

Für Zertifikate ist in Plesk Obsidian die Erweiterung SSL It! zuständig. Sie ist vorinstalliert und bindet Let's Encrypt sowie DigiCert an. Du kannst auch ein eigenes Zertifikat als .pem-Datei hochladen ^[4]. Ein kostenloses Zertifikat holst du so ^[4]:

1. "Websites & Domains" öffnen, die Domain wählen, dann "SSL/TLS Certificates".
2. Unter "More options" auf "Install" klicken.
3. Auswählen, was gesichert werden soll: die Hauptdomain, eine Wildcard (dann mit www und Webmail), die www-Subdomain und Aliase, Webmail und auf Wunsch der Mailserver dieser Domain.
4. Auf "Get it free" klicken. Plesk holt das Zertifikat bei Let's Encrypt und installiert es.

Kommen später Subdomains oder Aliase dazu, schaltest du auf derselben Seite "Keep websites secured" ein. SSL It! stellt das Let's-Encrypt-Zertifikat dann neu aus und nimmt die neuen Namen mit auf ^[4]. Freie Zertifikate von Let's Encrypt und DigiCert erneuert SSL It! 30 Tage vor Ablauf von selbst. Gekaufte Zertifikate erneuert die Erweiterung nicht, sie kann sie nach Ablauf aber durch ein freies ersetzen, wenn "Keep websites secured" an ist ^[4].

Bei einem gewöhnlichen Zertifikat prüft Let's Encrypt über HTTP, ob du die Domain kontrollierst. Dazu legt Plesk eine Datei unter /.well-known/acme-challenge/ ab, die Let's Encrypt über Port 80 abruft ^{[4, 5]}. Die Prüfung schlägt fehl, wenn dieses Verzeichnis nicht erreichbar ist, etwa wegen eines Passwortschutzes oder einer gesperrten Website. SSL It! hält das Verzeichnis deshalb standardmäßig auch in solchen Fällen offen ^[4].

Wildcard-Zertifikate in Plesk

Ein Wildcard-Zertifikat für *.beispiel.de gibt Let's Encrypt nur nach einer DNS-Prüfung aus. Dabei muss ein TXT-Eintrag unter _acme-challenge.beispiel.de stehen, der sich bei jeder Prüfung ändert ^{[5, 6]}. Plesk kann diesen Eintrag nur setzen, wenn es selbst primärer Nameserver der Domain ist oder mit einem DNS-Dienst synchronisiert ist. Plesk nennt DigitalOcean DNS, Amazon Route 53 und Azure DNS. Liegt die Zone woanders, scheitert der Versuch ^[4]. Administratoren können die Wildcard-Option für solche Domains deshalb ausblenden ^[4].

Auf der Kommandozeile geht es in zwei Schritten. plesk ext sslit --certificate -issue -domain beispiel.de -secure-domain -wildcard legt den Auftrag an, plesk ext sslit --certificate -issue beispiel.de -continue schließt ihn ab und stellt das Zertifikat aus ^[4].

Ob ein Wildcard oder einzelne Zertifikate besser passen, hängt von der Zahl der Subdomains ab. Ein Let's-Encrypt-Zertifikat kann bis zu 100 Namen enthalten. Für dieselbe registrierte Domain stellt Let's Encrypt höchstens 50 Zertifikate in sieben Tagen aus ^[7]. Wer viele Subdomains einzeln absichert und dabei mehrfach neu ausstellen muss, stößt an diese Grenze schneller als mit einem Wildcard. Die Abwägung im Einzelnen steht unter SSL für Subdomains: Wildcard oder einzelne Zertifikate.

Wenn die Ausstellung scheitert

Die meisten Fehlschläge lassen sich auf wenige Ursachen zurückführen. Die HTTP-Prüfung läuft nur über Port 80. Let's Encrypt folgt dabei bis zu zehn Weiterleitungen, aber nur auf http- oder https-Adressen mit Port 80 oder 443 ^[5]. Eine Weiterleitung von HTTP auf HTTPS stört also nicht, eine Weiterleitung auf einen anderen Port schon. Bei Wildcards über DNS sollten alte TXT-Einträge unter _acme-challenge wieder verschwinden. Werden es zu viele, wird die Antwort zu groß, und Let's Encrypt lehnt sie ab ^[5].

Let's Encrypt prüft von mehreren Standorten aus und trägt jedes ausgestellte Zertifikat in öffentliche Certificate-Transparency-Protokolle ein. Kurz danach rufen automatische Programme, die diese Protokolle auswerten, die neue Adresse auf ^[6]. Wer nach dem ersten Zertifikat ungewohnte Zugriffe im Protokoll sieht, muss sich deshalb keine Sorgen machen. Eine erfolgreiche Prüfung merkt sich Let's Encrypt bis zu 30 Tage lang. Wird in dieser Zeit erneuert, findet keine neue Prüfung statt ^[6].

Kürzere Laufzeiten ab 2027

Zertifikate von Let's Encrypt gelten heute 90 Tage ^[6]. Let's Encrypt verkürzt die Laufzeit in zwei Stufen: Ab dem 10.02.2027 stellt das Standardprofil Zertifikate mit 64 Tagen aus, ab dem 16.02.2028 mit 45 Tagen. Die neue Laufzeit gilt jeweils ab der nächsten Erneuerung ^[8]. Auch die Frist, in der Let's Encrypt eine erfolgreiche Prüfung wiederverwendet, sinkt: von bisher bis zu 30 Tagen auf 10 Tage ab dem 10.02.2027 und auf 7 Stunden ab dem 16.02.2028 ^[8]. Let's Encrypt empfiehlt, nach etwa zwei Dritteln der Laufzeit zu erneuern, und rät von Erneuerungen von Hand ab ^[8].

Plesk erneuert freie Zertifikate 30 Tage vor Ablauf ^[4]. Bei einem 45-Tage-Zertifikat wäre das nach 15 Tagen. Wirf nach den Stichtagen einen Blick in die Zertifikatsübersicht, ob die Erneuerungen wie erwartet laufen.

HTTPS erzwingen und absichern

Auf der Seite "SSL/TLS Certificates" stellst du auch ein, wie streng die Website HTTPS durchsetzt. "Redirect from http to https" leitet jeden HTTP-Aufruf per 301 auf HTTPS um. Bei frischen Installationen von Plesk Obsidian ist das schon eingeschaltet, nach einem Update von älteren Versionen musst du es selbst aktivieren ^[4]. Weitere Schalter sind HSTS, OCSP Stapling und die TLS-Einstellungen nach den Vorgaben von Mozilla ^[4].

Die Dokumentation von Plesk rät, zusammen mit HSTS "Keep websites secured" einzuschalten, damit nach Ablauf eines Zertifikats sofort ein freies nachkommt ^[4]. Was HSTS genau bewirkt, erklärt der Glossareintrag HSTS. Worauf du beim Wechsel einer bestehenden Seite auf HTTPS sonst noch achten musst, beschreibt Von HTTP auf HTTPS umstellen.

1. Organisation Adding and Removing Domains (Plesk Obsidian Customer's Guide). Plesk (WebPros International GmbH). Stand ohne Datum. abgerufen am 29.10.2026
2. Organisation Adding Subdomains (Plesk Obsidian Administrator's Guide). Plesk (WebPros International GmbH). Stand ohne Datum. abgerufen am 29.10.2026
3. Organisation DNS Zones for Subdomains (Plesk Obsidian Administrator's Guide). Plesk (WebPros International GmbH). Stand ohne Datum. abgerufen am 29.10.2026
4. Organisation Securing Connections with the SSL It! Extension (Plesk Obsidian Administrator's Guide). Plesk (WebPros International GmbH). Stand ohne Datum. abgerufen am 29.10.2026
5. Organisation Challenge Types. Let's Encrypt (ISRG). Stand 12.02.2026. abgerufen am 29.10.2026
6. Organisation FAQ. Let's Encrypt (ISRG). Stand 28.04.2025. abgerufen am 29.10.2026
7. Organisation Rate Limits. Let's Encrypt (ISRG). Stand 05.08.2026. abgerufen am 29.10.2026
8. Organisation Decreasing Certificate Lifetimes to 45 Days. Let's Encrypt (ISRG). Stand 02.12.2025. abgerufen am 29.10.2026
9. Gesetz RFC 1912: Common DNS Operational and Configuration Errors, Abschnitt 2.8. IETF. Stand Februar 1996. 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.