2026-10-30 · ONDERZOEK · Het Offensive Technology-team

Verbergt een wildcardcertificaat je subdomeinen?

Verbergt een wildcardcertificaat je subdomeinen? Grotendeels wel, maar vrijwel niemand gebruikt er daadwerkelijk een op die manier. We hebben het huidige, actieve certificaat voor 660 topdomeinen bekeken via dezelfde publieke Certificate Transparency-logs die iedereen kan bevragen, en geclassificeerd wat elk certificaat prijsgeeft. 63.8% vermeldt ten minste één echt subdomein bij naam in gewone SAN-vermeldingen, zonder enige wildcard-bescherming. Slechts 22.9% vertrouwt puur op een wildcard, waarmee ze hun subdomeinstructuur verbergen zoals de technologie toestaat. Tel daar de 11.1% bij op die beide tegelijk doen, en 74.8% van de huidige certificaten op topdomeinen geeft een specifieke hostnaam prijs, ongeacht of ze daarnaast een wildcard hebben. Een wildcard werkt daadwerkelijk zoals ontworpen. Vrijwel niemand kiest er echter om die reden voor.

Waarom dit een beslissing is, en niet zomaar een standaardinstelling

Wildcard- en SAN-certificaten (Subject Alternative Name) lossen hetzelfde probleem op, het dekken van meerdere hostnamen met één certificaat, maar op tegengestelde manieren. Een wildcard matcht een patroon: *.example.com is geldig voor elke naam op één niveau onder example.com, zonder dat die naam ooit op het certificaat zelf verschijnt. Een SAN-certificaat vermeldt hostnamen daarentegen expliciet; één certificaat kan app.example.com, api.example.com, en admin.example.com dekken door alle drie in het SAN-veld op te nemen. Beide zijn standaard, beide worden uitgegeven door elke publieke CA, en het subject van het certificaat verraadt niet of de aanpak een bewuste keuze was of een toevallig gevolg van de gebruikte tooling.

Het toeval is de gangbare praktijk. Gratis geautomatiseerde uitgifte, zoals vrijwel elke moderne implementatie gebruikt, vraagt doorgaans een certificaat aan voor de exacte hostnaam waarmee een server is geconfigureerd. Start tien subdomeinen op met tien afzonderlijke geautomatiseerde certificaataanvragen, en je krijgt tien SAN-certificaten die elk hun eigen naam loggen, en nooit één enkele wildcard die ze alle tien dekt. In plaats daarvan kiezen voor een wildcard is een extra stap die de meeste teams nooit nemen, omdat het standaardpad al een werkend certificaat oplevert.

De data: wat 660 huidige certificaten daadwerkelijk kiezen

Voor elk van de 660 topdomeinen met enige Certificate Transparency-geschiedenis hebben we het meest recente certificaat genomen dat al in onze lokale cache zat (nul nieuwe verzoeken aan crt.sh tijdens deze run, waarbij de dataset van drie eerdere onderzoeksartikelen is hergebruikt) en de Subject- en SAN-velden uitgelezen. We hebben elk certificaat geclassificeerd op basis van wat het prijsgeeft buiten het saaie, universele paar van het hoofddomein en het bijbehorende www.-adres: een wildcard-vermelding zonder iets anders, een wildcard plus benoemde hostnamen, benoemde hostnamen zonder enige wildcard, of geen van beide.

Oranje balken geven ergens op het certificaat een specifieke hostnaam prijs; groenblauwe balken niet. Alleen het deel van 22.9% dat uitsluitend wildcards gebruikt en het deel van 2.3% dat alleen het apex-domein bevat, samen 25.2% van de steekproef, houden hun subdomeinnamen buiten het openbare register. De overige drie op de vier domeinen geven op dit moment ten minste één echte subdomeinnaam weg aan iedereen die Certificate Transparency raadpleegt.

Het blijft zelden bij één naam

Zodra een certificaat iets prijsgeeft, blijft het meestal niet bij een enkele verdwaalde hostnaam. Van de 494 certificaten die ten minste één specifiek subdomein noemden, bevat het typische geval slechts één of twee namen, maar de verdeling kent een lange staart: het drukste afzonderlijke certificaat in de steekproef somt 70 verschillende subdomeinen op, en 20 certificaten (4.0% van alle openbarende certificaten) vermelden er tien of meer, waarbij 9 daarvan er 25 of meer vermelden. Een certificaat van die omvang verbergt niets; het lijkt eerder op een openbare sitemap van de infrastructuur van een organisatie, uitgegeven in één aanvraag en gelogd in één record.

Die laatste rij verdient wat extra aandacht. Eén certificaat in de categorie "mixed" bevat 94 verschillende wildcard-vermeldingen op één enkele sleutel, naast benoemde SAN's. Dat is vrijwel zeker een platform of SaaS-provider die dekking via wildcards regelt voor vele klant- of regionale subdomeinen tegelijk. Operationeel is dat efficiënt. Het betekent echter ook dat één privésleutel, mocht deze ooit worden gestolen, tegelijkertijd geldig is voor elk subdomein onder alle 94 patronen, nu en in de toekomst. Wildcards ruilen de geheimhouding van subdomeinen in voor een ander risico: hoe groot de blast radius achter één sleutel is.

Waarom niet iedereen gewoon een wildcard gebruikt

Als een wildcard meer verbergt, waarom gebruikt dan slechts 22.9% van de steekproef er uitsluitend een? Een paar praktische redenen, die op zichzelf geen van alle een fout zijn:

• Automatisering kiest standaard voor benoemen, niet voor wildcards. Tools zoals Certbot vragen een certificaat aan voor de hostnaam waarop een server al reageert. In plaats daarvan een wildcard verkrijgen vereist het aantonen van domeinbeheer via een DNS-01-challenge, een extra stap met extra tooling die de meeste implementaties overslaan.
• Een wildcard dekt slechts één niveau. *.example.com matcht app.example.com maar niet a.app.example.com. Elke werkelijke hiërarchie op een tweede niveau vereist een tweede wildcard of benoemde vermeldingen, wat organisaties weer terugtrekt naar enumeratie, zelfs wanneer ze al een wildcard bezitten.
• De blast radius bij sleutelcompromittering is reëel. Eén gecompromitteerde wildcard-privésleutel kan zich direct voordoen als elk subdomein dat erdoor wordt gedekt. Een gecompromitteerde sleutel per host dekte daarentegen alleen die specifieke host. Teams die gevoelige subdomeinen met gescheiden beheer draaien, kiezen soms bewust voor certificaten met specifieke namen om die blast radius klein te houden, ook al kost dat de geheimhouding van hun subdomeinen.
• Sommige audits vereisen expliciete dekking. Sommige compliance- en inventarisatieprocessen zijn eenvoudiger uit te voeren op basis van een certificaat dat elke gedekte hostnaam bij naam noemt, dan een certificaat dat dekking claimt via een patroon.

Hoe je je eigen domein controleert

Dit kost minder dan een minuut en vereist niets meer dan een browser, omdat je hetzelfde openbare register raadpleegt als wij.

• Doorzoek crt.sh voor je huidige certificaat. Open https://crt.sh/?q=yourdomain.com&output=json en bekijk het veld name_value van de meest recente vermelding, of controleer het certificaat van je server rechtstreeks met openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Tel wat het daadwerkelijk prijsgeeft. Een enkele vermelding met *.yourdomain.com en niets anders is uitsluitend een wildcard. Al het andere, elke benoemde host buiten het hoofddomein en www., is al openbaar via CT, ongeacht of je elders ook een wildcard hebt.
• Maak een bewuste afweging. Als de geheimhouding van subdomeinen voor jouw architectuur zwaarder weegt dan de blast radius bij sleutelcompromittering, stap dan over op een wildcard en een DNS-01-uitgifteproces. Is dat niet het geval, beschouw dan ten minste elke benoemde SAN als permanent openbaar en vertrouw niet langer op een onbekend subdomein als een vorm van beveiliging.

Wat dit niet bewijst

Eerlijke beperkingen, want een getal zonder kanttekeningen is marketing.

• We hebben het meest recente certificaat per domein bekeken, niet de volledige geschiedenis. Een domein kan jarenlang een wildcard hebben gebruikt en pas onlangs een benoemde SAN hebben toegevoegd, of omgekeerd. Dit is een momentopname van wat er momenteel wordt prijsgegeven, geen historisch patroon.
• Een benoemde SAN is geen bewijs dat de service erachter actief of bereikbaar is. We hebben hostnaamtekst op een certificaat geclassificeerd, niets meer. Sommige benoemde subdomeinen wijzen mogelijk naar infrastructuur die niet meer bestaat.
• Het is een steekproef van 660 domeinen van grote, gevestigde sites. De top-sites-ranglijst van Tranco helt over naar organisaties met genoeg infrastructuur om überhaupt meer dan één hostnaam nodig te hebben. Een andere populatie zou de exacte verdeling verschuiven.
• Dit meet openbaarmaking, niet exploiteerbaarheid. Het kennen van de naam van een subdomein is verkenning (reconnaissance). Wat een aanvaller met die naam doet, hangt volledig af van wat er daadwerkelijk achter draait.

Veelgestelde vragen

Verbergt een wildcardcertificaat subdomeinen?

Gedeeltelijk. Een wildcard voor *.example.com logt alleen de wildcard-string, geen specifieke labels. Maar in onze steekproef noemt 63.8% van de huidige certificaten desondanks een echt subdomein, en vertrouwt slechts 22.9% puur op een wildcard zonder dat er een benoemde host wordt blootgesteld.

Kunnen subdomeinen die onder een wildcard vallen alsnog verschijnen in Certificate Transparency-logs?

De wildcard-vermelding zelf verschijnt alleen als het patroon, niet als een specifieke naam. Maar op het moment dat een afzonderlijk certificaat een host expliciet noemt, wordt die naam volledig gelogd, zelfs naast een bestaande wildcard. 11.1% van de certificaten hier doet beide.

Wat is het verschil tussen een wildcard- en een SAN-certificaat?

Een wildcard dekt een patroon, *.example.com, zonder enig subdomein te noemen. Een SAN-certificaat vermeldt specifieke hostnamen expliciet. Geautomatiseerde uitgifte kiest standaard voor SAN-certificaten voor de exacte hostnaam waarop een server draait, waardoor enumeratie, en niet het gebruik van wildcards, de gangbare praktijk is.

Is een wildcardcertificaat veiliger dan het expliciet vermelden van elk subdomein?

Voor de geheimhouding van subdomeinnamen wel. Voor de blast radius bij sleutelcompromittering niet noodzakelijk: één gestolen wildcard-sleutel is direct geldig voor elk subdomein dat eronder valt, terwijl een gecompromitteerde sleutel per host alleen die host dekt.

Wat gebeurt er als de privésleutel van een wildcardcertificaat gecompromitteerd raakt?

Een aanvaller kan zich voordoen als elk subdomein onder dat patroon totdat het certificaat wordt ingetrokken en overal waar het was geïmplementeerd opnieuw wordt uitgegeven. Eén certificaat in onze steekproef bevat 94 verschillende wildcard-vermeldingen op één enkele sleutel, een enorme blast radius mocht die sleutel ooit uitlekken.

Dekt een wildcard ook subdomeinen van subdomeinen?

Nee. *.example.com matcht a.example.com, maar niet a.b.example.com. Een naam op een tweede niveau vereist een eigen wildcard of een expliciete SAN-vermelding, wat een van de redenen is waarom organisaties hostnamen enumereren, zelfs als ze al een wildcard hebben.

Hoe gebruiken aanvallers Certificate Transparency-logs om subdomeinen te enumereren uit SAN-lijsten?

Elk certificaat dat een publieke CA uitgeeft, wordt gelogd onder RFC 6962 en is gratis doorzoekbaar via crt.sh. Een certificaat dat hostnamen bij naam opsomt, overhandigt een aanvaller een kant-en-klare kaart van subdomeinen, zonder dat er scans nodig zijn.

Moet je kiezen voor een wildcard of SAN vanwege beveiliging, en niet alleen voor het gemak?

Als de geheimhouding van subdomeinnamen belangrijk is, is een wildcard het betere uitgangspunt, en de meeste organisaties in deze steekproef maken die keuze niet. Als je enumereert, behandel dan elke benoemde SAN als permanent openbaar en weeg het risico van sleutelcompromittering af voordat je overstapt.

Gerelateerde artikelen

• Hoe Certificate Transparency-logs interne subdomeinen lekken Zelfde cache, de inhoudelijke vraag: welke categorieën interne hostnamen duiken daadwerkelijk op zodra een certificaat er een prijsgeeft.
• Hoe lang duurt het voordat een certificaat in CT verschijnt? Zelfde crt.sh-invalshoek, de timingvraag in plaats van de vraag over openbaarmaking.
• Is de regel voor 200-dagen-certificaten al van kracht geworden? Een derde invalshoek op dezelfde cache van 660 domeinen: hoe lang certificaten mogen leven, niet wat ze prijsgeven.