Wildcard-SSL-Zertifikate verstehen

Was ein Wildcard-SSL-Zertifikat ist

Ein SSL/TLS-Zertifikat verknüpft einen öffentlichen Schlüssel mit einem oder mehreren Hostnamen, damit Browser prüfen können, dass sie mit dem richtigen Server sprechen, und die Verbindung verschlüsseln. Ein Standardzertifikat listet konkrete Namen wie example.com und www.example.com. Ein Wildcard-Zertifikat enthält dagegen einen Namen mit einem Sternchen ganz links, etwa *.example.com, das auf jedes einzelne Label an dieser Position passt.

Dieser eine Eintrag deckt shop.example.com, blog.example.com, api.example.com und jede weitere Subdomain der ersten Ebene ab, die Sie später anlegen – ohne das Zertifikat neu ausstellen zu lassen. Für Organisationen, die regelmäßig Subdomains hinzufügen, spart das viel Verwaltungsaufwand.

Was eine Wildcard abdeckt und was nicht

Die Wildcard-Zuordnung folgt strengen Regeln aus den TLS- und Zertifikatsstandards. Das Sternchen ersetzt genau ein Label, und zwar nur an der linken Position.

In der Praxis fügen die meisten Zertifizierungsstellen die Hauptdomain automatisch neben der Wildcard hinzu oder lassen Sie beide Namen gemeinsam beantragen. Prüfen Sie bei der Bestellung, dass das Zertifikat sowohl example.com als auch *.example.com enthält.

Verfügbare Validierungsstufen

Wildcards können als domainvalidierte (DV) Zertifikate ausgestellt werden, die die Kontrolle über die Domain belegen, oder als organisationsvalidierte (OV) Zertifikate, bei denen zusätzlich die juristische Organisation geprüft wird. Die Branchenregeln erlauben keine Extended-Validation-Wildcards (EV). Benötigen Sie EV für einen bestimmten Hostnamen, muss dieser explizit aufgeführt werden.

Wildcard vs. Multi-Domain-Zertifikat (SAN)

Die wichtigste Alternative ist ein Multi-Domain-Zertifikat, das mehrere konkrete Namen im Feld Subject Alternative Name (SAN) auflistet. Beide Ansätze lösen unterschiedliche Probleme und lassen sich in einem Zertifikat kombinieren.

Ein nützlicher Nebeneffekt von Wildcards ist Privatsphäre: Certificate-Transparency-Logs veröffentlichen jeden Namen jedes öffentlich vertrauenswürdigen Zertifikats. Ein SAN-Zertifikat verrät jeden internen Hostnamen, eine Wildcard nur das Muster. Das ist für sich genommen keine Sicherheitsmaßnahme, verringert aber, wie viel Ihrer Infrastruktur öffentlich gelistet ist.

So erhalten Sie ein Wildcard-Zertifikat

Kommerzielle Zertifizierungsstellen verkaufen Wildcard-Zertifikate, ACME-basierte Stellen wie Let’s Encrypt stellen sie kostenlos aus. In beiden Fällen erzeugen Sie einen privaten Schlüssel und eine Zertifikatsignierungsanforderung (CSR), weisen die Kontrolle über die Domain nach und installieren das ausgestellte Zertifikat.

DNS-01-Validierung

Für Wildcard-Namen verlangen ACME-Stellen die DNS-01-Challenge. Sie weisen die Kontrolle nach, indem Sie unter _acme-challenge.example.com einen TXT-Eintrag mit einem von der Stelle vorgegebenen Token veröffentlichen. HTTP-basierte Validierung wird für Wildcards nicht akzeptiert, weil eine Datei auf einem Host nicht die Kontrolle über jede mögliche Subdomain belegt.

Mit Certbot sieht eine manuelle Anfrage so aus:

certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"

Eine manuelle DNS-Validierung verlängert sich nicht automatisch. Für eine wartungsfreie Verlängerung nutzen Sie ein DNS-Plugin oder einen ACME-Client, der die API Ihres DNS-Anbieters unterstützt, damit der Client den TXT-Eintrag selbst anlegen und entfernen kann. Vor der Validierung können Sie prüfen, ob der Eintrag sichtbar ist:

dig +short TXT _acme-challenge.example.com

Wenn Sie mit CAA-Einträgen einschränken, welche Stellen für Ihre Domain ausstellen dürfen, beachten Sie, dass sich die Wildcard-Ausstellung separat über die Eigenschaft issuewild steuern lässt. Unser Leitfaden zur korrekten Konfiguration von CAA-Einträgen erklärt die Syntax.

Wildcard-SSL für Onlineshops

Onlineshops verteilen ihre Plattform oft auf Subdomains: die Storefront auf www, ein Kundenkonto auf account, den Checkout auf checkout oder pay, ein Hilfecenter auf help, statische Dateien auf cdn und regionale Shops auf uk oder de. Ein Wildcard-Zertifikat kann all das mit einer Bestellung und einem Verlängerungstermin abdecken, was mehrere praktische Vorteile bringt:

• Schnellere Starts. Neue Kampagnenseiten, regionale Shops oder Staging-Umgebungen erhalten sofort gültiges HTTPS.
• Weniger Lücken. Eine vergessene Subdomain ohne HTTPS löst Browserwarnungen aus, die das Vertrauen im ungünstigsten Moment beschädigen können.
• Einfachere Verwaltung. Ein Zertifikat überwachen statt vieler einzelner mit unterschiedlichen Ablaufdaten.

Diese Vorteile müssen gegen Risiken abgewogen werden. Zahlungsseiten sind der sensibelste Teil eines Shops, und Compliance-Rahmenwerke wie PCI DSS erwarten einen starken Schlüsselschutz und eine klare Netzwerksegmentierung. Viele Teams verwenden daher ein eigenes Zertifikat für Checkout- und Zahlungs-Hosts und eine Wildcard für Marketing-, Inhalts- und Asset-Subdomains. Besprechen Sie das passende Design mit der Stelle, die Ihre Compliance-Prüfung durchführt; dies sind allgemeine Informationen, keine Rechts- oder Compliance-Beratung.

Sicherheitsrisiken und bewährte Praxis

Das größte Risiko einer Wildcard besteht darin, dass ein privater Schlüssel jede passende Subdomain schützt. Gelangt der Schlüssel von irgendeinem Server, auf dem er liegt, nach außen, könnte ein Angreifer jede Subdomain imitieren, bis das Zertifikat widerrufen und ersetzt ist. Verringern Sie dieses Risiko mit folgenden Gewohnheiten:

1. Verteilung begrenzen. Installieren Sie die Wildcard nur auf Servern, die Sie selbst kontrollieren und pflegen, nicht auf Drittanbieter- oder Altsystemen.
2. Terminierungspunkte bevorzugen. Terminieren Sie TLS an einem Load Balancer oder Reverse Proxy, damit weniger Maschinen den Schlüssel besitzen.
3. Den Schlüssel schützen. Beschränken Sie Dateirechte, verschicken Sie Schlüssel nicht per E-Mail und nutzen Sie, wo möglich, einen Secrets-Manager oder ein Hardware-Modul.
4. Eigene Zertifikate für Hochrisiko-Hosts. Zahlungs-, Admin- und Authentifizierungs-Endpunkte profitieren von eigenen Schlüsseln.
5. Einen Widerrufsplan haben. Wissen Sie, wie Sie bei einem kompromittierten Server schnell widerrufen und neu ausstellen.
6. Auf Subdomain-Übernahmen achten. Entfernen Sie DNS-Einträge für Dienste, die Sie nicht mehr nutzen, denn eine gültige Wildcard lässt eine gekaperte Subdomain voll vertrauenswürdig erscheinen.

Zertifikatslaufzeiten und Ablaufüberwachung

Die Laufzeiten öffentlich vertrauenswürdiger Zertifikate werden kürzer. Nach dem Zeitplan des CA/Browser Forums sank die maximale Gültigkeit im März 2026 von 398 auf 200 Tage; weitere Verkürzungen auf 100 Tage im Jahr 2027 und 47 Tage im Jahr 2029 sind geplant. Kostenlose ACME-Zertifikate sind bereits kurzlebig und auf automatische Verlängerung ausgelegt. Prüfen Sie die aktuellen Richtlinien Ihrer Zertifizierungsstelle, da genaue Termine und Verfahren angepasst werden können.

Kürzere Laufzeiten machen Automatisierung unverzichtbar, doch auch Automatisierung scheitert: DNS-API-Zugangsdaten laufen ab, ein Server wird migriert und der Verlängerungsjob nicht mitkopiert, oder eine manuell ausgestellte Wildcard wird schlicht vergessen. Da eine Wildcard oft viele Dienste gleichzeitig schützt, kann eine verpasste Verlängerung eine ganze Plattform lahmlegen statt nur einer einzelnen Website. Das aktuelle Zertifikat eines Hosts prüfen Sie so:

openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName

TLDix kann Ablaufdaten von SSL-Zertifikaten zusammen mit Domains und Hosting-Tarifen überwachen und vor dem Ablauf Warnungen senden. Fügen Sie Ihre Hosts im TLDix-Panel hinzu und lesen Sie unsere Best Practices zur Domain-Sicherheit für verwandte Schutzmaßnahmen.

Ein Wildcard-Zertifikat installieren und testen

Nach der Ausstellung wird eine Wildcard wie jedes andere Zertifikat installiert: Laden Sie Zertifikat, Zwischenzertifikatskette und privaten Schlüssel auf Ihren Webserver, Load Balancer oder in Ihr Hosting-Panel. Fehlende Zwischenzertifikate sind eine häufige Fehlerursache auf manchen Geräten, installieren Sie daher immer die vollständige Kette, die die Zertifizierungsstelle bereitstellt. Testen Sie nach der Installation mehrere Subdomains statt nur einer, da jeder virtuelle Host auf eine andere Zertifikatsdatei verweisen kann. Prüfen Sie, ob HTTP-Anfragen auf HTTPS umgeleitet werden, ob Namen und Ablaufdatum des Zertifikats stimmen und ob ältere Protokollversionen gemäß den aktuellen Sicherheitsempfehlungen Ihres Servers deaktiviert sind.

Typische Fehler nach der Umstellung

Nach dem Wechsel auf eine Wildcard treten einige Probleme immer wieder auf. Ein Host liefert noch das alte Einzelzertifikat aus, weil seine Konfiguration nicht aktualisiert wurde. Ein Dienst auf einer zweiten Subdomain-Ebene zeigt einen Namensfehler, da die Wildcard ihn nicht abdeckt. Oder ein CDN beziehungsweise externer Dienst nutzt ein eigenes Zertifikat, das unabhängig verlängert werden muss. Führen Sie eine kurze Liste aller Hosts, die das Wildcard-Zertifikat verwenden, und gehen Sie diese Liste nach jeder Verlängerung einmal durch.

Ist eine Wildcard das Richtige für Sie?

Ein Wildcard-Zertifikat ist eine gute Wahl, wenn Sie viele Subdomains unter einer Domain betreiben, häufig neue anlegen und den privaten Schlüssel auf wenigen gut verwalteten Systemen halten können. Ein SAN-Zertifikat oder Einzelzertifikate sind oft besser, wenn Sie mehrere verschiedene Domains bedienen, EV für einen bestimmten Host benötigen oder sensible Dienste isolieren möchten. Viele Organisationen landen bei einer Mischung: Wildcards für allgemeine Subdomains, eigene Zertifikate für kritische Endpunkte und automatische Verlängerung mit unabhängiger Ablaufüberwachung für alle.