2026-07-21 · ONDERZOEK · Het Offensive Technology-team

Hoeveel topdomeinen beperken wie hun certificaten kan uitgeven?

Kort antwoord: We namen de 1,000 drukste domeinen op het internet, resolveerden er 994 en lazen het CAA-record dat elk domein in DNS publiceert. Slechts 32.4% publiceert überhaupt een CAA-record. De overige 67.6% stelt op DNS-niveau geen enkele beperking aan welke certificaatautoriteit een TLS-certificaat voor hun naam mag uitgeven, dus elk van de tientallen publiek vertrouwde CA's zou, in principe, misleid of gecompromitteerd kunnen worden om een geldig certificaat voor hen uit te geven, en niets wat het domein publiceerde zou nee hebben gezegd. Onder de minderheid die wel CAA instelt, vraagt minder dan de helft (42.5%) om op de hoogte te worden gesteld wanneer een CA een verzoek ziet dat hun beleid schendt, wat precies die ene regel is die CAA verandert van een stil hekwerk in een alarm. Elk getal hier is afkomstig van passieve publieke DNS-lookups die we zelf hebben uitgevoerd tegen een gepubliceerde topsites-lijst. Er is met geen enkele host contact opgenomen en er is niets gescand. Hier is exact hoe we dit hebben gemeten, en wat het wel en niet bewijst.

De bevinding in één grafiek

Voor elk domein stelden we drie publieke vragen. Publiceert het een CAA-record? Zo ja, vermeldt het een rapportagecontact (iodef) zodat een CA kan waarschuwen bij overtredingen? En beheert het de uitgifte van wildcards afzonderlijk van gewone uitgifte? Elke laag is kleiner dan de vorige:

Wat een CAA-record daadwerkelijk doet

Elke browser vertrouwt tientallen certificaatautoriteiten, en standaard kan elk daarvan een geldig TLS-certificaat uitgeven voor elk willekeurig domein. Dat is handig, maar het is ook het zwakke punt: als één enkele CA wordt misleid via een gebrekkige domeinvalidatiecontrole, onder druk wordt gezet of wordt gecompromitteerd, kan deze een certificaat aanmaken voor een naam die geen klant is, en een browser zal dit accepteren. Onterechte certificaatuitgifte is niet hypothetisch; het is de reden waarom de sector in de eerste plaats gelaagde verdedigingen rondom uitgifte heeft gebouwd.

CAA (RFC 8659, die het eerdere RFC 6844 verving) is de helft van die verdediging op DNS-niveau. Een domein publiceert een kort record dat in feite zegt: "alleen deze CA's mogen voor mij uitgeven." Sinds een CA/Browser Forum stemming van kracht werd op 8 september 2017, is elke publiek vertrouwde CA verplicht om dat record te lezen op het moment van uitgifte en te weigeren een certificaat uit te geven dat niet door het record is geautoriseerd. Het is een zeldzame maatregel die zowel gratis is in te stellen als actief wordt gehandhaafd door de andere partij.

Een CAA-recordset heeft een paar bewegende delen:

• issue noemt een CA die gewone certificaten mag uitgeven, bijvoorbeeld 0 issue "letsencrypt.org". Een issue ";" met een puntkomma betekent dat geen enkele CA überhaupt mag uitgeven.
• issuewild regelt wildcard-certificaten (*.example.com) afzonderlijk, wat van belang is omdat één enkele wildcard een grotere blast radius heeft dan één hostnaam.
• iodef geeft een URL of mailbox waar een CA een verzoek kan melden dat het beleid schendt. Het is het verschil tussen het stilzwijgend blokkeren van een kwaadaardig verzoek en erachter komen dat er een poging is gedaan.

Twee derde van de drukste domeinen stelt niets in

Het opvallendste getal is de afwezigheid. Van de 994 domeinen die geresolveerd werden, publiceren er 672 (67.6%) geen CAA-record. Voor die domeinen zegt de DNS niets over wie hun certificaten mag uitgeven, dus het antwoord is: iedereen in de public trust store. Dat is geen inbreuk en op zichzelf geen kwetsbaarheid. Het is een gemiste kans om het aanvalsoppervlak voor een categorie aanvallen te verkleinen met een record dat één regel en geen geld kost.

Onder de 322 domeinen die wel CAA publiceren, leunt het merendeel niet op één enkele provider: twee derde (66.5%) autoriseert meer dan één certificaatautoriteit, met een mediaan van drie. Dat is normaal en verstandig voor een organisatie die verschillende CA's gebruikt voor verschillende systemen, hier een interne PKI-provider, daar een publieke CA voor de marketingsite. Wat opvalt is de rapportagekloof. Slechts 42.5% van de publicerders stelt een iodef-contact in, dus de meerderheid heeft wel een hek gebouwd maar geen alarm: een CA die een verzoek ontvangt dat hun beleid schendt zal dit weigeren, maar de domeineigenaar hoort nooit dat iemand het geprobeerd heeft. Dit sluit rechtstreeks aan bij hetzelfde thema als ons onderzoek naar blootstelling via e-mailauthenticatie bij deze domeinen, waar het patroon hetzelfde was: het basisrecord wordt vaker ingesteld dan de instelling die daadwerkelijk een alarm zou doen afgaan.

Hoe we dit hebben gemeten

Een scepticus moet dit vanaf nul kunnen herbouwen, dus hier is de volledige methode zonder iets te verbergen.

• De populatie. We gebruikten de Tranco-lijst (lijst N29KW, gegenereerd op 20 juli 2026), een onderzoeksgerichte topsites-ranking die het gemiddelde van meerdere providers over 30 dagen neemt om bestand te zijn tegen dagelijkse manipulatie. Het is gepubliceerd, voorzien van versies en permanent citeerbaar, wat belangrijker is voor de reproduceerbaarheid dan de lijst van welke individuele leverancier dan ook. Zie tranco-list.eu en het onderliggende NDSS 2019-paper.
• De steekproef. De top 1,000 domeinen van die lijst. 994 geresolveerd naar actieve nameservers; 6 deden dat niet en werden weggelaten, dus de noemer is 994.
• De lookups. Voor elk domein een dig CAA <domain> query tegen publieke recursieve resolvers, plus een NS query als liveness gate. We hebben het antwoord geparsed op issue-, issuewild- en iodef-tags en deze uitgelezen op de apex van het domein, wat de gebruikelijke adoptiemetriek is en het record dat een CA raadpleegt voor het geregistreerde domein.
• Wat we niet hebben gedaan. We hebben nooit een certificaat aangevraagd, verbinding gemaakt met een webserver of iets gescand. Het lezen van een openbaar DNS-record is een lookup, geen scan. Dit is dezelfde grens tussen een controle en een delict die geldt voor elk traject dat we uitvoeren.
• Wat we hebben bewaard. Alleen geaggregeerde aantallen en percentages. Resultaten per domein verbleven in het geheugen voor de duur van de uitvoering en werden nooit naar schijf geschreven. Er wordt geen enkel domein bij naam genoemd. We hebben alleen vastgelegd of een iodef-tag aanwezig was, nooit de contactwaarde ervan, en we hebben geen persoonsgegevens verzameld; domeinen en hun DNS-records zijn geen persoonsgegevens.

Een neutrale blik op wie er geautoriseerd wordt

Eén geaggregeerd gegeven is het tonen waard omdat het de certificaatautoriteiten beschrijft, niet de sites die we hebben gemeten, en geen enkel domein noemt. Over de 322 domeinen die CAA publiceren kwamen deze uitgevers het vaakst voor op de geautoriseerde lijsten. Lees het als een populariteitskaart van vertrouwde CA's, niet als een scorebord van de beveiliging van wie dan ook:

Wat dit niet bewijst

Eerlijke beperkingen, want een getal zonder kanttekeningen is marketing.

• Het is een momentopname. DNS verandert dagelijks. Deze cijfers beschrijven 20 juli 2026, niet een trend. Een domein dat vandaag geen CAA heeft, kan er volgende week een toevoegen.
• Een ontbrekende CAA is geen kwetsbaarheid. Het is een maatregel die niet is ingeschakeld. Genoeg goed beheerde organisaties slaan CAA over en vertrouwen op andere lagen. We meten de adoptie van een hardening-stap, we tellen geen lekken.
• CAA is geen muur. Het bindt alleen CA's die het respecteren, intrekking van reeds uitgegeven certificaten vindt niet plaats en het doet niets wanneer een door u wel geautoriseerde CA gecompromitteerd raakt. Het verkleint de verzameling uitgevers die kunnen handelen, en iodef meldt pogingen. Het achteraf opsporen van onverwachte uitgifte is de taak van Certificate Transparency monitoring, wat natuurlijk samengaat met CAA.
• Alleen apex. We lazen het CAA-record op de apex van elk geregistreerd domein. Omdat CAA wordt geëvalueerd door de DNS-tree te beklimmen, kan een subdomein dit overerven of overschrijven; we hebben subdomeinen niet geïnumereerd, en dat zouden we ook niet doen, omdat dat meer begint te lijken op het in kaart brengen van iemands terrein dan op het lezen van één enkel openbaar record.
• De top van de lijst is gemengd. De drukste domeinen omvatten CDN's en infrastructuur waarvan de certificaatpraktijken verschillen van die van een typisch bedrijf. De populatie bestaat uit "de namen met het meeste verkeer", niet "bedrijven zoals het uwe", dus beschouw de percentages als een landschap, niet als een benchmark voor uw eigen risico.

Waarom een aanvaller hierom geeft, en waarom u dat zou moeten doen

Een vervalst maar geldig certificaat is een machtig middel. Het stelt een aanvaller die zich al in een positie bevindt om verkeer te onderscheppen (via een overgenomen netwerkpad of een gecompromitteerde resolver) in staat om uw domein te presenteren met een slotje dat de browser vertrouwt, zonder enige waarschuwing voor de bezoeker. Onterechte uitgifte is zeldzaam, juist omdat CA's worden geauditeerd en CAA wordt gehandhaafd, maar "zeldzaam" doet veel werk wanneer de kosten voor het verhogen van de lat slechts één DNS-record bedragen. Het publiceren van CAA verwijdert elke CA die u niet gebruikt uit de vergelijking, en het toevoegen van een iodef-contact betekent dat als iemand wel probeert een certificaat te verkrijgen via een CA die u nooit heeft geautoriseerd, u erover hoort in plaats van er via een klant achter te komen.

De oplossing is niet spectaculair en grotendeels gratis: vermeld de CA's die u daadwerkelijk gebruikt, voeg een issuewild-regel toe als u wildcard-certificaten gebruikt, en stel een iodef-mailbox in die u leest. Het lastige gedeelte is nooit de DNS-aanpassing. Het is het kennen van elke plek waar uw organisatie legitiem certificaten vandaan haalt, zodat het inschakelen van CAA niet stilzwijgend een verlenging breekt die u vergeten was. Dat vergt inzicht, en het is hetzelfde inzicht dat nodig is om te weten welke van uw blootgestelde oppervlakken er daadwerkelijk toe doen en welke ruis zijn.

Certificaatautorisatie: snelle antwoorden

Wat is een CAA-record?

CAA (Certification Authority Authorization, RFC 8659) is een DNS-record waarin staat welke certificaatautoriteiten TLS-certificaten voor een domein mogen uitgeven. Sinds september 2017 eist het CA/Browser Forum dat publiek vertrouwde CA's dit record controleren en uitgifte weigeren die niet door het record is geautoriseerd. Geen CAA-record betekent geen beperking: elke publieke CA mag uitgeven.

Welk aandeel van de topdomeinen publiceert een CAA-record?

In onze controle van juli 2026 onder de 1,000 drukste domeinen (994 geresolveerd), publiceerde slechts 32.4% een CAA-record; 67.6% publiceert er geen. Onder publicerders stelt 42.5% ook een iodef-rapportagecontact in en beheert 36% de uitgifte van wildcards afzonderlijk.

Stopt een CAA-record alle onterechte certificaatuitgifte?

Nee. Het is defense-in-depth: het bindt alleen CA's die het respecteren, trekt reeds uitgegeven certificaten niet in en voorkomt niet dat een geautoriseerde CA gecompromitteerd raakt. Het beperkt wie kan uitgeven en meldt, met iodef, pogingen daartoe. Combineer het met Certificate Transparency-monitoring.

Hoe controleer en stel ik mijn eigen CAA-record in?

Lees het uit met dig CAA yourdomain.com. Om er een in te stellen, autoriseert u alleen de CA's die u gebruikt (bijvoorbeeld 0 issue "letsencrypt.org"), voegt u een issuewild-regel toe als u wildcards gebruikt, en voegt u 0 iodef "mailto:[email protected]" toe zodat een CA overtredingen kan melden. Het controleren van uw eigen record is een passieve lookup, dus het is veilig en gratis.

Gerelateerde artikelen

• Hoe kwetsbaar zijn de topdomeinen voor e-mailspoofing?
• Wat kunnen aanvallers daadwerkelijk zien over uw bedrijf?
• Waarom autorisatie voorafgaat aan elke test