2026-10-30 · RESEARCH · Das Offensive Technology-Team

Verbirgt ein Wildcard-Zertifikat Ihre Subdomains?

Verbirgt ein Wildcard-Zertifikat Ihre Subdomains? Größtenteils ja, aber fast niemand nutzt es tatsächlich so. Wir haben die aktuellen, aktiven Zertifikate von 660 Top-Domains über dieselben öffentlichen Certificate-Transparency-Logs ausgelesen, die jeder abfragen kann, und klassifiziert, was jedes einzelne davon preisgibt. 63.8% zählen mindestens eine echte Subdomain namentlich in einfachen SAN-Einträgen auf, ganz ohne Wildcard-Schutz. Nur 22.9% setzen ausschließlich auf eine Wildcard, und verbergen ihre Subdomain-Struktur so, wie es die Technologie ermöglicht. Rechnet man die 11.1% hinzu, die beides gleichzeitig tun, geben 74.8% der aktuellen Zertifikate von Top-Domains einen spezifischen Hostnamen preis, unabhängig davon, ob sie zusätzlich eine Wildcard besitzen. Eine Wildcard funktioniert tatsächlich wie vorgesehen. Fast niemand wählt sie aus diesem Grund.

Warum dies eine Entscheidung ist und nicht nur ein Standardwert

Wildcard- und SAN-Zertifikate (Subject Alternative Name) lösen dasselbe Problem, nämlich mehrere Hostnamen mit einem Zertifikat abzudecken, auf entgegengesetzte Weise. Eine Wildcard matcht ein Muster: *.example.com ist für jeden einstufigen Namen unter example.com gültig, ohne dass dieser Name jemals auf dem Zertifikat selbst erscheint. Ein SAN-Zertifikat listet Hostnamen stattdessen explizit auf, ein Zertifikat kann app.example.com, api.example.com, und admin.example.com, indem alle drei in das SAN-Feld eingetragen werden. Beides ist Standard, beides wird von jeder öffentlichen CA ausgestellt, und das Subject des Zertifikats verrät nicht, welcher Ansatz eine bewusste Entscheidung war und welcher nur ein Nebeneffekt des Toolings.

Dieser Nebeneffekt ist der Regelfall. Die kostenlose, automatisierte Ausstellung, wie sie fast jedes moderne Deployment nutzt, fordert typischerweise ein Zertifikat für genau den Hostnamen an, auf den ein Server konfiguriert ist. Setzt man zehn Subdomains mit zehn separaten automatisierten Zertifikatsanfragen auf, erhält man zehn SAN-Zertifikate, von denen jedes seinen eigenen Namen loggt, niemals eine einzelne Wildcard, die alle zehn abdeckt. Stattdessen eine Wildcard zu wählen, erfordert einen zusätzlichen Schritt, den die meisten Teams nie unternehmen, da der Standardpfad bereits ein funktionierendes Zertifikat liefert.

Die Daten: Was 660 aktuelle Zertifikate tatsächlich wählen

Für jede der 660 Top-Domains mit Certificate-Transparency-Historie haben wir das aktuellste Zertifikat aus unserem lokalen Cache genommen (in diesem Durchlauf null neue Anfragen an crt.sh, da der Datensatz aus drei früheren Research-Beiträgen wiederverwendet wurde) und dessen Subject- und SAN-Felder ausgelesen. Wir haben jedes Zertifikat danach klassifiziert, was es über das triviale, universelle Paar aus der reinen Domain und ihrer www.-Adresse hinaus preisgibt: einen reinen Wildcard-Eintrag, eine Wildcard plus benannte Hostnamen, benannte Hostnamen ganz ohne Wildcard oder keines von beidem.

Bernsteinfarbene Balken legen irgendwo auf dem Zertifikat einen spezifischen Hostnamen offen, türkisfarbene Balken nicht. Nur der 22.9%-Anteil reiner Wildcards und der 2.3%-Anteil reiner Apex-Einträge, zusammen 25.2% der Stichprobe, halten ihre Subdomain-Namen aus den öffentlichen Aufzeichnungen heraus. Die anderen drei von vier Domains geben genau jetzt mindestens einen echten Subdomain-Namen an jeden weiter, der Certificate Transparency liest.

Es bleibt selten bei nur einem Namen

Sobald ein Zertifikat überhaupt etwas preisgibt, bleibt es meist nicht bei einem einzelnen vereinzelten Hostnamen. Unter den 494 Zertifikaten, die mindestens eine spezifische Subdomain nannten, listet der typische Fall nur ein oder zwei auf, die Verteilung weist jedoch einen Long Tail auf: das am stärksten belegte Einzelzertifikat in der Stichprobe führt 70 verschiedene Subdomains auf, und 20 Zertifikate (4.0% aller offenlegenden Zertifikate) listen zehn oder mehr auf, wobei 9 davon 25 oder mehr auflisten. Ein Zertifikat dieser Größe verbirgt nichts, es gleicht eher einer öffentlichen Sitemap der Infrastruktur eines Unternehmens, ausgestellt in einem einzigen Request und protokolliert in einem einzigen Eintrag.

Diese letzte Zeile muss man sich auf der Zunge zergehen lassen. Ein Zertifikat in der Kategorie "mixed" enthält 94 verschiedene Wildcard-Einträge auf einem einzigen Schlüssel, neben benannten SANs. Das ist mit an Sicherheit grenzender Wahrscheinlichkeit ein Plattform- oder SaaS-Anbieter, der viele Kunden- oder regionale Subdomains auf einmal per Wildcard abdeckt. Das ist im Betrieb effizient. Es bedeutet aber auch, dass ein einziger privater Schlüssel, sollte er jemals entwendet werden, für jede Subdomain unter allen 94 Mustern gleichzeitig gilt, heute wie in Zukunft. Wildcards tauschen die Geheimhaltung von Subdomains gegen ein anderes Risiko ein: den Blast Radius, der an einem einzigen Schlüssel hängt.

Warum nicht einfach jeder eine Wildcard nutzt

Wenn eine Wildcard mehr verbirgt, warum nutzen dann nur 22.9% der Stichprobe ausschließlich eine? Es gibt einige praktische Gründe, von denen für sich genommen keiner ein Fehler ist:

• Automatisierung setzt standardmäßig auf Benennung, nicht auf Wildcards. Tools wie Certbot fordern ein Zertifikat für den Hostnamen an, auf den ein Server bereits antwortet. Stattdessen eine Wildcard zu erhalten, erfordert den Nachweis der Domainkontrolle über eine DNS-01-Challenge, ein zusätzlicher Schritt mit zusätzlichen Tools, den die meisten Deployments auslassen.
• Eine Wildcard deckt nur eine Ebene ab. *.example.com matcht app.example.com, aber nicht a.app.example.com. Jede echte zweistufige Hierarchie erfordert entweder eine zweite Wildcard oder benannte Einträge, was Unternehmen selbst dann wieder zur Enumeration verleitet, wenn sie bereits eine Wildcard besitzen.
• Der Blast Radius bei einem Key-Compromise ist real. Ein einziger privater Wildcard-Schlüssel kann, sobald er kompromittiert ist, jede abgedeckte Subdomain auf einmal imitieren. Ein kompromittierter Host-spezifischer Schlüssel betrifft hingegen immer nur diesen einen Host. Teams, die sensible, separat verwaltete Subdomains betreiben, entscheiden sich manchmal gezielt für benannte Zertifikate, um diesen Blast Radius klein zu halten, auch wenn sie dafür die Geheimhaltung der Subdomains aufgeben.
• Manche Audits fordern explizite Abdeckung. Einige Compliance- und Inventarisierungsprozesse lassen sich mit einem Zertifikat, das jeden abgedeckten Hostnamen explizit auflistet, einfacher durchführen als mit einem, das die Abdeckung über ein Muster zusichert.

So prüfen Sie Ihre eigene Domain

Das dauert weniger als eine Minute und erfordert lediglich einen Browser, da dabei dieselben öffentlichen Datensätze ausgelesen werden, die auch wir genutzt haben.

• Fragen Sie crt.sh nach Ihrem aktuellen Zertifikat ab. Öffnen Sie https://crt.sh/?q=yourdomain.com&output=json und prüfen Sie das Feld name_value des aktuellsten Eintrags oder prüfen Sie das Zertifikat Ihres Servers direkt mit openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Zählen Sie, was es tatsächlich preisgibt. Ein einzelner *.yourdomain.com-Eintrag ohne weitere Zusätze ist Wildcard-only. Alles andere, jeder benannte Host über die reine Domain und www. hinaus, ist über CT bereits öffentlich, unabhängig davon, ob Sie an anderer Stelle eine Wildcard besitzen.
• Treffen Sie die Abwägung bewusst. Wenn für Ihre Architektur die Geheimhaltung von Subdomains wichtiger ist als der Blast Radius bei einem Key-Compromise, wechseln Sie zu einer Wildcard und einem DNS-01-Ausstellungsprozess. Falls nicht, behandeln Sie zumindest jeden benannten SAN-Eintrag als dauerhaft öffentlich und verlassen Sie sich nicht länger darauf, dass eine unbenannte Subdomain Sicherheit bietet.

Was dies nicht beweist

Ehrliche Grenzen, denn eine Zahl ohne ihre Einschränkungen ist reines Marketing.

• Wir haben das aktuellste Zertifikat pro Domain analysiert, nicht die vollständige Historie. Eine Domain könnte jahrelang eine Wildcard genutzt und erst kürzlich einen benannten SAN-Eintrag hinzugefügt haben oder umgekehrt. Dies ist eine Momentaufnahme der aktuellen Offenlegung, kein langfristiges Verhaltensmuster.
• Ein benannter SAN-Eintrag ist kein Beweis dafür, dass der Dienst dahinter aktiv oder erreichbar ist. Wir haben lediglich den Hostnamen-Text auf einem Zertifikat klassifiziert, nichts weiter. Einige benannte Subdomains verweisen möglicherweise auf Infrastruktur, die gar nicht mehr existiert.
• Es handelt sich um eine Stichprobe von 660 Domains großer, etablierter Websites. Das Top-Sites-Ranking von Tranco tendiert zu Organisationen mit ausreichend Infrastruktur, um überhaupt mehr als einen Hostnamen zu benötigen. Eine andere Grundgesamtheit würde die genaue Verteilung verschieben.
• Dies misst Offenlegung, nicht Ausnutzbarkeit. Einen Subdomain-Namen zu kennen, ist reine Reconnaissance. Was ein Angreifer mit diesem Namen anfangen kann, hängt vollständig davon ab, was tatsächlich dahinter läuft.

Häufig gestellte Fragen

Verbirgt ein Wildcard-Zertifikat Subdomains?

Teilweise. Eine Wildcard für *.example.com protokolliert nur den Wildcard-String, keine spezifischen Labels. In unserer Stichprobe benennen jedoch 63.8% der aktuellen Zertifikate trotzdem eine echte Subdomain, und nur 22.9% verlassen sich rein auf eine Wildcard, ohne dass ein benannter Host offengelegt wird.

Können Subdomains, die durch eine Wildcard abgedeckt sind, trotzdem in Certificate-Transparency-Logs auftauchen?

Der Wildcard-Eintrag selbst erscheint nur als Muster, nicht als spezifischer Name. Doch in dem Moment, in dem ein separates Zertifikat einen Host explizit benennt, wird dieser Name vollständig protokolliert, selbst wenn parallel eine Wildcard existiert. 11.1% der Zertifikate hier tun beides.

Was ist der Unterschied zwischen einem Wildcard- und einem SAN-Zertifikat?

Eine Wildcard deckt ein Muster wie *.example.com ab, ohne eine Subdomain zu benennen. Ein SAN-Zertifikat listet spezifische Hostnamen explizit auf. Die automatisierte Ausstellung erzeugt standardmäßig SAN-Zertifikate für genau den Hostnamen, den ein Server betreibt, weshalb die Enumeration und nicht die Wildcard der Regelfall ist.

Ist ein Wildcard-Zertifikat sicherer, als jede Subdomain explizit aufzulisten?

Was die Geheimhaltung von Subdomain-Namen angeht: ja. Was den Blast Radius bei einem Key-Compromise angeht: nicht zwingend. Ein gestohlener Wildcard-Schlüssel ist für jede abgedeckte Subdomain gleichzeitig gültig, während ein kompromittierter Host-spezifischer Schlüssel nur diesen einen Host betrifft.

Was passiert, wenn der private Schlüssel eines Wildcard-Zertifikats kompromittiert wird?

Ein Angreifer kann sich für jede Subdomain unter diesem Muster ausgeben, bis das Zertifikat widerrufen und überall neu ausgestellt wird, wo es im Einsatz war. Ein Zertifikat in unserer Stichprobe wies 94 verschiedene Wildcard-Einträge auf einem einzigen Schlüssel auf, ein enormer Blast Radius, sollte dieser Schlüssel jemals kompromittiert werden.

Deckt eine Wildcard Subdomains von Subdomains ab?

Nein. *.example.com matcht a.example.com, aber nicht a.b.example.com. Ein zweistufiger Name erfordert eine eigene Wildcard oder einen expliziten SAN-Eintrag, ein Grund dafür, warum Organisationen Hostnamen selbst dann enumerieren, wenn sie zusätzlich eine Wildcard besitzen.

Wie nutzen Angreifer Certificate-Transparency-Logs, um Subdomains aus SAN-Listen zu enumerieren?

Jedes von einer öffentlichen CA ausgestellte Zertifikat wird gemäß RFC 6962 protokolliert und ist kostenlos über crt.sh durchsuchbar. Ein Zertifikat, das Hostnamen namentlich aufzählt, liefert einem Angreifer eine fertige Übersicht aller Subdomains, ganz ohne Scanning.

Sollte man aus Sicherheitsgründen und nicht nur aus Bequemlichkeit Wildcard oder SAN wählen?

Wenn die Geheimhaltung von Subdomain-Namen eine Rolle spielt, ist eine Wildcard die stärkere Vorgabe, und die meisten Organisationen in dieser Stichprobe treffen diese Wahl nicht. Wenn Sie Hostnamen einzeln aufführen, betrachten Sie jeden benannten SAN-Eintrag als dauerhaft öffentlich und wägen Sie das Key-Compromise-Risiko ab, bevor Sie wechseln.

Weiterführende Artikel

• Wie Certificate-Transparency-Logs interne Subdomains preisgeben Derselbe Cache, die inhaltliche Frage: Welche Kategorien interner Hostnamen tauchen tatsächlich auf, sobald ein Zertifikat diese offenlegt.
• Wie lange dauert es, bis ein Zertifikat in CT auftaucht? Dasselbe crt.sh-Themenfeld, die zeitliche Frage statt der Frage nach der Offenlegung.
• Ist die 200-Tage-Zertifikatsregel bereits in Kraft getreten? Ein dritter Blickwinkel auf denselben Cache aus 660 Domains: Wie lange Zertifikate gültig sein dürfen, nicht was sie offenlegen.