Wildcard-Zertifikat: ein Zertifikat für alle Subdomains

Ein Wildcard-Zertifikat gilt für alle Subdomains einer Domain auf einmal. Statt für shop.beispiel.de, blog.beispiel.de und kunde1.beispiel.de je ein eigenes Zertifikat zu holen, deckt ein Zertifikat für *.beispiel.de alle ab, auch solche, die Sie erst nächstes Jahr anlegen. Das ist praktisch, aber nicht immer die beste Wahl. Seit es kostenlose Zertifikate gibt, die sich selbst erneuern, ist ein eigenes Zertifikat pro Subdomain oft einfacher und sicherer.

Was ein Wildcard Zertifikat abdeckt

Das Sternchen steht für genau eine Ebene vor der Domain. Ein Zertifikat für *.beispiel.de gilt für www.beispiel.de, shop.beispiel.de und mail.beispiel.de. Es gilt nicht für beispiel.de selbst und nicht für tiefere Ebenen wie test.shop.beispiel.de.

Die Hauptdomain fehlt also. Fast alle Anbieter nehmen sie deshalb als zweiten Namen mit in das Zertifikat auf, und bei Let's Encrypt geben Sie beide Namen einfach zusammen an. Für eine weitere Ebene brauchen Sie einen eigenen Stern, etwa für *.shop.beispiel.de. Wie Subdomains überhaupt entstehen, zeigt der Ratgeber zum Thema Subdomain einrichten.

Die Alternativen

Ein Zertifikat pro Name. Jede Subdomain bekommt ihr eigenes Zertifikat, bei den meisten Hostern automatisch von Let's Encrypt. Das ist kostenlos, erneuert sich selbst, und jedes Zertifikat hat seinen eigenen Schlüssel.

Ein Zertifikat mit mehreren Namen. Ein sogenanntes SAN- oder Multi-Domain-Zertifikat enthält eine feste Liste von Namen, auch von verschiedenen Domains, etwa beispiel.de, www.beispiel.de und beispiel.com. Neue Namen erfordern ein neues Zertifikat.

Wildcard. Ein Zertifikat für alle Namen einer Ebene, auch für künftige. Bei Let's Encrypt kostenlos, aber nur mit einer Prüfung über DNS. Bei kommerziellen Anbietern kostet es deutlich mehr als ein einfaches Zertifikat. Die Unterschiede der Prüfstufen DV, OV und EV erklärt der Vergleich der SSL-Typen. Eine Besonderheit: Mit erweiterter Prüfung, also als EV-Zertifikat, gibt es Wildcards gar nicht.

Wann sich ein Wildcard Zertifikat lohnt

• Viele oder wechselnde Subdomains: Etwa eine Anwendung, in der jeder Kunde eine eigene Adresse wie kunde42.beispiel.de bekommt. Ein Zertifikat pro neuem Kunden wäre hier mühsam, und bei Let's Encrypt gibt es Grenzen, wie viele Zertifikate pro Woche ausgestellt werden.
• Interne Namen nicht veröffentlichen: Jedes öffentliche Zertifikat landet in öffentlichen Protokollen, den sogenannten Certificate Transparency Logs. Wer dort sucht, sieht alle Namen, für die Sie Zertifikate haben, auch intern-buchhaltung.beispiel.de. Bei einem Wildcard-Zertifikat steht dort nur *.beispiel.de. Ganz geheim bleiben die Namen trotzdem nicht: Wer Ihre DNS-Einträge abfragt oder durchprobiert, findet sie weiterhin. Das Zertifikat verrät sie nur nicht zusätzlich.
• Ein Server für viele Subdomains: Ein Reverse Proxy, der alle Subdomains an verschiedene Anwendungen verteilt, kommt mit einem Zertifikat aus.

Für eine normale Website mit www und zwei, drei Subdomains brauchen Sie keinen Stern im Zertifikat. Die automatischen Zertifikate pro Name sind dort einfacher.

Die Risiken

Ein Wildcard-Zertifikat hat einen einzigen privaten Schlüssel für alle Subdomains. Wird er gestohlen, kann ein Angreifer jede beliebige Subdomain Ihrer Domain mit gültigem Zertifikat vortäuschen, sofern er den Verkehr umleiten kann. Das wiegt umso schwerer, je mehr Server den Schlüssel kennen. Liegt dasselbe Zertifikat auf dem Webserver, dem Mailserver und einem alten Testserver, reicht eine Lücke auf dem schwächsten davon.

Halten Sie die Zahl der Server mit diesem Schlüssel deshalb klein. Für eine einzelne wichtige Anwendung, etwa den Login oder den Shop, kann ein eigenes Zertifikat neben dem Wildcard sinnvoll sein.

Wildcard Zertifikat mit Let's Encrypt

Let's Encrypt stellt Wildcard-Zertifikate kostenlos aus, verlangt aber einen Nachweis über DNS. Sie müssen zeigen, dass Sie die DNS-Einträge der Domain ändern können. Dazu legt Ihr Programm einen TXT-Eintrag mit dem Namen _acme-challenge.beispiel.de und einem zufälligen Wert an. Let's Encrypt prüft den Eintrag und stellt das Zertifikat aus. Die übliche Prüfung über eine Datei auf dem Webserver reicht für Wildcards nicht. Die verschiedenen Prüfverfahren beschreibt die Dokumentation von Let's Encrypt.

Im Kundenmenü. Liegt die Domain samt DNS bei Ihrem Hoster, gibt es oft eine Option „Wildcard“ beim Let's-Encrypt-Zertifikat. Der Hoster legt den TXT-Eintrag selbst an und erneuert das Zertifikat automatisch. Das ist der einfachste Weg.

Mit Certbot und einer DNS-Schnittstelle. Auf einem eigenen Server braucht Certbot Zugriff auf die Schnittstelle Ihres DNS-Anbieters, um den Eintrag bei jeder Erneuerung selbst zu setzen. Für viele Anbieter gibt es Erweiterungen. Am Beispiel eines Anbieters mit eigener Erweiterung sieht das so aus:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/dns.ini \
  -d beispiel.de -d '*.beispiel.de'

Die Datei mit dem Zugangsschlüssel für die DNS-Schnittstelle schützen Sie mit chmod 600, denn wer sie hat, kann Ihre DNS-Einträge ändern. Geben Sie dem Schlüssel nur die Rechte, die er braucht, meist nur das Bearbeiten der Einträge dieser einen Domain. Die Erneuerung läuft danach automatisch über den Timer von Certbot. Ein Programm mit Unterstützung für besonders viele DNS-Anbieter ist acme.sh.

Von Hand. Mit --manual --preferred-challenges dns fragt Certbot Sie nach dem TXT-Eintrag, und Sie legen ihn selbst an. Das funktioniert für einen Test. Da Zertifikate von Let's Encrypt derzeit 90 Tage gelten, müssten Sie das aber alle paar Wochen wiederholen. Für den Betrieb ist das keine Lösung. Weitere Grundlagen zu Certbot stehen im Ratgeber zu Let's Encrypt.

Kommerzielle Wildcard-Zertifikate

Ein gekauftes Wildcard-Zertifikat kann sinnvoll sein, wenn Ihre Firma ein OV-Zertifikat mit geprüftem Firmennamen braucht oder eine Anwendung keine automatische Erneuerung unterstützt. Auch kommerzielle Zertifikate werden aber kürzer. Die Höchstdauer sinkt in mehreren Stufen, seit März 2026 sind es höchstens 200 Tage, bis 2029 werden es 47 Tage. Spätestens dann führt an einer automatischen Erneuerung kaum ein Weg vorbei, auch bei gekauften Zertifikaten.

Das Zertifikat einbinden und prüfen

Auf dem Webserver binden Sie das Zertifikat in jedem Server-Block oder jedem virtuellen Host ein, der eine Subdomain bedient. Mit Certbot liegen die Dateien unter /etc/letsencrypt/live/beispiel.de/, also fullchain.pem und privkey.pem. Laden Sie den Webserver nach jeder Erneuerung neu. Certbot erledigt das, wenn Sie einen sogenannten Deploy-Hook setzen, etwa mit --deploy-hook "systemctl reload nginx" beim ersten Abruf.

Bei Nginx sieht die Einbindung für jede Subdomain gleich aus, nur der Name wechselt:

server {
    listen 443 ssl;
    server_name shop.beispiel.de;
    ssl_certificate     /etc/letsencrypt/live/beispiel.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/beispiel.de/privkey.pem;
    # weitere Einstellungen der Subdomain
}

Ob eine Subdomain das richtige Zertifikat bekommt, prüfen Sie im Browser über das Schloss neben der Adresse oder auf der Konsole:

openssl s_client -connect shop.beispiel.de:443 -servername shop.beispiel.de </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -enddate

Die Ausgabe zeigt die enthaltenen Namen und das Ablaufdatum. Steht dort *.beispiel.de und beispiel.de, ist alles richtig. Damit ein abgelaufenes Zertifikat nicht unbemerkt bleibt, lassen Sie das Ablaufdatum von einem Monitoring überwachen, wie im Ratgeber zum Website-Monitoring beschrieben.

Typische Fehler mit Wildcard-Zertifikaten

• Hauptdomain vergessen: Das Zertifikat gilt für alle Subdomains, aber beispiel.de zeigt eine Warnung. Geben Sie beide Namen an.
• Zweite Ebene erwartet: test.shop.beispiel.de ist nicht abgedeckt. Dafür braucht es *.shop.beispiel.de.
• Erneuerung von Hand: Ein manuell geholtes Zertifikat läuft nach 90 Tagen ab, und niemand merkt es bis zur Warnung im Browser.
• Zugangsschlüssel für DNS mit vollen Rechten: Wer ihn findet, kann alle Domains Ihres Kontos umleiten. Beschränken Sie ihn auf eine Domain und nur auf DNS.
• Kopien auf vielen Servern: Bei der Erneuerung bekommt einer davon das neue Zertifikat nicht und liefert nach Ablauf eine Fehlermeldung. Verteilen Sie neue Zertifikate automatisch, etwa über den Deploy-Hook, oder bündeln Sie die Subdomains hinter einem Reverse Proxy.
• CAA-Eintrag übersehen: Ein CAA-Eintrag im DNS legt fest, welche Zertifizierungsstellen für Ihre Domain ausstellen dürfen. Gibt es Einträge vom Typ issuewild, gelten für Wildcards nur diese. Fehlt dort Ihre Stelle, lehnt sie die Ausstellung ab.