Defaults.Exposed › Oplossingen › CAA-records

Hoe je CAA-records oplost

Een CAA-record is een korte instructie in uw domeininstellingen die benoemt welke certificaatbedrijven het „hangslot”-beveiligingscertificaat voor uw website mogen uitgeven. Met deze instructie aan kan geen enkel ander bedrijf stilletjes een geldig certificaat op uw naam aanmaken.

De kern voor je bedrijf: Zonder een CAA-record kan bijna elk van de honderden certificaatbedrijven wereldwijd een echt, volledig vertrouwd hangslotcertificaat voor uw domein uitgeven — waarmee een oplichter een vlekkeloze, volledig „beveiligd” ogende kloon van uw site kan optuigen om de inloggegevens en kaartgegevens van uw klanten te oogsten, zonder dat er iets op het scherm waarschuwt.

Wat dit je kan kosten

Een oplichter verkrijgt een echt certificaat voor een kopie van uw site, zodat die het groene hangslot en HTTPS toont — uw klanten zien niets mis, tikken hun wachtwoorden en kaartnummers in, en u hoort er pas van wanneer de terugboekingen en boze telefoontjes beginnen.
Uw klanten worden gephisht via een pixel-perfecte look-alike van uw inlogpagina; de nasleep — terugbetalingen, supportlast, reputatieschade — landt op uw merk ook al werd uw echte site nooit aangeraakt.
Het security- of inkoopteam van een prospect doet vóór ondertekening een snelle controle van uw domein, ziet geen CAA-bescherming, en zet u stilletjes lager als „zwak op de basis” — waarmee een deal in gevaar komt over een instelling die vijf minuten kost om toe te voegen.
Een van 's werelds certificaatbedrijven raakt gecompromitteerd (dit is herhaaldelijk gebeurd — DigiNotar, Comodo, Symantec), en omdat u nooit zei wie namens u mocht handelen, is uw domein blootgesteld aan welke ook de zwakste schakel blijkt te zijn.

Waarom het ertoe doet. Op dit moment staat de deur wijd open: elk certificaatbedrijf ter wereld kan instaan voor een site die beweert de uwe te zijn, of u ooit met ze te maken had of niet. Een CAA-record vergrendelt die deur zodat alleen de provider die u koos certificaten kan uitgeven — het is de eenvoudigste, goedkoopste verdediging die er is tegen iemand die uw bedrijf online nabootst.

CAA-records, in gewone woorden

Elke beveiligde website heeft een certificaat — het ding achter het hangslot in de browser en de „https” aan het begin van uw adres. Die certificaten worden uitgereikt door gespecialiseerde firma’s, certificaatautoriteiten (CA’s) genaamd: namen als Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Wanneer uw browser een geldig certificaat ziet, toont hij het hangslot en vertelt hij uw klant dat de verbinding echt en beveiligd is.

Dit is het deel dat de meeste ondernemers nooit is verteld: standaard mogen honderden van deze certificaatautoriteiten wereldwijd elk een certificaat voor uw domein uitgeven — of u ooit van ze gehoord heeft of niet. Een CAA-record (Certification Authority Authorization) is een notitie van één regel die u toevoegt aan de DNS-instellingen van uw domein en die in feite zegt: „alleen deze providers mogen certificaten voor mij uitgeven.” Elke legitieme certificaatautoriteit is volgens de regels van de sector verplicht die notitie te controleren vóór uitgifte — en te weigeren als ze niet op uw lijst staat.

Het is het verschil tussen een onvergrendelde voordeur waar iedereen doorheen kan, en een waar alleen de mensen die u koos een sleutel van hebben. En toevoegen kost niets.

Wat dit u kan kosten

Het risico dat een CAA-record afsluit is overtuigende nabootsing. Wanneer een oplichter een echt certificaat voor een kopie van uw site kan krijgen, verdwijnen de gebruikelijke waarschuwingssignalen — er is geen kapot hangslot, geen „niet veilig”-banner, geen certificaatfout. Alles ziet er goed uit, en precies dat maakt het gevaarlijk.

De vlekkeloze nep. Een oplichter registreert een look-alike-adres (of compromitteert een route naar uw klanten), krijgt een echt certificaat, en tuigt een perfecte kloon van uw inlog- of afrekenpagina op — hangslot en al. Klanten voeren wachtwoorden en kaartnummers in zoals gewoonlijk. Het eerste wat u hoort is een golf van terugboekingen, fraudemeldingen en boze telefoontjes.
De phishingcampagne op uw naam. Aanvallers sturen „bevestig uw account”-e-mails die linken naar hun gecertificeerde kloon van uw site. Omdat de pagina volledig beveiligd oogt, trappen meer mensen erin. De opruiming — klanten informeren, terugbetalingen, supporturen, de ongemakkelijke publieke uitleg — landt allemaal op u, ook al werden uw echte servers nooit aangeraakt.
De deal die vastloopt op een checklist. Het security- of inkoopteam van een grotere klant scant uw domein vóór ondertekening. „Geen CAA-record” verschijnt als een rood of oranje item naast uw naam. Technisch is het een klein ding, maar het leest als „dekt de basis niet”, en het kan een contract vertragen of laten kelderen dat u anders gewonnen had.
Betrapt door andermans inbreuk. Een certificaatautoriteit met wie u nooit te maken had raakt gecompromitteerd — dit is niet hypothetisch; DigiNotar, Comodo en Symantec hebben allemaal ernstige incidenten gehad. Omdat u nooit beperkte wie namens u mocht handelen, kan de aanvaller via die zwakke CA een geldig certificaat voor uw domein krijgen. Een CAA-record zou hen geweigerd hebben.
De wildcard-blinde vlek. Zelfs bedrijven die voorzichtig zijn met hun hoofdsite vergeten vaak subdomeinen. Zonder een issuewild-regel krijgt een aanvaller die een wildcardcertificaat kan bemachtigen in feite een sleutel tot elk subdomein dat u ooit zult hebben, in één keer.

Geen van deze vereist een geraffineerde aanval op uw servers. Ze buiten het feit uit dat het bredere certificaatsysteem, zonder CAA-record, simpelweg te goedgelovig namens u is.

Wat het feitelijk is, en hoe „goed” eruitziet

Een CAA-record leeft in de DNS van uw domein — dezelfde instellingen die uw domein naar uw website en e-mail wijzen. Elk record heeft drie delen: een vlag, een tag en een waarde. De tags die ertoe doen zijn:

issue — benoemt een certificaatautoriteit die normale certificaten voor uw domein mag uitgeven. U kunt er meerdere hebben, één per provider die u legitiem gebruikt.
issuewild — bestuurt wildcardcertificaten (één certificaat dat elk subdomein dekt, bijv. *.example.com). Gebruikt u geen wildcards, dan blokkeert de aanbevolen instelling ze volledig.
iodef — een optioneel contactadres waar u bericht krijgt als een certificaatautoriteit een aanvraag afwijst vanwege uw CAA-policy. Dit is uw vroege waarschuwing dat iemand het probeerde.

Hoe „goed” eruitziet: ten minste één issue- (of issuewild-)record is aanwezig, dat de provider(s) benoemt die u werkelijk gebruikt, met wildcards ofwel beperkt tot een genoemde provider ofwel geblokkeerd. Dat is de lat die deze check meet — hij zoekt de CAA-records van uw domein op via verschillende onafhankelijke resolvers en slaagt wanneer hij een echte issue- of issuewild-policy aantreft. Een domein met geen CAA-records wordt behandeld als de open deur die het is.

Beïnvloedt dit mijn cijfer? Ja. Een ontbrekend CAA-record is een gescoord item en wordt gemarkeerd op middelhoge ernst — het is een echt gat, niet zomaar een nice-to-have, omdat het een reële nabootsingsroute openlaat. Het record toevoegen dicht het gat en wist de bevinding.

Hoe los je het op (gratis, ~5 minuten)

Geef dit onderdeel aan wie uw domein of website beheert — de oplossing is gratis. Het is een kleine DNS-wijziging, geen herbouw. We rekenen alleen iets als u later wilt dat we blijven kijken of het record op zijn plek blijft; toevoegen kost niets.

Stap 1 — Zoek uit welke certificaatautoriteit u werkelijk gebruikt. Dit is de ene stap die de moeite waard is goed te doen, want de verkeerde provider vermelden kan uw volgende verlenging blokkeren. Gangbare gevallen:

Let’s Encrypt — gebruikt door veel hosts en configuratieschermen (cPanel, Plesk) → letsencrypt.org
Cloudflare (als het uw edge-certificaat uitgeeft) → letsencrypt.org, digicert.com, comodoca.com, pki.goog en ssl.com (Cloudflare gebruikt meerdere back-end-CA’s; vermeld degene die zijn dashboard toont, of de volledige set, zodat verlengingen nooit breken)
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com (en comodoca.com)
Microsoft 365 / Azure — Microsoft gebruikt doorgaans DigiCert voor beheerde certificaten → digicert.com (bevestig in uw portaal)

Twijfelt u, bekijk dan uw huidige certificaat in de browser (klik op het hangslot → certificaatdetails → „Uitgegeven door”) om te zien wie het uitgaf.

Stap 2 — Log in bij uw DNS-provider. Dit is waar de records van uw domein leven — meestal uw registrar, uw webhost of Cloudflare. Vind het DNS-recordsgedeelte en kies een nieuw record van type CAA toe te voegen (sommige interfaces labelen het als type 257).

Stap 3 — Voeg een issue-record toe voor elke provider die u gebruikt. Voor Let’s Encrypt bijvoorbeeld:

example.com.   CAA   0 issue "letsencrypt.org"

Voeg één issue-regel toe per legitieme provider. De meeste DNS-dashboards geven u aparte velden voor de vlag (0), tag (issue) en waarde (het domein van de CA), zodat u de hele regel niet met de hand hoeft te typen.

Stap 4 — Bestuur wildcardcertificaten. Gebruikt u geen wildcards, blokkeer ze dan ronduit zodat niemand er stilletjes een kan krijgen:

example.com.   CAA   0 issuewild ";"

Gebruikt u wel wildcards, benoem dan de provider: 0 issuewild "letsencrypt.org".

Stap 5 — (Aanbevolen) Voeg een meldingsadres toe. Zodat u bericht krijgt wanneer een CA een poging afwijst — uw vroege waarschuwing dat iemand het probeerde:

example.com.   CAA   0 iodef "mailto:[email protected]"

Stap 6 — Opslaan en verifiëren. Draai dig CAA example.com (of gebruik een online DNS-opzoektool) en bevestig dat uw records verschijnen. Wijzigingen kunnen van een paar minuten tot een paar uur duren om zich over internet te verspreiden. Uw bestaande certificaat en alle verlengingen blijven al die tijd werken — CAA bestuurt alleen nieuwe uitgifte.

Snelle platformnotities: Op Cloudflare, DNS → Records → Add record → type CAA. Op Google Workspace beheert u DNS bij uw registrar (of Cloud DNS als u dat gebruikt) — voeg de CAA-records daar toe met pki.goog. Op Microsoft 365 wordt CAA niet ingesteld in het M365-beheercentrum; voeg het toe waar de DNS van uw domein is gehost, met vermelding van uw beheerde-certificaat-CA (vaak DigiCert). Op gangbare hosts (GoDaddy, Namecheap, en dergelijke) zit het in hetzelfde DNS-paneel waar uw A- en MX-records leven.

Veelgemaakte fouten

De verkeerde CA vermelden — of er een vergeten. Het grootste praktijkrisico is geen security, maar uw eigen verlengingen blokkeren. Gebruikt u meer dan één uitgever (bijv. een voor de hoofdsite en een andere achter Cloudflare), vermeld ze dan allemaal. Bij twijfel: vermeld er een paar die u vertrouwt liever dan te weinig.
issue instellen maar wildcards negeren. Een domein dat normale certificaten beperkt maar niets over wildcards zegt, laat de krachtigere wildcardroute toch open. Stel altijd ook issuewild in — ofwel naar uw provider ofwel op ";" om hem te blokkeren.
CAA op de verkeerde naam zetten. CAA wordt door de certificaatautoriteit gelezen voor de exacte naam die wordt gecertificeerd, omhoog door de boom lopend. Het instellen aan de top van uw domein (de „apex”, bijv. example.com) is de juiste zet — het dekt subdomeinen standaard tenzij een subdomein zijn eigen instelt.
Aannemen dat uw platform het al deed. Cloudflare, Google en Microsoft beheren certificaten maar voegen geen CAA-records voor u toe. Tenzij u ze toevoegde, staat uw domein nog open.
Het als eenmalig behandelen zonder monitoring. Een latere DNS-migratie, een registrarwissel, of een „opruiming” van records kan uw CAA-bescherming stilletjes laten vallen. Het is de moeite waard te controleren of het er nog staat na elke DNS-wijziging.

De technische laag (geef dit aan uw IT’er)

CAA is gedefinieerd in RFC 8659 en afgedwongen onder de CA/Browser Forum Baseline Requirements — elke publiek-vertrouwde CA is verplicht CAA te controleren op het moment van uitgifte. Records hebben de vorm <flags> <tag> <value>, met tags issue, issuewild en iodef. Een niet-lege issue- of issuewild-policy is wat aan deze check voldoet; de aanwezigheid van iodef alleen niet (dat is rapportage, geen autorisatie).

Een solide basis op de apex:

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

Notities voor de implementeerder:

CAA-tree-climbing: CA’s evalueren CAA vanaf de aangevraagde FQDN omhoog tot de apex, en stoppen bij de eerste naam met een CAA-record. Een record op de apex beschermt daarom alle subdomeinen tenzij een subdomein zijn eigen publiceert, wat kan — handig als een specifiek subdomein een andere uitgever gebruikt.
De ;-waarde in issuewild betekent „geen CA mag wildcards uitgeven” — een expliciete weigering. Gebruik haar wanneer wildcards geen deel van uw opzet zijn.
De 0-vlag is de issuer-critical-vlag; 0 (niet-kritiek) is correct voor normaal gebruik. Vermijd het zetten van de critical-bit tenzij u die volledig begrijpt, want een verkeerd begrepen critical-tag kan conforme CA’s doen weigeren uit te geven.
Meerdere uitgevers: meerdere issue-records zijn toegestaan en additief — vermeld elke CA die legitiem in uw stack zit (inclusief de back-end-CA’s die uw CDN/edge-provider gebruikt) om verlengingsfouten te voorkomen.
Verificatie: dig CAA example.com +short, of controleer via de CAA-testtools van het CA/Browser Forum. Deze check zelf bevraagt CAA over verschillende onafhankelijke resolvers (lokale DNS, dan Google, Cloudflare en Quad9 DNS-over-HTTPS als terugval) en aanvaardt het eerste autoritatieve antwoord, zodat een enkele resolverstoring geen vals „geen CAA”-resultaat oplevert.
DNSSEC-koppeling: CAA vertelt CA’s wie mag uitgeven; DNSSEC belet dat het CAA-antwoord zelf onderweg wordt vervalst. Ze vullen elkaar aan — voor hoogwaardige domeinen draait u beide.

Stel het in bij je host

Stap voor stap voor populaire providers:

Veelgestelde vragen

Ik ben niet technisch — kan ik dit zelf afhandelen?

U hoeft het detail niet te begrijpen, maar de oplossing is een kleine wijziging in de DNS-instellingen van uw domein, dus die kunt u het beste overlaten aan wie uw website of domein beheert. Stuur ze het onderdeel „Hoe los je het op” hieronder — het is een wijziging van vijf minuten, kosteloos. We rekenen alleen iets als u later wilt dat we blijven kijken of het record op zijn plek blijft; de oplossing zelf is altijd gratis.

Breekt dit toevoegen mijn website of mijn certificaat?

Nee — zolang u de certificaatprovider opgeeft die u werkelijk gebruikt, blijft alles precies als voorheen werken. Een CAA-record raakt of vervangt uw bestaande certificaat niet; het bepaalt enkel wie nieuwe mag aanmaken. De enige manier om problemen te veroorzaken is uw echte provider van de lijst weglaten, wat uw volgende automatische verlenging kan blokkeren — de stappen hieronder zijn specifiek geschreven om dat te vermijden.

Als certificaten tegenwoordig automatisch worden uitgegeven, waarom heb ik dit dan nog nodig?

Automatische certificaten zijn prima en handig — het probleem is dat het systeem standaard voor iedereen openstaat, ook voor iemand die zich als u voordoet. Een CAA-record benoemt simpelweg wie het mag, en verandert een open deur in een met uw eigen slot erop. Het werkt naast automatische uitgifte, niet ertegen.

Beïnvloedt dit mijn Google-ranking of mijn cijfer in dit rapport?

Het beïnvloedt uw beveiligingscijfer hier — een ontbrekend CAA-record is een gescoord item, gemarkeerd als een gat van middelhoge ernst, omdat het een echte nabootsingsroute openlaat. Het is geen directe Google-rankingfactor, maar de nabootsing en phishing die het voorkomt zijn precies het soort incidenten die vertrouwen en verkeer wél schaden. Hoe dan ook is het een snelle, gratis winst.

Wat is het verschil tussen „issue” en „issuewild”?

Een „issue”-record bepaalt normale certificaten voor uw domein en zijn subdomeinen. Een „issuewild”-record bepaalt wildcardcertificaten — het ene certificaat dat elk mogelijk subdomein tegelijk dekt (zoals *.example.com). Wildcards zijn krachtiger en daarom riskanter in verkeerde handen, dus het is goede praktijk ze apart te besturen: gebruikt u geen wildcards, blokkeer ze dan ronduit.

Wij gebruiken Cloudflare / Google Workspace / Microsoft 365 — dekt dat dit al?

Niet automatisch. Die platforms beheren uw certificaten voor u, maar tenzij u expliciet CAA-records heeft toegevoegd, vertelt uw domein de wereld nog steeds „elke autoriteit mag uitgeven.” Het goede nieuws is dat de oplossing op alle drie dezelfde simpele DNS-wijziging is, en waar Cloudflare of uw host uw certificaat uitgeeft, vermeldt u simpelweg die provider. De platformnotities in het oplossingsdeel hieronder dekken de gangbare gevallen.