CAA-records uitgelegd: bepalen welke certificeringsinstanties namens uw domein een certificaat mogen uitgeven

In de wereld van Public Key Infrastructure (PKI) is vertrouwen van het grootste belang. Organisaties besteden veel tijd en geld aan het beveiligen van hun domeinen met SSL/TLS-certificaten , maar velen staan ​​er niet bij stil wie die certificaten daadwerkelijk mag uitgeven. Die lacune kan tot ernstige problemen leiden. CAA-records zijn een eenvoudige DNS-tool waarmee domeineigenaren duidelijk kunnen bepalen welke certificeringsinstanties certificaten voor hun domein mogen uitgeven.

Als uw beveiligingsprogramma nog geen DNS CAA-records gebruikt, legt deze handleiding uit wat ze zijn, hoe ze werken en waarom elke organisatie ze zou moeten gebruiken.

Kort antwoord: Wat is een CAA-record?

Een CAA-record (Certification Authority Authorization) is een DNS-resource record (RFC 6844, bijgewerkt naar RFC 8659) dat certificeringsinstanties vertelt welke instanties gemachtigd zijn om SSL/TLS-certificaten voor uw domein uit te geven. Sinds september 2017 moeten alle publiekelijk vertrouwde certificeringsinstanties CAA-records controleren voordat ze certificaten uitgeven. Een domein zonder CAA-records staat elke certificeringsinstantie toe om er certificaten voor uit te geven . Drie tags bepalen de uitgifte: issue , issuewild en iodef.

Key Takeaways

• CAA-records zijn een DNS-uitgiftecontrole die is gestandaardiseerd in RFC 6844 (bijgewerkte RFC 8659) en die beperkt welke certificeringsinstanties SSL/TLS-certificaten voor een domein mogen uitgeven. Sinds september 2017 schrijven de CA/Browser Forum Baseline Requirements voor dat alle publiekelijk vertrouwde CA's CAA-records moeten controleren voordat ze een certificaat uitgeven. Een CA die niet in de lijst staat, moet de aanvraag weigeren; een SERVFAIL tijdens de lookup moet ook leiden tot weigering (fail-secure gedrag).
• Een domein zonder CAA-records op welk niveau dan ook in de DNS-hiërarchie, stelt elke publiekelijk vertrouwde CA in staat om certificaten ervoor uit te geven. Met meer dan 100 vertrouwde root-CA's in de root-certificaatarchieven van browsers, is het openlaten van certificaatuitgifte aan elk van hen hetzelfde als de deur open laten staan ​​in de DNS-wereld. CAA-records dichten die kloof met één enkele DNS-vermelding op het hoogste domeinniveau die wordt doorgegeven aan alle subdomeinen.
• Uit de DigiCert Trust Pulse Survey (2 juli 2025) bleek dat 45 procent van de bedrijven het voorgaande jaar te maken had met downtime als gevolg van certificaatproblemen. Onjuist geconfigureerde CAA-records, met name records die geen actieve CA bevatten, leiden tot mislukte certificaatvernieuwingen die precies die downtime veroorzaken: het certificaat verloopt omdat de vernieuwing werd geblokkeerd tijdens de CAA-controle van de CA. Met een maximale TLS-validiteit van 47 dagen vanaf maart 2029 (CA/B Forum SC-081v3, goedgekeurd in april 2025) veroorzaakt een onjuist geconfigureerd CAA-record acht keer per jaar een mislukte vernieuwing per getroffen certificaat in plaats van één keer.
• CAA-records gebruiken drie eigenschapstags. De 'issue'-tag bepaalt welke CA standaardcertificaten mag uitgeven. De 'issuewild'-tag bepaalt onafhankelijk welke CA wildcardcertificaten mag uitgeven. De 'iodef'-tag specificeert waar CA's overtredingsrapporten naartoe moeten sturen. De 'issue'- en 'issuewild'-tags zijn onafhankelijk van elkaar; het instellen van de ene tag zonder de andere laat de helft van de certificaatnaamruimte onbeheerd.
• DNSSEC beschermt CAA-records tegen DNS-cachevergiftigingsaanvallen, waarmee een aanvaller anders valse CAA-records zou kunnen invoegen die de door hem gekozen CA autoriseren. Zonder DNSSEC biedt een CAA-record alleen bescherming tegen legitieme CA's die betrouwbare verzoeken controleren, en niet tegen actieve aanvallers die DNS-reacties manipuleren.

Wie zou zich moeten bekommeren om CAA-gegevens?

Het configureren en onderhouden van CAA-records is een gedeelde verantwoordelijkheid van DNS-beheer, PKI-beheer, beveiligingsarchitectuur en compliance-governance. Elk team is verantwoordelijk voor een specifiek onderdeel van het probleem, en hiaten in welk gebied dan ook leiden tot ofwel een openstaande uitgifte (geen CAA-records) ofwel configuratiefouten die verlenging blokkeren (verouderde of onvolledige CAA-records).

Rol	Waarom het uitmaakt	Actie-item
PKI- en certificeringsteams	Beheer de certificaat-naar-CA-mapping die bepaalt welke CA's in CAA-records moeten worden vermeld; het publiceren van CAA-records zonder eerst te controleren welke CA's actief certificaten uitgeven, leidt tot mislukte verlengingen; het schema van het CA/Browser Forum SC-081v3 (maximale geldigheidsduur van 47 dagen tot maart 2029) betekent dat elk verkeerd geconfigureerd CAA-record ongeveer acht keer per jaar tot mislukte verlengingen leidt per getroffen certificaat; de certificaatinventaris moet actueel blijven naarmate CA-relaties veranderen, certificaten tussen CA's migreren en nieuwe domeinen worden geconfigureerd.	Controleer het volledige certificatenbestand met behulp van CertSecure Manager om een ​​actuele certificaat-CA-mapping te genereren voordat CAA-records worden gepubliceerd of bijgewerkt; gebruik CBOM Secure Om alle certificaten in cloud-, on-premises- en multi-cloudomgevingen te ontdekken en alle CA's te identificeren die actief certificaten uitgeven voor elk domein; bevestigen dat het CLM-platform de verlengingen automatiseert via de CA's die in het CAA-record staan ​​vermeld, zodat inconsistenties in de verlenging worden opgespoord voordat ze storingen veroorzaken.
DNS- en infrastructuurteams	Het publiceren en onderhouden van CAA-records en DNS-zones is een vereiste; CAA-records kunnen alleen worden gepubliceerd en bijgewerkt door teams met schrijftoegang tot de DNS-zone; DNSSEC-ondertekening is een voorwaarde voor de bescherming van CAA-records tegen spoofing, en de ondertekening moet continu worden gehandhaafd (het verlopen van de RRSIG leidt tot DNSSEC-validatiefouten waardoor CAA-records niet meer gevalideerd kunnen worden); in de cloud geprovisioneerde DNS-zones en zelfservice-subdomeinen voor ontwikkelaars bevinden zich mogelijk niet in de inventaris van het DNS-team, wat kan leiden tot hiaten in de CAA-dekking.	Bevestig dat DNSSEC is geïmplementeerd en onderhouden voor elke zone waar CAA-records worden gepubliceerd; publiceer CAA-records op het hoofddomein om overervingsdekking te bieden voor alle subdomeinen; houd een DNS-zone-inventaris bij die alle cloud- en door ontwikkelaars geprovisioneerde subdomeinen omvat om te bevestigen dat de CAA-dekking compleet is; test CAA-records met dig, MX Toolbox of de SSLMate CAA Record Generator na publicatie en na elke update; plan de migratie van het DNSSEC-zoneondertekeningsalgoritme via de PQC Centrum van Uitmuntendheid
Beveiligingsarchitecten	Beheer het CAA-governancemodel: definieer het beleid voor de scheiding van de tags 'issue' en 'issuewild', stel de DNSSEC-implementatievereisten vast, specificeer het iodef-eindpunt en de monitoringintegratie, en definieer het reactieplan voor ongeautoriseerde uitgifte wanneer iodef-rapporten worden ontvangen. Zonder een gedefinieerd governancemodel worden CAA-records inconsistent gepubliceerd over domeinen en reactief in plaats van proactief bijgewerkt naarmate CA-relaties en certificaatportfolio's veranderen.	Definieer het CAA-governancebeleid: welke CA's zijn geautoriseerd voor standaardcertificaten versus wildcardcertificaten (scheiding tussen uitgifte en uitgifte), DNSSEC als verplichte voorwaarde voor alle domeinen met CAA-records, iodef-eindpunt gekoppeld aan SIEM of ticketsysteem, en driemaandelijkse CAA-auditfrequentie; definieer het reactieplan voor ongeautoriseerde uitgifte: SLA voor beoordeling van iodef-rapporten, CA-notificatieproces en escalatiepad voor bevestigde onjuiste uitgifte; plan de migratie van DNSSEC-algoritmen naar post-quantumstandaarden. PQC-gereedheid diensten
Compliance	CAA-records zijn een documenteerbare uitgiftecontrole die direct aansluit op de vereisten voor certificaatbeheer in SOC 2, ISO 27001 en PCI DSS 4.0; auditbewijs moet bevestigen dat CAA-records aanwezig zijn voor alle domeinen binnen het toepassingsgebied, dat ze het geautoriseerde CA-gebruik nauwkeurig weergeven en dat iodef-rapporten worden gemonitord en beantwoord; uit de DigiCert Trust Pulse Survey (2 juli 2025) bleek dat 37.5 procent van de certificaatgerelateerde storingen te wijten was aan verlopen certificaten, en een verkeerde CAA-configuratie die verlengingen blokkeert, is een directe oorzaak van dit vervalpatroon in omgevingen waar CA's zijn gewijzigd maar de CAA-records niet zijn bijgewerkt.	Neem de aanwezigheid en nauwkeurigheid van CAA-records op in het kwartaaloverzicht van het nalevingsbewijs: percentage van de domeinen binnen het toepassingsgebied met CAA-records, percentage van de CAA-records dat overeenkomt met de huidige certificaat-CA-mapping en responstijden van het iodef-rapport; bevestig dat CAA-records worden bijgewerkt als onderdeel van het gedocumenteerde CA-onboarding- en offboardingproces; koppel de fasedata van CA/B Forum SC-081v3 (200 dagen maart 2026, 100 dagen maart 2027, 47 dagen maart 2029) aan interne nalevingsmijlpalen voor aanpassing van de auditfrequentie van CAA-records
CISO's	Domeinen zonder CAA-records zijn kwetsbaar voor certificaatuitgifte door elk van de meer dan 100 publiekelijk vertrouwde CA's; een frauduleus uitgegeven certificaat dat een MITM-aanval of merkimitatie mogelijk maakt, leidt tot een inbreuk die de raad van toezicht bereikt; CAA-records zijn een van de eenvoudigste en goedkoopste preventieve maatregelen in de PKI-beveiligingstoolkit; het CA/B Forum SC-081v3-schema voor het verminderen van de geldigheidsduur betekent dat het onderhoud van CAA-records meegroeit met de vernieuwingsfrequentie, waardoor nauwkeurige CAA-records een steeds belangrijkere operationele vereiste worden naarmate de levensduur van certificaten afneemt tot ongeveer 47 dagen.	Eis dat elk extern bereikbaar domein een CAA-record heeft als basisbeveiligingsstandaard; financier het certificaatdetectie- en CLM-programma dat nodig is om nauwkeurige CAA-records te behouden naarmate het certificaatportfolio en de CA-relaties evolueren; evalueer PKI als een service Voor private PKI-infrastructuren waar intern CA-gebruik moet worden bijgehouden naast publiek CA-gebruik in CAA-records; vereisen dat de dekking en nauwkeurigheid van de CAA-records kwartaalrapporten worden uitgebracht als KPI's op bestuursniveau, samen met de dekking van de monitoring van de vervaldatum van certificaten.

Wat is een CAA-record?

Een Certification Authority Authorization (CAA) -record is een DNS-resource record, gestandaardiseerd onder RFC 6844 en bijgewerkt door RFC 8659, dat de wereld vertelt welke certificeringsinstanties (CA's) gemachtigd zijn om SSL/TLS-certificaten uit te geven voor uw domein of subdomein. U kunt het zien als een eenvoudige regel in uw DNS die elke CA vertelt om de toestemming te controleren voordat een certificaat wordt uitgegeven.

Een standaard CAA-record ziet er als volgt uit:

Dit record vertelt elke certificeringsinstantie (CA): alleen Let's Encrypt mag certificaten uitgeven voor bijvoorbeeld example.com. Elke andere CA die een certificaatverzoek voor dat domein ontvangt, is volgens de basisvereisten van het CA/Browser Forum verplicht om te controleren op CAA-records en de regels te volgen of de uitgifte te weigeren. CAA-records volgen ook de DNS-hiërarchie. Als een subdomein geen eigen CAA-record heeft, kijkt de CA naar het hoofddomein en past die regels toe, waardoor het eenvoudig is om beleid te beheren voor een groot aantal domeinen.

Hoe CAA-gegevens de geautoriseerde certificeringsinstanties definiëren.

CAA-records werken door specifieke CA-identificaties aan uw domein in DNS te koppelen. Wanneer een CA een verzoek ontvangt om een ​​certificaat uit te geven, zoekt deze de CAA-records voor dat domein op. Als er een CAA-record bestaat en de CA niet in de lijst staat, moet de CA het verzoek weigeren. Als er helemaal geen CAA-record bestaat, kan elke CA certificaten voor uw domein uitgeven, wat een open deur is die beveiligingsteams moeten dichten.

U kunt meerdere CA's in uw CAA-gegevens opnemen. Dit is handig voor organisaties die verschillende CA's voor verschillende doeleinden gebruiken, zoals een openbare CA voor klantgerichte diensten en een privé-CA voor interne systemen. Elke geautoriseerde CA krijgt een eigen CAA-vermelding en de CA moet overeenkomen met ten minste één vermelding om door te kunnen gaan met de certificaatuitgifte.

Inzicht in het probleem, issuewild en iodef Tags

CAA-gegevens gebruiken drie hoofdeigenschapstags om de uitgifte van certificaten te beheren. Elke tag heeft een andere functie, en het is belangrijk om ze alle drie te begrijpen om uw gegevens correct in te stellen.

Probleem: Deze tag geeft aan welke CA gemachtigd is om standaardcertificaten voor uw domein uit te geven. Bijvoorbeeld, 0 issue “digicert.com” geeft DigiCert toestemming om certificaten voor dat domein uit te geven.

Issuewild: Deze tag bepaalt welke certificeringsinstanties (CA's) wildcardcertificaten mogen uitgeven , zoals *.example.com . Dit staat los van de issue-tag, waardoor u een soepeler beleid kunt hanteren voor standaardcertificaten en een strenger beleid voor wildcardcertificaten, afhankelijk van uw beveiligingsbehoeften.

Iodef: Deze tag vertelt certificeringsinstanties (CA's) waar ze een melding naartoe moeten sturen als ze een certificaatverzoek ontvangen dat in strijd is met uw beleid. U kunt een e-mailadres of een URL opgeven, bijvoorbeeld zo:

0 iodef "mailto:[email protected]"

Een belangrijk aandachtspunt: als u alleen een issuewild-tag instelt zonder een issue-tag, kan elke certificeringsinstantie (CA) nog steeds standaardcertificaten voor uw domein uitgeven. De twee tags zijn onafhankelijk van elkaar, dus configureer ze altijd allebei om er zeker van te zijn dat uw beleid compleet is.

CAA-tagreferentie: issue, issuewild en iodef

Gebruik deze tabel als snel naslagwerk bij het configureren of controleren van CAA-records. Elke rij beschrijft wat de tag beheert, een voorbeeld van de syntaxis, wanneer deze te gebruiken is en wat er gebeurt als de tag ontbreekt of verkeerd geconfigureerd is. Alle drie de tags moeten elk kwartaal worden gecontroleerd aan de hand van de actuele certificaat-CA-mapping uit de CLM-inventaris.

Dag	Wat het controleert	Voorbeeldsyntaxis	Wanneer te gebruiken	Foutmodus indien weggelaten of verkeerd geconfigureerd
kwestie	Welke CA('s) mogen standaard (niet-wildcard) SSL/TLS-certificaten voor het domein uitgeven? Meerdere uitgifte-opties zijn toegestaan, één per geautoriseerde CA. Als de waarde wordt ingesteld op een lege tekenreeks ("0 uitgifte ""), worden alle CA's verboden om standaardcertificaten uit te geven.	0 uitgave “digicert.com” 0 probleem “letsencrypt.org”	Altijd. Elk domein moet minstens één issue-tag hebben die expliciet alle CA's vermeldt die gemachtigd zijn om standaardcertificaten voor dat domein uit te geven. Zonder deze tag kan elke CA standaardcertificaten uitgeven, ongeacht de andere aanwezige tags.	Weggelaten: elke CA kan standaardcertificaten uitgeven. Onjuiste CA vermeld: verlenging mislukt wanneer de actieve CA het CAA-register controleert en vaststelt dat deze niet vermeld staat; bij een geldigheidsduur van 47 dagen leidt dit tot ongeveer 8 mislukte verlengingen per jaar per getroffen certificaat.
probleemwild	Welke CA('s) mogen wildcard SSL/TLS-certificaten (*.domain.com) uitgeven voor het domein? Onafhankelijk van de issue-tag. Als issuewild ontbreekt, gelden voor de uitgifte van wildcardcertificaten de beperkingen van de issue-tag.	0 issuewild “digicert.com” 0 issuewild “” (blokkeert alle uitgifte van wildcards)	Elk domein waarvoor wildcardcertificaten worden of kunnen worden uitgegeven. Stel dit expliciet in om specifieke CA's te machtigen voor de uitgifte van wildcardcertificaten of om de uitgifte van wildcardcertificaten volledig te verbieden (0 issuewild “”) voor domeinen die geen wildcardcertificaten vereisen.	Weggelaten: bij de uitgifte van wildcards wordt teruggevallen op de uitgiftetag, wat mogelijk toleranter is dan bedoeld. Onjuist geconfigureerd (vermeldt CA die niet voor wildcards wordt gebruikt): de verlenging van de wildcard mislukt. Het niet instellen van issuewild wanneer issuewild niet nodig is, is acceptabel als de controle op de uitgiftetag voldoende is.
jodef	Waar CA's een melding moeten versturen wanneer ze een certificaataanvraag ontvangen die in strijd is met het CAA-beleid van het domein. Accepteert een e-mailadres (mailto:) of een URL-eindpunt. Blokkeert de uitgifte niet; geeft alleen een melding.	0 iodef “mailto:[e-mail beveiligd]" 0 iodef “https://example.com/caa-report”	Elk domein met issue- of issuewild-records. De iodef-tag is het notificatiemechanisme dat de handhaving van het CAA-beleid zichtbaar maakt. Zonder deze tag blijven beleidsschendingen onopgemerkt: de CA weigert, maar de domeineigenaar wordt nooit op de hoogte gesteld.	Weggelaten: beleidsschendingen blijven stil; er wordt geen melding verzonden wanneer een niet-geautoriseerde CA een certificaatverzoek voor het domein ontvangt. Eindpunt niet bewaakt: meldingen komen wel binnen, maar niemand onderneemt actie, waardoor de operationele waarde van de iodef-tag vervalt.

Waarom CAA-records essentieel zijn voor domeinbeveiliging

Ongeautoriseerde certificaatuitgifte is een serieus probleem. Of het nu via social engineering, een fout bij de certificeringsinstantie (CA) of een gecompromitteerd systeem gebeurt, er worden onterecht certificaten uitgegeven voor bekende domeinen. Wanneer dit gebeurt, kunnen aanvallers versleuteld verkeer onderscheppen, man-in-the-middle-aanvallen uitvoeren of zich voordoen als legitieme diensten.

CAA-records voorkomen niet elke mogelijke aanval, omdat ze afhankelijk zijn van CA's die ze controleren en naleven, en de naleving wordt geregeld door het CA/Browser Forum. Maar sinds september 2017 zijn alle publiekelijk vertrouwde CA's volgens de Baseline Requirements van het CA/Browser Forum verplicht om CAA-records te controleren voordat ze certificaten uitgeven. Een CA die dit negeert, riskeert zijn vertrouwde status te verliezen, wat ernstige gevolgen kan hebben.

CAA-gegevens ondersteunen ook de naleving van regelgeving. Binnen raamwerken zoals SOC 2, ISO 27001 en PCI DSS is het kunnen aantonen dat u bepaalt welke CA's certificaten voor uw domein uitgeven een solide, aantoonbare beveiligingsmaatregel. Het helpt bij audits en laat zien dat uw organisatie de domeinbeveiliging op de juiste manier beheert.

Hoe certificeringsinstanties CAA-gegevens valideren

Wanneer een certificeringsinstantie (CA) een certificaatverzoek ontvangt, voert deze een DNS-lookup uit naar CAA-records voor de volledig gekwalificeerde domeinnaam (FQDN) in het verzoek. Als er records worden gevonden en de CA niet in de lijst staat, weigert de CA het certificaat uit te geven. Als de DNS-query mislukt vanwege een SERVFAIL, time-out of verkeerde configuratie, moet de CA het verzoek ook weigeren. Deze fail-secure aanpak betekent dat een foutieve configuratie u beschermt in plaats van u kwetsbaar te maken.

DNSSEC biedt hier een extra beschermingslaag. Zonder DNSSEC kunnen CAA-records worden vervalst door middel van DNS-cachevergiftiging, waarbij een aanvaller valse records invoegt waardoor de door hem gekozen certificeringsinstantie een certificaat kan uitgeven. Wanneer uw DNS-zones zijn ondertekend met DNSSEC, zijn de nauwkeurigheid en integriteit van uw CAA-records gegarandeerd op cryptografisch niveau.

Als er geen CAA-record bestaat voor een specifieke FQDN, doorloopt de CA de DNS-structuur omhoog naar het bovenliggende domein, vervolgens naar het grootouderdomein, totdat er een record wordt gevonden. Dit betekent dat één enkel CAA-record op uw apexdomein uw volledige domeinnaamruimte kan bestrijken, wat een zeer efficiënte manier is om beleid op grote schaal af te dwingen.

CAA-configuratie: vereisten, storingsmodi en bewakingssignalen

Gebruik deze tabel om elke CAA-configuratievereiste te koppelen aan de bijbehorende validatiemethode, de foutmodus wanneer niet aan de vereiste wordt voldaan, het monitoringsignaal dat de fout aan het licht brengt en de gezaghebbende beleidsbron. CAA-gegevens en de basisvereisten van het CA/Browser Forum worden elk kwartaal herzien en kunnen onafhankelijk van elkaar worden bijgewerkt.

eis	Validatiemethode	Faal modus	Monitoringsignaal	Beleidsbron
CAA-records aanwezig voor elk extern oplosbaar domein	DNS-lookup (dig TYPE257 domain.com of dig CAA domain.com); MX Toolbox CAA-controle; SSLMate CAA Record Generator; CLM-platform domeinaudit	Geen CAA-registratie: elke publiekelijk erkende CA kan certificaten voor het domein uitgeven; ongeautoriseerde uitgifte blijft onopgemerkt totdat een CT-logmonitor of een iodef-rapport dit aan het licht brengt.	CLM-platformdomeinaudit toont domeinen zonder CAA-records; CT-logmonitoringwaarschuwing voor onverwacht certificaat uitgegeven voor een onbeveiligd domein	RFC 6844 (CAA-standaard); RFC 8659 (CAA-update); CA/Browser Forum Baseline Requirements Sectie 3.2.2.8 (CAA-controleverplichting, van kracht sinds september 2017)
De tags issue en issuewild komen overeen met alle certificeringsinstanties die actief domeinen uitgeven.	Vergelijk de CLM-certificaatinventaris (welke CA elk certificaat voor elk domein heeft uitgegeven) met de CA's die in het CAA-record voor dat domein staan ​​vermeld; controleer of elke actieve CA is opgenomen; test door een certificaatvernieuwing aan te vragen bij elke geautoriseerde CA en te controleren of de CAA-controle slaagt.	Het CAA-record mist een actieve CA: de certificaatvernieuwing mislukt bij de CAA-controle van de CA; bij een maximale geldigheidsduur van 47 dagen (SC-081v3, maart 2029) leidt dit tot ongeveer 8 mislukte vernieuwingen per jaar per getroffen certificaat; de mislukking wordt weergegeven als een weigeringsfout van de CA in plaats van een waarschuwing voor het verlopen van het certificaat.	Meldingen over mislukte certificaatvernieuwingen in het CLM-platform correleren met CAA-zoekfouten; CA-foutreacties verwijzen naar het CAA-beleid tijdens de vernieuwing; CLM-inventarisvergelijking toont een CA-mismatch tussen de certificaatuitgever en de inhoud van het CAA-record.	RFC 6844 Sectie 4 (CAA-eigenschapstags); CA/Browser Forum Basisvereisten Sectie 3.2.2.8; CA/B Forum SC-081v3 (goedgekeurd april 2025) voor context van de vernieuwingsfrequentie
Het iodef-eindpunt is geconfigureerd en wordt bewaakt.	Controleer of de iodef-tag aanwezig is in het CAA-record voor alle domeinen; test of het iodef-eindpunt bereikbaar en correct geformatteerd is; controleer of iodef-rapporten worden doorgestuurd naar het SIEM- of ticketsysteem en binnen de vastgestelde SLA worden beoordeeld; let op: niet alle CA's implementeren iodef-rapportage; controleer de iodef-ondersteuning bij elke geautoriseerde CA.	Iodef-tag ontbreekt: beleidsschendingen blijven onopgemerkt; een niet-geautoriseerde CA ontvangt een certificaatverzoek, maar de domeineigenaar wordt nooit op de hoogte gesteld; de schending is alleen te ontdekken via monitoring van CT-logboeken. Iodef-eindpunt niet gemonitord: meldingen komen binnen, maar niemand onderneemt actie.	SIEM- of ticketsysteemwaarschuwing voor nieuw ontvangen iodef-rapport; hiaat in het logboek voor de beoordeling van iodef-rapporten vastgesteld tijdens de kwartaalaudit; CT-logboekbewakingswaarschuwing voor onverwacht certificaat dat een iodef-rapport had moeten activeren.	RFC 6844 Sectie 5.4 (iodef-eigenschapstag); CA/Browser Forum Baseline Requirements Sectie 3.2.2.8
DNSSEC-ondertekening voor alle domeinen met CAA-records.	Externe DNSSEC-validator (DNSViz, Verisign DNSSEC Analyzer); controleer of de AD-vlag is ingesteld op CAA-recordreacties van DNSSEC-validerende resolvers; controleer of RRSIG-records aanwezig en niet verlopen zijn voor de zone.	Geen DNSSEC: CAA-records zijn kwetsbaar voor DNS-cachevergiftiging; een aanvaller kan valse CAA-records invoegen die de door hem gekozen CA machtigen om een ​​frauduleus certificaat uit te geven; het CAA-record zorgt alleen voor beleidshandhaving tegen eerlijke CA's, niet tegen actieve aanvallers die DNS manipuleren.	DNSSEC-validatiefout van externe validators; AD-vlag niet ingesteld op CAA-record in DNS-reacties; RRSIG-vervalwaarschuwingen van DNS-monitoring; certificaat uitgegeven voor een domein met een vervalst CAA-record (gedetecteerd via CT-logmonitoring)	RFC 4033-4035 (DNSSEC); RFC 6844 Sectie 3 (beveelt DNSSEC aan voor CAA); NIST SP 800-81-2 (richtlijnen voor de implementatie van DNSSEC)
CAA-gegevens worden bijgewerkt wanneer de relaties met CA veranderen.	Controleer of de processen voor het toelaten en afstoten van CA's een stap bevatten voor het bijwerken van CAA-gegevens; controleer CAA-gegevens elk kwartaal aan de hand van de huidige koppeling tussen certificaat en CA; test verlenging via elke CA die sinds de laatste controle is toegevoegd of verwijderd om te bevestigen dat de CAA-gegevens correct zijn.	Het CAA-record vermeldt een CA die niet langer in gebruik is: geen onmiddellijke fout, maar er blijft een onnodig risico bestaan ​​voor geautoriseerde uitgevers. Het CAA-record vermeldt geen nieuw toegevoegde CA: certificaatvernieuwingen mislukken onmiddellijk voor alle certificaten die naar de nieuwe CA worden gemigreerd.	Meldingen over mislukte certificaatvernieuwingen in het CLM-platform tijdens CA-migratie; CLM-inventarisvergelijking toont aan dat de nieuw toegevoegde CA niet in het CAA-record staat vermeld; driemaandelijkse CAA-audit identificeert verouderde CA-vermeldingen in CAA-records voor domeinen waar die CA niet langer certificaten uitgeeft.	RFC 8659 Sectie 4 (CAA-recordbeheer); CA/Browser Forum Basisvereisten Sectie 3.2.2.8; intern CA-beleid voor het beheer van wijzigingen bij het in- en uitdiensttreden.

Beste werkwijzen voor het configureren en beheren van CAA-records

Het opzetten van CAA-gegevens is eenvoudig, maar om het goed te doen, is enige planning vereist. Hieronder volgen de belangrijkste stappen:

• Controleer eerst uw certificateninventaris: Voordat u CAA-records toevoegt, moet u eerst achterhalen welke CA's al certificaten voor uw domeinen uitgeven. Tools zoals crt.sh kunnen u hierbij helpen. Als u de uitgifte beperkt tot een CA die u niet daadwerkelijk gebruikt, zullen certificaatverlengingen mislukken.
• Stel zowel de issue- als de issuewild-tag expliciet in: Ga er niet van uit dat het ene het andere uitsluit. Wees duidelijk over welke certificeringsinstanties (CA's) standaardcertificaten en wildcardcertificaten mogen uitgeven en houd bij waarom elke CA geautoriseerd is.
• Voeg een iodef-tag toe en monitor deze daadwerkelijk: Rapporten zijn alleen nuttig als ze ook daadwerkelijk gelezen worden. Koppel uw iodef-eindpunt aan het ticketsysteem of SIEM van uw beveiligingsteam en neem alle waarschuwingen over overtredingen serieus.
• Gebruik CAA-records in combinatie met DNSSEC: DNSSEC zorgt ervoor dat uw CAA-beleid niet op DNS-niveau kan worden vervalst. Als uw zones nog niet DNSSEC-ondertekend zijn, is dit een goede reden om ermee te beginnen.
• Controleer uw CAA-gegevens na publicatie: Gebruik tools zoals dig, de SSLMate CAA Record Generator of MX Toolbox om te controleren of uw records correct worden opgelost vanuit meerdere locaties.
• Werk de CAA-gegevens bij wanneer uw CA-relaties wijzigen: Telkens wanneer u van CA wisselt, een nieuwe leverancier contracteert of een fusie doormaakt, dient u uw CAA-gegevens bij te werken. Verouderde gegevens kunnen net zo riskant zijn als ontbrekende gegevens.

Hoe encryptieconsultancy kan helpen

Het correct instellen van CAA-records begint met precies weten welke certificeringsinstanties (CA's) al certificaten uitgeven voor uw domeinen. Zonder die inventarisatie loopt u het risico een CA die actief certificaten vernieuwt, buiten te sluiten, wat storingen veroorzaakt zodra een vernieuwing mislukt. Deze controle is waar de meeste organisaties vastlopen, en dat is waar CertSecure Manager het grootste verschil maakt.

CertSecure Manager is het platform voor certificaatlevenscyclusbeheer van Encryption Consulting. Het biedt uw team een ​​complete, continu bijgewerkte inventaris van elk SSL/TLS-certificaat in uw omgeving, inclusief welke CA elk certificaat heeft uitgegeven, wanneer het verloopt en waar het is geïmplementeerd. Deze zichtbaarheid is precies wat u nodig hebt voordat u ook maar één CAA-record opstelt. Voor volledig inzicht in uw cryptografische omgeving, naast certificaten, breidt CBOM Secure de ontdekking uit naar algoritmen, sleutels en cryptografische afhankelijkheden in cloud-, on-premises- en hybride omgevingen.

Hieronder leggen we uit hoe CertSecure Manager elk van deze uitdagingen aanpakt:

Certificaatdetectie en -inventarisatie: Onze CertSecure Manager scant uw netwerk- en cloudomgevingen om elk in gebruik zijnd certificaat te vinden, ongeacht door welke CA het is uitgegeven. Voordat u de uitgifte beperkt via CAA-records, moet u weten welke certificaten er al in omloop zijn. Deze stap wordt automatisch uitgevoerd.

Relatiebeheer met certificeringsinstanties: Omdat uw CAA-beleid slechts zo nauwkeurig is als uw kennis van de certificeringsinstanties die u daadwerkelijk gebruikt, zorgt CertSecure Manager ervoor dat uw certificaatinventaris actueel blijft, zodat uw CAA-gegevens overeenkomen met de werkelijkheid, zelfs als uw omgeving groeit of uw relaties met certificeringsinstanties veranderen.

Automatisering van certificaatvernieuwing: Zodra uw CAA-gegevens correct zijn ingesteld, zal elke certificaatvernieuwing die naar een niet-geautoriseerde CA wordt gestuurd, mislukken. CertSecure Manager automatiseert de vernieuwingen via uw geautoriseerde CA's, zodat u niet voor verrassingen komt te staan ​​wanneer een certificaat bijna verloopt.

Auditlogboek voor compliance: Voor frameworks zoals SOC 2, ISO 27001 en PCI DSS is het aantonen van controle over de certificaatuitgifte een documenteerbare beveiligingsmaatregel. CertSecure Manager registreert elke certificaatgebeurtenis, waardoor uw compliance-team het bewijsmateriaal krijgt dat ze nodig hebben.

CAA-records bieden u beleid. CertSecure Manager biedt u het inzicht en de automatisering om dat beleid consistent toe te passen in uw gehele certificaatomgeving. Voor organisaties die een private PKI-infrastructuur bouwen of uitbreiden, biedt PKI as a Service een volledig beheerde CA-hiërarchie waarin intern CA-gebruik naadloos integreert met het beheer van CAA-records. Voor de planning van DNSSEC-zoneondertekeningsalgoritmen die naast CAA worden gebruikt, na de quantummigratie, kunt u de vereisten volgen via het PQC Center of Excellence.

Conclusie

CAA-records worden vaak over het hoofd gezien omdat ze onopvallend op de achtergrond werken, maar het weglaten ervan creëert een aanzienlijk beveiligingslek. Aangezien het misbruik van certificaten een steeds groter risico vormt op internet, moeten domeineigenaren controle hebben over wie namens hen certificaten mag uitgeven. CAA-records bieden die controle op een eenvoudige, gestandaardiseerde manier.

Wanneer CAA-records correct zijn ingesteld en gekoppeld aan DNSSEC, een bewaakt iodef-eindpunt en een degelijk certificaatbeheerproces, vormen ze een waardevol onderdeel van uw PKI-strategie. Ze zijn niet moeilijk te implementeren, maar moeten wel actueel worden gehouden naarmate uw omgeving verandert.

Deze handleiding wordt elk kwartaal herzien, en onmiddellijk wanneer het CA/Browser Forum de basisvereisten voor CAA-controleregels bijwerkt of nieuwe CAA-eigendomstags introduceert.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit CAA Records Explained: Definiëren welke certificeringsinstanties certificaten voor uw domein kunnen uitgeven?

CAA-records zijn een DNS-uitgiftecontrole (RFC 6844, bijgewerkte RFC 8659) die beperkt welke certificeringsinstanties SSL/TLS-certificaten voor uw domein mogen uitgeven. Deze controle wordt sinds september 2017 afgedwongen door de CA/Browser Forum Baseline Requirements. Een domein zonder CAA-records staat elke publiekelijk vertrouwde CA toe om certificaten voor dat domein uit te geven. Drie tags controleren de uitgifte: issue (standaardcertificaten), issuewild (wildcardcertificaten) en iodef (rapportage van overtredingen). DNSSEC beschermt CAA-records tegen spoofing. De tags issue en issuewild zijn onafhankelijk van elkaar; het instellen van de ene tag zonder de andere laat de helft van de certificaatnaamruimte ongecontroleerd.

Waarom zijn CAA-gegevens belangrijk voor PKI-teams binnen bedrijven?

Enterprise PKI-teams worden geconfronteerd met twee CAA-gerelateerde risico's. Een domein zonder CAA-records staat open voor certificaatuitgifte door elk van de meer dan 100 publiekelijk vertrouwde CA's, die allemaal gecompromitteerd of onder druk gezet kunnen worden. Uit de DigiCert Trust Pulse Survey (2 juli 2025) bleek dat 45 procent van de bedrijven te maken had met downtime als gevolg van certificaatproblemen; verkeerd geconfigureerde CAA-records die een actieve CA weglaten, veroorzaken verlengingsfouten met precies die downtime tot gevolg. Bij een maximale TLS-validiteit van 47 dagen vanaf maart 2029 (CA/B Forum SC-081v3, goedgekeurd in april 2025) veroorzaakt een verkeerd geconfigureerd CAA-record ongeveer acht keer per jaar verlengingsfouten per getroffen certificaat.

Welke risico's nemen toe als CAA-gegevens niet geconfigureerd zijn of handmatig worden beheerd?

Drie risicocategorieën nemen toe: blootstelling aan open uitgifte (zonder CAA-records kan elke publiekelijk vertrouwde CA certificaten voor het domein uitgeven); verkeerde configuratie die verlengingen blokkeert (een CAA-record dat een actieve CA weglaat, veroorzaakt verlengingsfouten, acht keer per jaar bij een geldigheidsduur van 47 dagen); en wildcard-gat (het configureren van issue zonder issuewild, of issuewild zonder issue, laat de helft van de certificaatnaamruimte onbeheerd achter).

Welke teams zouden verantwoordelijk moeten zijn voor de configuratie en het onderhoud van CAA-records?

De DNS- en infrastructuurteams zijn verantwoordelijk voor de publicatie van CAA-records en het onderhoud van DNSSEC. De PKI- en certificaatteams zijn verantwoordelijk voor de mapping van certificaten naar CA's, die bepaalt welke CA's moeten worden vermeld. De beveiligingsarchitecten zijn verantwoordelijk voor het governance-model: het beleid voor uitgegeven versus niet-uitgegeven certificaten, de monitoring van iodef-eindpunten en het draaiboek voor reacties op ongeautoriseerde uitgifte. De compliance-teams zijn verantwoordelijk voor het auditbewijs dat bevestigt dat CAA-records aanwezig, correct en actueel zijn voor alle domeinen die binnen het toepassingsgebied vallen.

Hoe zijn CAA-gegevens gekoppeld aan het beheer van de certificaatlevenscyclus?

CAA-records zijn een afhankelijkheid in de levenscyclus: elke certificaatvernieuwing activeert een CAA-lookup bij de uitgevende CA. Een CAA-record waarin de vernieuwende CA ontbreekt, zorgt ervoor dat de vernieuwing mislukt. CertSecure Manager biedt de certificaatinventaris die nodig is om te bevestigen welke CA's moeten worden vermeld voordat CAA-records worden gepubliceerd en automatiseert vernieuwingen via geautoriseerde CA's, zodat CAA-mismatches geen storingen veroorzaken.

Hoe moeten organisaties het succes van de CAA-registratieprocedure meten?

Belangrijkste prestatie-indicatoren: 100 procent van de domeinen in eigendom van de organisatie met CAA-records; 100 procent van de CAA-records die overeenkomen met de huidige certificaat-CA-mapping uit de CLM-inventaris; geen mislukte certificaatvernieuwingen als gevolg van een verkeerde CAA-configuratie; iodef-rapporten beoordeeld binnen de vastgestelde SLA (doel: 100 procent binnen 24 uur); en DNSSEC-ondertekeningsdekking voor 100 procent van de domeinen met CAA-records.

Wat moet er regelmatig gecontroleerd of gemonitord worden?

Continue monitoring: iodef-rapporten van alle geautoriseerde CA's met geautomatiseerde waarschuwingen; gebeurtenissen met betrekking tot mislukte certificaatvernieuwingen die correleren met CAA-zoekfouten. Kwartaalcontrole: aanwezigheid van CAA-records voor alle domeinen in eigendom van de organisatie; nauwkeurigheid van CAA-records ten opzichte van de huidige certificaat-CA-mapping; DNSSEC-ondertekeningsstatus voor alle domeinen met CAA-records; en CA/B Forum Baseline Requirements voor eventuele CAA-gerelateerde updates.

Welke invloed hebben CAA-records op cloud-, hybride- of multi-CA PKI-omgevingen?

Omgevingen met meerdere certificeringsinstanties (CA's) maken CAA-records het meest complex: elk domein kan meerdere geautoriseerde CA's hebben (een publieke CA voor klantgerichte TLS, een private CA voor interne services en een cloudprovider-CA voor cloud-native workloads), en het CAA-record moet ze allemaal correct vermelden. Cloud-geprovisioneerde subdomeinen die niet in de DNS-inventaris staan, creëren hiaten in de dekking. Een CLM-platform met cross-environment discovery is een voorwaarde voor accurate CAA-records in een omgeving met meerdere CA's en meerdere clouds.

Welke veelgemaakte fouten moeten teams vermijden?

De meest voorkomende fouten: het publiceren van CAA-records voordat gecontroleerd is welke CA's actief certificaten uitgeven (dit leidt tot verlengingsfouten als een actieve CA wordt weggelaten); het instellen van issuewild zonder ook issue in te stellen (waardoor standaard certificaatuitgifte openstaat voor elke CA); het niet opnemen van alle CA's die in subdomeinen worden gebruikt; het niet configureren van DNSSEC (waardoor CAA-records kwetsbaar worden voor DNS-cachevergiftiging); en het niet monitoren van iodef-rapporten (waardoor de notificatiewaarde van de iodef-tag vervalt).

Wat moet er elk kwartaal vernieuwd worden?

Driemaandelijks: vergelijk CAA-records met de huidige certificaat-naar-CA-mapping uit de CLM-inventaris; bevestig dat DNSSEC alle domeinen ondertekent met CAA-records; bekijk de iodef-rapporten van het voorgaande kwartaal; bevestig dat nieuwe domeinen die sinds de laatste audit zijn toegevoegd, CAA-records hebben; en controleer of de CA/B Forum Baseline Requirements geen nieuwe CAA-controleregels hebben geïntroduceerd. Voor de planning van de DNSSEC-algoritmemigratie na de quantumupdate kunt u terecht bij het PQC Center of Excellence . Dit bericht wordt driemaandelijks herzien.