SSL für Subdomains: Wildcard, SAN oder einzelne Zertifikate

Jede Subdomain, die du im Browser aufrufst, braucht ein Zertifikat, in dem ihr Name steht. Sonst meldet der Browser einen Fehler, auch wenn die Hauptdomain längst über HTTPS läuft. Für blog.beispiel.de, shop.beispiel.de und mail.beispiel.de gibt es drei Wege: ein eigenes Zertifikat je Subdomain, ein gemeinsames Zertifikat mit einer Liste aller Namen oder ein Wildcard-Zertifikat für *.beispiel.de. Welcher Weg passt, hängt davon ab, wie viele Subdomains du hast, wie oft neue dazukommen und ob alle auf demselben Server laufen.

Drei Wege im Vergleich

Ein Einzelzertifikat deckt einen Namen ab, oft zusammen mit der www-Variante. Ein SAN-Zertifikat enthält im Feld Subject Alternative Name eine feste Liste von Namen, bei Let's Encrypt höchstens 100 ^[4]. Ein Wildcard-Zertifikat enthält einen Namen mit Sternchen und gilt damit für jede Subdomain auf dieser Ebene, auch für solche, die du erst später anlegst.

Wie du eine Subdomain überhaupt anlegst, vom DNS-Eintrag bis zum Webserver, steht unter Subdomain einrichten: DNS-Eintrag, Webserver und Zertifikat.

Was *.beispiel.de abdeckt und was nicht

Die Regeln, wie ein Browser einen Namen mit einem Wildcard-Eintrag abgleicht, stehen in RFC 9525 vom November 2023. Danach darf ein Name genau ein Sternchen enthalten, und dieses muss das ganze erste Namensteil von links bilden ^[1]. Das Sternchen steht für genau ein Namensteil. *.beispiel.de passt also auf www.beispiel.de und shop.beispiel.de, aber nicht auf test.shop.beispiel.de ^[1]. Teil-Wildcards wie f*.beispiel.de sind ungültig und werden ignoriert ^[1].

Daraus folgt eine Lücke, die viele überrascht: Die Hauptdomain beispiel.de selbst ist nicht abgedeckt, denn dort steht an der Stelle des Sternchens gar kein Namensteil. Deshalb tragen Wildcard-Zertifikate in der Praxis zwei Namen, *.beispiel.de und beispiel.de.

RFC 9525 weist ausdrücklich darauf hin, dass Wildcards in Zertifikaten anders funktionieren als Wildcards im DNS ^[1]. Ein DNS-Eintrag *.beispiel.de beantwortet auch Fragen nach Namen auf tieferen Ebenen, die nicht ausdrücklich eingetragen sind. Wie das im DNS geregelt ist, erklärt Wildcard-DNS: ein Eintrag für alle Subdomains. Wer beides kombiniert, bekommt eine Website, die unter jedem beliebigen Subdomain-Namen erreichbar ist, und ein Zertifikat, das dazu passt, solange es bei einer Ebene bleibt.

Wildcard nur über die DNS-Bestätigung

Bevor eine Zertifizierungsstelle ein Zertifikat ausstellt, musst du nachweisen, dass du die Domain kontrollierst. Für Wildcards lassen die Baseline Requirements des CA/Browser Forum nur einen Teil der Prüfverfahren zu. Verfahren, bei denen eine Datei auf der Website abgelegt wird, sind für Wildcard-Namen ausgeschlossen, Verfahren über eine Änderung im DNS sind erlaubt ^[8]. Let's Encrypt verlangt für Wildcards deshalb die Bestätigung DNS-01 ^[3].

Dabei legst du einen TXT-Eintrag unter _acme-challenge.beispiel.de an, dessen Wert dein ACME-Programm vorgibt ^[2]. Let's Encrypt fragt den Eintrag ab und stellt bei Erfolg das Zertifikat aus. Der Vorteil: Der Webserver muss dafür nicht aus dem Internet erreichbar sein, und es funktioniert auch, wenn mehrere Server die Website ausliefern ^[2]. Der Nachteil: Damit die Erneuerung automatisch läuft, braucht das ACME-Programm Zugriff auf eine Schnittstelle deines DNS-Anbieters. Let's Encrypt nennt es ein Risiko, diese Zugangsdaten auf dem Webserver zu speichern, und weist darauf hin, dass nicht jeder DNS-Anbieter eine solche Schnittstelle hat ^[2].

Let's Encrypt verkürzt die Laufzeit seiner Standardzertifikate bis Februar 2028 schrittweise auf 45 Tage und rät ausdrücklich davon ab, Zertifikate von Hand zu erneuern ^[9]. Wie die Verkürzung im Einzelnen abläuft, steht unter Laufzeit von SSL-Zertifikaten.

Einzelzertifikate über HTTP-01

Für ein Zertifikat ohne Sternchen reicht meist die Bestätigung HTTP-01. Das ACME-Programm legt eine Datei unter /.well-known/acme-challenge/ auf dem Webserver ab, und Let's Encrypt ruft sie über Port 80 ab ^[2]. Andere Ports erlaubt das Verfahren nicht ^[2]. Das lässt sich mit jedem gängigen Webserver automatisieren und braucht keinen Zugriff auf das DNS. Es scheitert, wenn der Internetanbieter Port 80 sperrt oder wenn mehrere Server die Subdomain ausliefern und nicht alle die Datei bereithalten ^[2].

Laufen deine Subdomains auf verschiedenen Servern, etwa der Blog bei einem Hoster und der Shop bei einem Shopanbieter, kümmert sich meist jeder Server selbst um sein Zertifikat. Ein Wildcard-Zertifikat müsstest du dagegen auf alle Server kopieren. Für Tests oder Server im internen Netz, die von außen nicht erreichbar sind, bleibt auch bei Einzelzertifikaten nur DNS-01 ^[2].

Sicherheit: ein Schlüssel für alle Subdomains

Zu einem Wildcard-Zertifikat gehört ein einziger privater Schlüssel. Liegt das Zertifikat auf mehreren Servern, liegt dieser Schlüssel überall mit. Wer einen dieser Server übernimmt, kann sich mit dem Schlüssel als jede andere Subdomain ausgeben. Die US-Behörde NSA hat 2021 in einem Merkblatt vor zu weit gefassten Wildcard-Zertifikaten gewarnt und dabei auch den Angriff ALPACA beschrieben, der Dienste mit gemeinsamem Zertifikat ausnutzt ^[6]. Einzelzertifikate begrenzen den Schaden auf die eine Subdomain, deren Server betroffen ist.

Für das Wildcard-Zertifikat spricht ein anderer Punkt. Jedes ausgestellte Zertifikat landet in öffentlichen Certificate-Transparency-Logs, die jeder abfragen darf ^[5]. Mit Einzelzertifikaten steht damit jeder Subdomain-Name öffentlich im Netz, auch der Name eines Testsystems. Ein Wildcard-Zertifikat zeigt dort nur *.beispiel.de. Was die Logs über deine Domain verraten, kannst du mit dem Subdomain-Finder nachsehen. Der Begriff ist im Glossar unter Certificate Transparency erklärt.

Wildcards mit dem CAA-Eintrag steuern

Mit einem CAA-Eintrag im DNS legst du fest, welche Zertifizierungsstellen für deine Domain überhaupt Zertifikate ausstellen dürfen. RFC 8659 vom November 2019 kennt dafür zwei Angaben: issue für normale Namen und issuewild für Wildcard-Namen ^[10]. Steht issuewild in der Zone, gilt bei einem Antrag auf ein Wildcard-Zertifikat nur diese Angabe, und issue wird dafür ignoriert ^[10]. Ein issue-Eintrag mit dem Wert ";" bedeutet, dass niemand ausstellen darf ^[10].

Damit kannst du Wildcards gezielt sperren und Einzelzertifikate trotzdem erlauben. Zwei Zeilen in der Zone reichen: beispiel.de CAA 0 issue "letsencrypt.org" und beispiel.de CAA 0 issuewild ";". Den Namen letsencrypt.org nennt Let's Encrypt selbst für diesen Zweck ^[11]. Danach darf Let's Encrypt Zertifikate für einzelne Namen ausstellen, aber keine Zertifizierungsstelle mehr ein Wildcard-Zertifikat. Ohne issuewild-Eintrag gelten die issue-Einträge auch für Wildcards ^[11]. Umgekehrt kannst du mit issuewild eine andere Stelle für Wildcards zulassen als für Einzelzertifikate. Was es mit dem Eintrag sonst auf sich hat, steht im Glossar unter CAA-Eintrag.

Grenzen bei Let's Encrypt

Let's Encrypt begrenzt die Zahl der Zertifikate. Je registrierter Domain, also für beispiel.de mit allen Subdomains zusammen, sind 50 neue Zertifikate in sieben Tagen erlaubt ^[4]. Für genau dieselbe Namensliste gibt es höchstens fünf Zertifikate in sieben Tagen, und diese Grenze lässt sich nicht aufheben ^[4]. Ein Zertifikat darf höchstens 100 Namen enthalten ^[4]. Wer Dutzende Subdomains mit Einzelzertifikaten versorgt und sie alle am selben Tag neu ausstellt, kann an die Wochengrenze stoßen. Ein Wildcard-Zertifikat zählt dagegen nur einmal.

Wildcard in Plesk

In Plesk stellt die Erweiterung SSL It! die Zertifikate aus. Ein Wildcard-Zertifikat von Let's Encrypt kann sie nur automatisch ausstellen, wenn Plesk der primäre DNS-Server der Domain ist oder ein externer DNS-Dienst mit Plesk abgeglichen wird ^[7]. Bei der Option für das Wildcard-Zertifikat sind die www-Subdomain, Domain-Aliasse und Webmail abgedeckt ^[7]. Liegt das DNS woanders, ohne Abgleich, bleibt nur der Weg über Einzelzertifikate oder ein externes ACME-Programm. Weitere Einstellungen beschreibt Plesk: Domains, Subdomains und Zertifikate verwalten.

Welche Variante zu dir passt

• Zwei bis fünf Subdomains auf verschiedenen Servern: Einzelzertifikate über HTTP-01, jeder Server erneuert selbst.
• Eine feste Handvoll Subdomains auf einem Server: ein SAN-Zertifikat oder Einzelzertifikate, beides ohne DNS-Schnittstelle möglich.
• Viele oder ständig neue Subdomains auf einem Server, etwa für Kundenprojekte: ein Wildcard-Zertifikat, sofern dein DNS-Anbieter eine Schnittstelle für die automatische Erneuerung hat.
• Subdomains auf mehreren Ebenen: je Ebene ein eigenes Wildcard-Zertifikat oder Einzelzertifikate.

Wie du ein Zertifikat von Let's Encrypt beantragst, zeigt Let's Encrypt: kostenlose Zertifikate einrichten.

1. Gesetz RFC 9525: Service Identity in TLS, Abschnitte 6.3 und 7.1. IETF. Stand November 2023. abgerufen am 29.10.2026
2. Organisation Challenge Types. Let's Encrypt. Stand 12.02.2026. abgerufen am 29.10.2026
3. Organisation FAQ. Let's Encrypt. Stand 28.04.2025. abgerufen am 29.10.2026
4. Organisation Rate Limits. Let's Encrypt. Stand 05.08.2026. abgerufen am 29.10.2026
5. Gesetz RFC 6962: Certificate Transparency. IETF. Stand Juni 2013. abgerufen am 29.10.2026
6. Behörde Avoid Dangers of Wildcard TLS Certificates, the ALPACA Technique. National Security Agency (veröffentlicht über CSIAC). Stand 07.10.2021. abgerufen am 29.10.2026
7. Organisation Securing Connections with the SSL It! Extension. Plesk. Stand ohne Datum. abgerufen am 29.10.2026
8. Organisation Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1, Abschnitt 3.2.2.4. CA/Browser Forum. Stand 04.10.2026. abgerufen am 29.10.2026
9. Organisation Decreasing Certificate Lifetimes to 45 Days. Let's Encrypt. Stand 02.12.2025. abgerufen am 29.10.2026
10. Gesetz RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. IETF. Stand November 2019. abgerufen am 29.10.2026
11. Organisation Certificate Authority Authorization (CAA). Let's Encrypt. Stand 04.10.2026. 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.