Uitleg CAA
Wat is CAA?
CAA publiceert bedoelde issuernamen voor nieuwe certificaten. Lees over de DNS-walk, wildcard- en e-mailregels, CA-afhankelijke parameters en scangrenzen.
CAA is een DNS-publicatie waarmee een domein vastlegt welke issuernamen van certificaatautoriteiten het wil autoriseren. Het begrenst nieuwe certificaatuitgifte; het trekt geen bestaand certificaat in en bewijst niet wat een concrete CA zal beslissen.
Hoe de opvraag werkt
Voor uitgifte begint een CA bij het aangevraagde domein en controleert elke parent tot en met het TLD. De eerste niet-lege CAA-RRset is relevant; een RRset op een subdomein vervangt de records van een parent en wordt er niet mee samengevoegd. Bestaat nergens een relevante RRset, dan publiceert CAA geen beperking.
Een CA zonder passende autorisatie weigert normaal gesproken de uitgifte. De concrete aanvraag, CA-ondersteuning en een gedocumenteerde CP/CPS-uitzondering bepalen mede het uiteindelijke besluit.
De vier bruikbare tags
issue: issuernamen voor gewone certificatenissuewild: issuernamen voor wildcardcertificaten; zonder deze tag geldtissueook voor wildcardsissuemail: issuernamen voor certificaten over e-mailadressen; onafhankelijk vanissueenissuewildiodef: een rapport-URI; publicatie garandeert niet dat een CA rapporteert of dat het endpoint werkt
Een lege issuer, bijvoorbeeld 0 issue ";", publiceert voor die vraag geen geautoriseerde issuer.
Parameters en de critical-vlag
RFC 8657 definieert accounturi en validationmethods voor issue en issuewild. Ze beperken een aanvraag alleen wanneer die CA ze expliciet ondersteunt en herkent; leid ondersteuning niet af uit alleen de syntaxis. Parameters op issuemail zijn CA-specifiek.
Vlag 128 maakt een property critical. Een CA die die tag niet ondersteunt, mag niet uitgeven, ook wanneer de tag geregistreerd is. Gebruik deze vlag alleen bij gedocumenteerde CA-ondersteuning.
Wat DNS Radar kan bewijzen
DNS Radar vergelijkt publicatieroutes via antwoorden uit de cache van publieke DoH-resolvers. De scan is geen CA en reconstrueert niet de autoritatieve opvraag van een CA. AD is de validatiebewering van de resolver. De e-mailuitkomst is de hypothetische RFC 9495-vraag voor een adres op het gescande domein. Voor iodef controleert de scan syntaxis en lokale endpointvorm, niet aflevering of bereikbaarheid.
Zo stel je CAA in
- Inventariseer elke CA en dienst die namens jou certificaten aanvraagt
- Publiceer de issuernaam uit de documentatie van elke CA
- Voeg
issuewildalleen toe wanneer wildcardbeleid vanissuemoet verschillen - Voeg
issuemailalleen toe wanneer je S/MIME- of vergelijkbare e-mailcertificaten gebruikt - Voeg RFC 8657-parameters of vlag
128pas toe nadat je ondersteuning hebt bevestigd - Scan opnieuw en controleer beide resolverroutes en de gekozen RRset-owner
Primaire bronnen
Veelgestelde vragen
Trekt CAA bestaande certificaten in?
Nee. CAA wordt beoordeeld bij nieuwe uitgifte en vernieuwing. Bestaande certificaten blijven geldig tot ze verlopen of via een ander mechanisme worden ingetrokken.
Wat als ik meerdere CA's gebruik?
Publiceer per issuernaam een sturende property. Neem ook hosting-, CDN- en andere diensten mee die namens jou certificaten aanvragen.
Hoe werken gewone, wildcard- en e-mailregels samen?
issue stuurt gewone certificaten en is de wildcardfallback wanneer issuewild ontbreekt. issuemail is onafhankelijk en valt nooit terug op een van beide TLS-tags.
Garandeert een groene scan dat een CA uitgeeft?
Nee. De scan bewijst wat de gemeten publieke DNS-antwoorden publiceren. CA-identiteit, parameterondersteuning, aanvraagvalidatie en CP/CPS-besluiten vallen erbuiten.