Ein Wildcard-Zertifikat sichert eine einzelne Subdomain-Ebene ganz links unter einem Namen ab (*.example.com), während ein SAN-Zertifikat (auch UCC- oder Multi-Domain-Zertifikat genannt) eine explizite Liste von Hostnamen in seiner Subject-Alternative-Name-Erweiterung aufführt. Keines von beiden ist grundsätzlich „besser“. Sie lösen unterschiedliche Abdeckungsprobleme, und eine falsche Wahl zeigt sich meist erst später als unerwarteter Zertifikatsfehler auf einer Subdomain, an deren Aufnahme niemand gedacht hat.
Was ein Wildcard-Zertifikat tatsächlich abdeckt
Ein Wildcard-Zertifikat verwendet ein Sternchen im Label ganz links, etwa *.example.com. Laut RFC 6125 darf dieses Sternchen nur ein vollständiges Label ganz links ersetzen. *.example.com ist gültig, *.sub.example.com ist als eigene, separate Wildcard ebenfalls gültig. f*.example.com (Teil-Label) und *.*.example.com (mehrere Labels) sind dagegen keine Standard-Wildcard-Syntax, die öffentliche Zertifizierungsstellen (CAs) ausstellen.
Das Detail, über das viele stolpern: Eine Wildcard deckt die nackte Apex-Domain nicht ab, und sie reicht nicht tiefer als eine Ebene. *.example.com schützt www.example.com und api.example.com, aber weder example.com selbst noch a.b.example.com. Soll auch die Apex-Domain abgedeckt sein, fügst du sie als zweiten SAN-Eintrag auf demselben Zertifikat hinzu. Die meisten Aussteller erledigen das automatisch, wenn du eine Wildcard über ihren Standardprozess beantragst. Trotzdem lohnt es sich, die resultierende SAN-Liste zu prüfen, statt es einfach anzunehmen.
Öffentliche CAs stellen außerdem keine Wildcard auf oder oberhalb der Public-Suffix-Ebene aus. Ein *.co.uk bekommst du von einer öffentlich vertrauenswürdigen CA aus naheliegenden Gründen nicht.
WarningÖffentliche CAs stellen Wildcard-Zertifikate nur über DNS-01-Domainvalidierung aus, also über den Nachweis der Kontrolle über die DNS-Zone durch das Veröffentlichen eines TXT-Eintrags. HTTP-basierte Validierung kann die Kontrolle über Subdomains, die noch gar nicht existieren, nicht belegen. Ist dein DNS auf mehrere Anbieter verteilt oder hinter einem Change-Control-Prozess gesperrt, plane diese Vorlaufzeit bei Verlängerungen ein.
Was ein SAN-Zertifikat tatsächlich abdeckt
Ein SAN-Zertifikat listet jeden geschützten Hostnamen einzeln in der subjectAltName-Erweiterung des Zertifikats auf. www.example.com, app.example.com, example.net und shop.example.org können alle auf einem Zertifikat stehen, sogar über völlig unabhängige Domains hinweg. Auf Protokollebene gibt es keine Obergrenze dafür, wie viele Namen ein Zertifikat enthalten darf (RFC 5280 legt keine fest), aber CAs setzen eigene praktische Grenzen, häufig irgendwo im Bereich von 100–250 Namen, je nach Anbieter und Produktstufe. Prüfe also die aktuelle Dokumentation der ausstellenden CA, wenn du eine große Liste aufbaust.
Jeder Name auf einem SAN-Zertifikat kann grundsätzlich eine andere Validierungsmethode nutzen, und eine SAN-Liste kann exakte Hostnamen mit Wildcard-Einträgen mischen, zum Beispiel *.example.com, example.com und api.partner-domain.com auf einem einzigen Zertifikat. Diese Flexibilität ist der Hauptgrund, warum es SAN-Zertifikate gibt: Mit ihnen deckt ein Zertifikat eine verstreute Menge von Diensten ab, die keinem sauberen Subdomain-Muster folgen.
Wildcard vs. SAN im Überblick
| Wildcard | SAN / UCC | |
|---|---|---|
| Deckt ab | Eine Subdomain-Ebene unter einem Namen | Jeden aufgeführten Hostnamen explizit |
| Apex-Domain | Nicht automatisch enthalten | Als eigenen SAN-Eintrag hinzufügen |
| Neue Subdomains | Automatisch abgedeckt, wenn unter der Wildcard | Müssen hinzugefügt und das Zertifikat neu ausgestellt werden |
| Validierung | Nur DNS-01 (öffentliche CAs) | Je nach Name unterschiedlich |
| Ideal für | Viele Subdomains, ein Muster | Eine feste, gemischte Liste von Hostnamen/Domains |
| Max. Gültigkeit | 398 Tage (öffentliche CAs, wie bei jedem Zertifikat) | 398 Tage |
Wann du ein Wildcard-Zertifikat nutzen solltest
Greif zur Wildcard, wenn unter einem Namen häufig und vorhersehbar neue Subdomains entstehen, etwa Subdomains pro Kunde auf einer SaaS-Plattform (tenant1.example.com, tenant2.example.com) oder ein Microservices-Setup, in dem neue interne Dienste unter *.internal.example.com schneller auftauchen, als irgendjemand eine SAN-Liste pflegen möchte. Ein Zertifikat deckt all das stillschweigend ab, und du musst nicht jedes Mal neu ausstellen, wenn eine neue Subdomain live geht.
Der Haken: Ein kompromittierter privater Schlüssel einer Wildcard legt alle aktuellen und künftigen Subdomains unter diesem Namen auf einen Schlag offen. Das ist ein größerer Schadensradius als ein einzelnes gestohlenes SAN-Zertifikat mit einer festen Liste. Wenn du eine Wildcard einsetzt, schütze den privaten Schlüssel entsprechend und behalte die Certificate-Transparency-Logs im Blick, um Zertifikate für deine Domain zu entdecken, die du nicht beantragt hast.
Wann du ein SAN-Zertifikat nutzen solltest
SAN-Zertifikate sind sinnvoll, wenn du eine bekannte, relativ stabile Menge von Hostnamen hast, die keinem einheitlichen Muster folgen: eine Marketing-Website auf der Apex-Domain, eine App auf einer Subdomain, eine API auf einer anderen TLD, vielleicht noch eine Partner-Domain, für die du ebenfalls TLS terminierst. Die explizite Auflistung hält den Schadensradius kleiner (nur die genannten Hosts sind abgedeckt) und macht die Validierung Name für Name nachvollziehbar.
Der Nachteil liegt hier umgekehrt: Jeder neue Hostname bedeutet, die SAN-Liste zu bearbeiten und das Zertifikat neu auszustellen. Ändert sich deine Liste wöchentlich, summiert sich dieser Aufwand schnell, und eine Wildcard (oder Automatisierung) wird attraktiver.
TipDu musst dich nicht ausschließlich für eins entscheiden. Ein einzelnes Zertifikat kann einen Wildcard-Eintrag mit expliziten SAN-Hostnamen kombinieren.
*.example.complusexample.complusapi.partner.comauf einem Zertifikat ist gültig und in der Praxis verbreitet.
Prüfen, was wirklich im Zertifikat steht
Schließ nicht allein aus dem Common Name des Zertifikats auf die Abdeckung. Der Common Name ist heute oft nur noch informativ; entscheidend für den Abgleich ist die SAN-Liste. Prüfe jedes Live-Zertifikat mit unserem kostenlosen SSL-Checker, um alle SAN-Einträge, das Ablaufdatum und die Zertifikatskette in einer Ansicht zu sehen. So bestätigst du am schnellsten, dass eine Wildcard wirklich abdeckt, was du denkst, oder entdeckst ein SAN-Zertifikat mit fehlendem Hostnamen, bevor ein Browser es für dich tut.
Wenn du unabhängig von der SAN-/Wildcard-Form noch zwischen einem kostenlosen automatisierten und einem kommerziellen Zertifikat schwankst, wirf einen Blick auf unseren Vergleich Let's Encrypt vs. kommerzielle SSL-Zertifikate. Die Wahl zwischen Wildcard und SAN ist von dieser Entscheidung unabhängig, und beide Ausstellungswege unterstützen beide Formen.
SSL-Zertifikate automatisch erneuern – ohne Tabellenkalkulation
Egal, für welche Form du dich entscheidest, das betriebliche Risiko bleibt dasselbe: ein Zertifikat, das unbemerkt abläuft oder einen Hostnamen nicht mehr abdeckt, den jemand letzten Monat hinzugefügt hat. Das Zertifikatsmanagement von InfraNest überwacht jedes Zertifikat bei jedem Anbieter, meldet Lücken in der SAN-Abdeckung und automatisiert die Verlängerung, sodass Wildcard- und SAN-Zertifikate gleichermaßen vor dem Ablauf neu ausgestellt werden – und nicht erst, nachdem ein Kunde eine Browserwarnung meldet.
Häufig gestellte Fragen
#Kann ein Wildcard-Zertifikat auch die nackte Apex-Domain abdecken?
Nicht automatisch. Eine Wildcard wie *.example.com deckt nur eine Subdomain-Ebene ab; die Apex-Domain (example.com) muss als eigener SAN-Eintrag hinzugefügt werden. Die meisten Aussteller tun das standardmäßig, wenn du beim Beantragen des Zertifikats beides anforderst.
#Ist ein Wildcard-Zertifikat günstiger als ein SAN-Zertifikat mit derselben Anzahl an Namen?
Die Preise variieren je nach CA, aber Wildcards werden meist so verkauft, dass sie unbegrenzt viele Subdomains auf einer Ebene unter einem Namen abdecken, während SAN-Zertifikate in der Regel pro benanntem Host oder gestaffelt nach Anzahl der SANs berechnet werden. Vergleiche die aktuellen Preise der jeweiligen CA, statt anzunehmen, dass eine Variante günstiger ist.
#Kann ich einen Wildcard-Eintrag in ein SAN-Zertifikat aufnehmen?
Ja. Eine SAN-Liste kann einen Wildcard-Eintrag (z. B. *.example.com) mit expliziten Hostnamen und sogar unabhängigen Domains auf demselben Zertifikat kombinieren. Das ist ein gängiger Weg, die Abdeckung beider Ansätze zu vereinen.
#Brauchen Wildcard-Zertifikate eine andere Validierungsmethode als SAN-Zertifikate?
Öffentliche CAs validieren Wildcard-Einträge nur über DNS-01 (ein DNS-TXT-Eintrag, der die Kontrolle über die Zone belegt), weil HTTP-basierte Validierung die Kontrolle über noch nicht existierende Subdomains nicht bestätigen kann. Einzelne SAN-Hostnamen können in der Regel DNS-01 oder HTTP-01 nutzen, je nachdem, was die CA für den jeweiligen Namen unterstützt.
Mit einem kostenlosen Tool ausprobieren
War dieser Artikel hilfreich?
