CAA-poster förklarade: Definiera vilka certifikatutfärdare som kan utfärda för din domän

I PKI-världen (Public Key Infrastructure) är förtroende viktigare än något annat. Organisationer lägger ner mycket tid och pengar på att säkra sina domäner med SSL/TLS-certifikat , men många tänker inte på vem som faktiskt har rätt att utfärda dessa certifikat. Den luckan kan orsaka allvarliga problem. CAA-poster är ett enkelt DNS-verktyg som låter domänägare tydligt bestämma vilka certifikatutfärdare som har rätt att utfärda certifikat för deras domän.

Om ditt säkerhetsprogram ännu inte använder DNS CAA-poster, kommer den här guiden att guida dig genom vad de är, hur de fungerar och varför alla organisationer bör använda dem.

Snabbt svar: Vad är en CAA-post?

En CAA-post (Certification Authority Authorization) är en DNS-resurspost (RFC 6844, uppdaterad RFC 8659) som anger för certifikatutfärdare vilka som har tillstånd att utfärda SSL/TLS-certifikat för din domän. Sedan september 2017 måste alla offentligt betrodda certifikatutfärdare kontrollera CAA-poster innan de utfärdar. En domän utan CAA-poster tillåter vilken certifikatutfärdare som helst att utfärda certifikat för den . Tre taggar styr utfärdandet: issue , issuewild och iodef.

Key Takeaways

• CAA-poster är en DNS-utgivningskontroll standardiserad i RFC 6844 (uppdaterad RFC 8659) som begränsar vilka certifikatutfärdare som kan utfärda SSL/TLS-certifikat för en domän. Sedan september 2017 kräver CA/Browser Forum Baseline Requirements att alla offentligt betrodda CA:er kontrollerar CAA-poster innan de utfärdar ett certifikat. En CA som inte listas måste vägra; ett SERVFAIL under sökningen måste också orsaka vägran (felsäkert beteende).
• En domän utan CAA-poster på någon nivå i DNS-hierarkin tillåter vilken offentligt betrodd CA som helst att utfärda certifikat för den. Med fler än 100 betrodda rot-CA:er i webbläsarens rotlagrar är det att lämna utfärdandet öppet för vilken som helst av dem DNS-motsvarigheten till att lämna dörren olåst. CAA-poster täcker den klyftan med en enda DNS-post vid apex-domänen som ärver ner genom alla underdomäner.
• DigiCert Trust Pulse Survey (2 juli 2025) fann att 45 procent av företagen upplevde certifikatrelaterade driftstopp under föregående år. Felkonfigurerade CAA-poster, särskilt de som utelämnar en aktiv CA, orsakar misslyckade certifikatförnyelser som producerar just den driftstoppen: certifikatet upphör att gälla eftersom förnyelsen blockerades vid CA:s CAA-kontroll. Vid 47 dagars maximal TLS-giltighet från mars 2029 (CA/B Forum SC-081v3, godkänd april 2025) orsakar en felkonfigurerad CAA-post förnyelsemisslyckade åtta gånger per år per påverkat certifikat snarare än en gång.
• CAA-poster använder tre egenskapstaggar. Issue-taggen styr vilken CA som kan utfärda standardcertifikat. Issuewild-taggen styr oberoende vilken CA som kan utfärda jokerteckenscertifikat. Iodef-taggen anger vart CA:er ska skicka överträdelserapporter. Issue- och issuewild-taggarna är oberoende av varandra; om den ena anges utan den andra lämnas halva certifikatnamnrymden okontrollerad.
• DNSSEC skyddar CAA-poster från DNS-cacheförgiftningsattacker som annars skulle tillåta en angripare att infoga falska CAA-poster som auktoriserar den valda CA:n. Utan DNSSEC tillhandahåller en CAA-post endast policytillämpning mot ärliga CA:er som kontrollerar legitima förfrågningar, inte mot aktiva angripare som manipulerar DNS-svar.

Vem borde bry sig om CAA-register

Konfiguration och underhåll av CAA-poster är ett delat ansvar för DNS-verksamhet, PKI-hantering, säkerhetsarkitektur och efterlevnadsstyrning. Varje team äger en distinkt del av problemet, och luckor inom vilket område som helst leder antingen till öppna utfärdanden (inga CAA-poster) eller felkonfigurationer som blockerar förnyelser (föråldrade eller ofullständiga CAA-poster).

Roll	Varför det gäller	Åtgärdsobjekt
PKI- och certifikatteam	Äga certifikat-till-CA-mappningen som avgör vilka CA:er som måste listas i CAA-poster; publicering av CAA-poster utan att först granska vilka CA:er som aktivt utfärdar orsakar förnyelsemisslyckanden; CA/Browser Forum SC-081v3-schemat (maximal giltighetstid 47 dagar senast mars 2029) innebär att varje felkonfigurerad CAA-post orsakar förnyelsemisslyckanden ungefär åtta gånger per år per påverkat certifikat; certifikatinventeringen måste hållas aktuell när CA-relationer ändras, certifikat migreras mellan CA:er och nya domäner provisioneras	Granska hela certifikattillgången med hjälp av CertSecure-hanterare att skapa en aktuell certifikat-till-CA-mappning innan publicering eller uppdatering av några CAA-poster; använda CBOM-säkerhet att upptäcka alla certifikat i moln-, lokala och multimolnmiljöer och identifiera alla CA:er som aktivt utfärdar för varje domän; bekräfta att CLM-plattformen automatiserar förnyelser via de CA:er som listas i CAA-posten så att avvikelser i förnyelser upptäcks innan de orsakar avbrott.
DNS- och infrastrukturteam	Egen publicering av CAA-poster och underhåll av DNS-zoner; CAA-poster kan endast publiceras och uppdateras av team med skrivåtkomst till DNS-zoner; DNSSEC-signering är en förutsättning för att CAA-poster ska skyddas mot förfalskning, och signering måste underhållas kontinuerligt (RRSIG-utgång orsakar DNSSEC-valideringsfel som gör CAA-poster ogiltigförklarbara); molnprovisionerade DNS-zoner och utvecklarbaserade självbetjäningsunderdomäner kanske inte finns i DNS-teamets inventering, vilket skapar luckor i CAA-täckningen.	Bekräfta att DNSSEC distribueras och underhålls för varje zon där CAA-poster kommer att publiceras; publicera CAA-poster på apex-domänen för att ge arvstäckning för alla underdomäner; underhåll en DNS-zoninventering som inkluderar alla molnprovisionerade och utvecklarprovisionerade underdomäner för att bekräfta att CAA-täckningen är fullständig; testa CAA-poster med dig, MX Toolbox eller SSLMate CAA Record Generator efter publicering och efter varje uppdatering; planera migrering av DNSSEC-zonsigneringsalgoritmen genom PQC:s kompetenscentrum
Säkerhetsarkitekter	Äga CAA-styrningsmodellen: definiera policyn för separation av taggar mellan issue- och issuewild-taggar, ställa in DNSSEC-implementeringskrav, specificera iodef-slutpunkten och övervakningsintegrationen, och definiera den obehöriga utfärdandehanteringen när iodef-rapporter tas emot; utan en definierad styrningsmodell publiceras CAA-poster inkonsekvent mellan domäner och uppdateras reaktivt snarare än proaktivt när CA-relationer och certifikattillgångar förändras.	Definiera CAA:s styrningspolicy: vilka CA:er som är auktoriserade för standard- kontra wildcard-certifikat (separation mellan issue och issuewild), DNSSEC som en obligatorisk förutsättning för alla domäner med CAA-poster, iodef-slutpunkt ansluten till SIEM eller ärendesystem, och kvartalsvis CAA-revisionskadens; definiera handbok för svar på obehöriga utfärdanden: granskning av iodef-rapport, SLA, CA-meddelandeprocess och eskaleringsväg för bekräftade felaktiga utfärdanden; planera migrering av DNSSEC-algoritmen till post-kvantumstandarder genom PQC-beredskap tjänster
Compliance-team	CAA-poster är en dokumenterbar utfärdandekontroll som mappar direkt till certifikatstyrningskrav i SOC 2, ISO 27001 och PCI DSS 4.0; revisionsbevis måste bekräfta att CAA-poster finns för alla domäner inom scopet, att de korrekt återspeglar auktoriserad CA-användning och att iodef-rapporter övervakas och besvaras; DigiCert Trust Pulse Survey (2 juli 2025) fann att 37.5 procent av certifikatrelaterade avbrott spårades till utgångna certifikat, och CAA-felkonfiguration som blockerar förnyelser är en direkt orsak till detta utgångsmönster i miljöer där CA:er ändrades men CAA-poster inte uppdaterades.	Inkludera närvaro och noggrannhet av CAA-poster i det kvartalsvisa bevispaketet för efterlevnad: andel domäner inom scope med CAA-poster, andel CAA-poster som matchar den aktuella mappningen mellan certifikat och CA, och svarstider för iodef-rapporter; bekräfta att CAA-poster uppdateras som en del av den dokumenterade CA-introduktions- och avstängningsprocessen; mappa CA/B Forum SC-081v3-fasdatum (200-dagars mars 2026, 100-dagars mars 2027, 47-dagars mars 2029) till interna efterlevnadsmilstolpar för justering av CAA-postrevisionens kadens.
CISO: er	Domäner utan CAA-poster exponeras för certifikatutfärdande av vilken som helst av de över 100 offentligt betrodda CA:erna; ett bedrägligt utfärdat certifikat som möjliggör en MITM-attack eller varumärkesimitation producerar den typ av intrång som når styrelsen; CAA-poster är en av de enklaste och billigaste förebyggande kontrollerna i PKI-säkerhetsverktygslådan; CA/B Forum SC-081v3-giltighetsreduceringsschemat innebär att CAA-postunderhåll skalas upp med förnyelsefrekvensen, vilket gör korrekta CAA-poster till ett växande operativt krav i takt med att certifikatens livslängd krymper mot 47 dagar.	Kräv att varje externt upplösbar domän har en CAA-post som en grundläggande säkerhetsstandard; finansiera certifikatidentifierings- och CLM-programmet som behövs för att upprätthålla korrekta CAA-poster allt eftersom certifikattillgången och CA-relationerna utvecklas; utvärdera PKI som en tjänst för privat PKI-infrastruktur där intern CA-användning måste spåras tillsammans med offentlig CA-användning i CAA-register; kräva att CAA-registertäckning och noggrannhet rapporteras som nyckeltal på styrelsenivå kvartalsvis tillsammans med övervakning av certifikatutgångsdatum

Vad är en CAA-post?

En Certification Authority (CAA) -post är en DNS-resurspost, standardiserad enligt RFC 6844 och uppdaterad av RFC 8659, som talar om för världen vilka certifikatutfärdare (CA:er) som har tillstånd att utfärda SSL/TLS-certifikat för din domän eller underdomän. Du kan tänka på det som en enkel regel inskriven i din DNS som instruerar alla certifikatutfärdare att kontrollera behörigheter innan de utfärdar ett certifikat.

En grundläggande CAA-post ser ut så här:

Den här posten anger för varje CA: endast Let's Encrypt får utfärda certifikat för example.com. Alla andra CA som får en certifikatförfrågan för den domänen måste enligt CA/Browser Forum Baseline Requirements kontrollera om det finns CAA-poster och följa reglerna, eller vägra att utfärda. CAA-poster följer också DNS-hierarkin. Om en underdomän inte har en egen CAA-post kommer CA att titta på den överordnade domänen och tillämpa dessa regler istället, vilket gör det enkelt att hantera policyer över ett stort antal domäner.

Hur CAA-poster definierar auktoriserade certifikatutfärdare

CAA-poster fungerar genom att koppla specifika CA-identifierare till din domän i DNS. När en CA får en begäran om att utfärda ett certifikat söker den upp CAA-poster för den domänen. Om en CAA-post finns och CA:n inte finns med i listan måste den vägra. Om ingen CAA-post finns alls kan vilken CA som helst utfärda certifikat för din domän, vilket är den typ av öppen dörr som säkerhetsteam behöver stänga.

Du kan lista mer än en CA i dina CAA-poster. Detta är användbart för organisationer som använder olika CA:er för olika ändamål, till exempel en offentlig CA för kundvända tjänster och en privat CA för interna system. Varje auktoriserad CA får sin egen CAA-post, och CA:n måste matcha minst en post för att fortsätta med certifikatutfärdandet.

Förstå problemet, issuewild och iodef-taggar

CAA-poster använder tre huvudsakliga egenskapstaggar för att kontrollera certifikatutfärdande. Varje tagg gör något annorlunda, och det är viktigt att förstå alla tre för att konfigurera dina poster korrekt.

Problem: Den här taggen anger vilken certifikatutfärdare som har tillstånd att utfärda standardcertifikat för din domän. Till exempel ger 0 problem ”digicert.com” DigiCert tillstånd att utfärda certifikat för den domänen.

Issuewild: Den här taggen styr vilka certifikatutfärdare som kan utfärda jokerteckenscertifikat , till exempel *.example.com . Detta är separat från issue-taggen, så du kan ha en mer öppen policy för standardcertifikat men en striktare för jokerteckenscertifikat, beroende på dina säkerhetsbehov.

Iodef: Den här taggen anger vart certifikatutfärdare ska skicka en rapport om de får en certifikatförfrågan som bryter mot er policy. Ni kan peka den till en e-postadress eller en URL, så här:

0 iodef "mailto:[email protected]"

En sak att se upp för: om du bara anger en issuewild-tagg utan en issue-tagg kan vilken CA som helst fortfarande utfärda standardcertifikat för din domän. De två taggarna är oberoende av varandra, så konfigurera alltid båda för att säkerställa att din policy är komplett.

CAA-taggreferens: issue, issuewild och iodef

Använd den här tabellen som en snabbreferens när du konfigurerar eller granskar CAA-poster. Varje rad beskriver vad taggen styr, ett exempel på syntax, när den ska användas och felläget om den utelämnas eller är felkonfigurerad. Alla tre taggar bör granskas kvartalsvis mot den aktuella certifikat-till-CA-mappningen från CLM-inventeringen.

tagg	Vad den kontrollerar	Exempelsyntax	När ska du använda	Felläge om utelämnat eller felkonfigurerat
fråga	Vilka certifikatutfärdare får utfärda standard SSL/TLS-certifikat (ej jokertecken) för domänen? Flera utfärdandeposter är tillåtna, en per auktoriserad certifikatutfärdare. Om värdet anges till en tom sträng (0 utfärda "") förhindras alla certifikatutfärdare från att utfärda standardcertifikat.	0 nummer “digicert.com” 0 nummer “letsencrypt.org”	Alltid. Varje domän bör ha minst en ärendetagg som uttryckligen listar alla CA som är behöriga att utfärda standardcertifikat för den domänen. Utan denna tagg kan vilken CA som helst utfärda standardcertifikat oavsett om andra taggar finns.	Utelämnat: vilken CA som helst kan utfärda standardcertifikat. Listar fel CA: förnyelse misslyckas när den aktiva CA kontrollerar CAA-posten och upptäcker att den inte är listad; vid 47 dagars giltighetstid orsakar detta förnyelsemisslyckanden cirka 8 gånger per år per påverkat certifikat.
utgivningsvild	Vilka CA:er får utfärda jokerteckens SSL/TLS-certifikat (*.domain.com) för domänen. Oberoende av issuewild-taggen. Om issuewild saknas, faller utfärdandet av jokerteckenscertifikat tillbaka till issuetaggens begränsningar.	0 issuewild “digicert.com” 0 issuewild “” (blockerar all utfärdande av jokertecken)	Alla domäner för vilka jokerteckenscertifikat har utfärdats eller kan utfärdas. Ställ in detta explicit för att antingen auktorisera specifika certifikatutfärdare för utfärdande av jokertecken eller helt förbjuda utfärdande av jokertecken (0 issuewild “”) för domäner som inte kräver jokertecken.	Utelämnat: utfärdandet av jokertecken faller tillbaka på ärendetaggen, vilket kan vara mer tillåtande än avsett. Felkonfigurerat (listar CA som inte används för jokertecken): förnyelse av jokertecken misslyckas. Att inte ställa in issuewild när issuewild inte behövs är acceptabelt om kontrollerna för ärendetaggen är tillräckliga.
jod	Vart CA:er ska skicka en rapport när de tar emot en begäran om certifikatutfärdande som bryter mot domänens CAA-policy. Accepterar en e-postadress (mailto:) eller en URL-slutpunkt. Blockerar inte utfärdandet; ger endast aviseringar.	0 iodef “mailto:[e-postskyddad]" 0 iodef “https://example.com/caa-report”	Alla domäner med issue- eller issuewild-poster. Iodef-taggen är den anmälningsmekanism som gör att CAA:s policytillämpning kan observeras. Utan den är policyöverträdelser tysta: CA vägrar men domänägaren meddelas aldrig.	Utelämnad: policyöverträdelser är tysta; ingen avisering skickas när en obehörig certifikatutfärdare tar emot en certifikatbegäran för domänen. Slutpunkt övervakas inte: aviseringar anländer men ingen agerar utifrån dem, vilket eliminerar iodef-taggens operativa värde.

Varför CAA-poster är viktiga för domänsäkerhet

Obehörig certifikatutfärdande är ett verkligt problem. Oavsett om det sker genom social ingenjörskonst, ett misstag hos certifikatutfärdaren eller ett komprometterat system, har certifikat felaktigt utfärdats för välkända domäner. När det händer kan angripare fånga upp krypterad trafik, köra man-in-the-middle-attacker eller låtsas vara legitima tjänster.

CAA-register förhindrar inte alla möjliga attacker, eftersom de är beroende av att CA:er kontrollerar och följer dem, och efterlevnaden styrs av CA/Browser Forum. Men sedan september 2017 är alla offentligt betrodda CA:er skyldiga enligt CA/Browser Forum Baseline Requirements att kontrollera CAA-register innan de utfärdar. En CA som ignorerar detta riskerar att förlora sin status som betrodd, vilket är en allvarlig konsekvens.

CAA-register stöder också regelefterlevnad. Enligt ramverk som SOC 2, ISO 27001 och PCI DSS är det en solid och dokumenterbar säkerhetskontroll att kunna visa att du kontrollerar vilka CA:er som utfärdar certifikat för din domän. Det hjälper vid revisioner och visar att din organisation hanterar domänsäkerheten korrekt.

Hur certifikatutfärdare validerar CAA-poster

När en CA tar emot en certifikatförfrågan kör den en DNS-sökning efter CAA-poster på det fullständigt kvalificerade domännamnet (FQDN) i begäran. Om poster hittas och CA inte finns med i listan vägrar den att utfärda certifikatet. Om DNS-frågan misslyckas på grund av ett SERVFAIL, timeout eller felkonfiguration måste CA också vägra. Denna felsäkra metod innebär att en trasig installation skyddar dig snarare än att du blir exponerad.

DNSSEC lägger till ytterligare ett skyddslager här. Utan DNSSEC kan CAA-poster förfalskas genom DNS-cacheförgiftning, där en angripare infogar falska poster som gör det möjligt för deras valda CA att utfärda ett certifikat. När dina DNS-zoner är signerade med DNSSEC garanteras noggrannheten och integriteten hos dina CAA-poster på kryptografisk nivå.

Om ingen CAA-post finns för ett specifikt FQDN, går CA:n upp i DNS-trädet till den överordnade domänen, sedan den överordnade, tills den hittar en. Det betyder att en enda CAA-post på din apex-domän kan täcka hela ditt domännamnsområde, vilket är ett mycket effektivt sätt att tillämpa policyer i stor skala.

CAA-konfiguration: Krav, fellägen och övervakningssignaler

Använd den här tabellen för att mappa varje CAA-konfigurationskrav till dess valideringsmetod, felläget när kravet inte uppfylls, övervakningssignalen som visar felet och den auktoritativa policykällan. CAA-poster och CA/Browser Forum-baskraven granskas kvartalsvis och kan uppdateras oberoende.

Krav	Valideringsmetod	Feltillstånd	Övervakningssignal	Policykälla
CAA-poster finns för varje externt matchningsbar domän	DNS-sökning (se TYPE257 domain.com eller CAA domain.com); MX Toolbox CAA-kontroll; SSLMate CAA Record Generator; CLM-plattformens domängranskning	Ingen CAA-post: vilken offentligt betrodd CA som helst kan utfärda certifikat för domänen; obehörig utfärdande upptäcks inte förrän en CT-loggövervakare eller iodef-rapport visar det.	CLM-plattformens domängranskning som visar domäner utan CAA-poster; CT-loggövervakningsvarning för oväntat certifikat utfärdat för en oskyddad domän	RFC 6844 (CAA-standard); RFC 8659 (CAA-uppdatering); CA/Browser Forum Baseline Requirements Avsnitt 3.2.2.8 (CAA-kontrollmandat, gäller från september 2017)
Taggarna issue och issuewild matchar alla CA:er som aktivt utfärdar för domänen.	Jämför CLM-certifikatinventeringen (vilken CA som utfärdat varje certifikat för varje domän) med de CA:er som listas i CAA-posten för den domänen; bekräfta att alla aktiva CA:er listas; testa genom att begära en certifikatförnyelse via varje auktoriserad CA och bekräfta att CAA-kontrollen är godkänd.	CAA-posten utelämnar en aktiv CA: certifikatförnyelse misslyckas vid CA:s CAA-kontroll; vid maximal giltighetstid på 47 dagar (SC-081v3, mars 2029) orsakar detta förnyelsemisslyckanden cirka 8 gånger per år per påverkat certifikat; misslyckandet visas som ett CA-avslagsfel snarare än en utgångsvarning.	Aviseringar om misslyckade certifikatförnyelser i CLM-plattformen korrelerade med CAA-sökningsfel; CA-felsvar som hänvisar till CAA-policy under förnyelse; CLM-inventeringsjämförelse som visar CA-avvikelse mellan certifikatutfärdare och CAA-postinnehåll	RFC 6844 Avsnitt 4 (CAA-egenskapstaggar); CA/Browser Forum Baseline Requirements Avsnitt 3.2.2.8; CA/B Forum SC-081v3 (godkänd april 2025) för kontext för förnyelsefrekvens
iodef-slutpunkten är konfigurerad och övervakad	Bekräfta att iodef-taggen finns i CAA-posten för alla domäner; testa att iodef-slutpunkten är nåbar och korrekt formaterad; bekräfta att iodef-rapporter dirigeras till SIEM eller ärendesystem och granskas inom definierat SLA; observera: inte alla CA:er implementerar iodef-rapportering; bekräfta iodef-stöd med varje auktoriserad CA	Iodef-tagg saknas: policyöverträdelser är tysta; en obehörig certifikatutfärdare tar emot en certifikatbegäran men domänägaren meddelas aldrig; överträdelsen kan endast upptäckas via CT-loggövervakning. Iodef-slutpunkten övervakas inte: meddelanden kommer in men ingen agerar utifrån dem	SIEM- eller ärendesystemavisering om ny mottagen iodef-rapport; lucka i iodef-rapportgranskningsloggen identifierad under kvartalsvis revision; CT-loggövervakningsvarning för oväntat certifikat som borde ha utlöst en iodef-rapport	RFC 6844 avsnitt 5.4 (iodef-egenskapstagg); CA/Browser Forum-grundkrav avsnitt 3.2.2.8
DNSSEC signerad för alla domäner med CAA-poster	Extern DNSSEC-validerare (DNSViz, Verisign DNSSEC Analyzer); bekräfta att AD-flaggan är satt på CAA-postsvar från DNSSEC-validerande resolvers; bekräfta att RRSIG-poster finns och inte har utgångit för zonen.	Ingen DNSSEC: CAA-poster är sårbara för DNS-cacheförgiftning; en angripare kan infoga falska CAA-poster som godkänner att deras valda CA utfärdar ett bedrägligt certifikat; CAA-posten tillhandahåller endast policytillämpning mot ärliga CA:er, inte mot aktiva angripare som manipulerar DNS.	DNSSEC-valideringsfel från externa validerare; AD-flagga inte satt på CAA-postens DNS-svar; RRSIG-utgångsvarningar från DNS-övervakning; certifikat utfärdat för en domän med en förfalskad CAA-post (upptäckt via CT-loggövervakning)	RFC 4033-4035 (DNSSEC); RFC 6844 avsnitt 3 (rekommenderar DNSSEC för CAA); NIST SP 800-81-2 (DNSSEC-distributionsriktlinjer)
CAA-register uppdateras när CA-relationer ändras	Bekräfta att onboarding- och offboarding-processer för CA inkluderar ett steg för uppdatering av CAA-poster; granska CAA-poster mot den aktuella mappningen mellan certifikat och CA varje kvartal; testa förnyelse genom alla CA som lagts till eller tagits bort sedan den senaste granskningen för att bekräfta att CAA-posterna är korrekta.	CAA-posten listar en CA som inte längre används: inget omedelbart fel men onödig exponering för auktoriserad utfärdare kvarstår. CAA-posten listar inte en nyligen ombordansluten CA: certifikatförnyelser misslyckas omedelbart för alla certifikat som migreras till den nya CA:n	Aviseringar om misslyckade certifikatförnyelser i CLM-plattformen under CA-migrering; CLM-inventeringsjämförelse som visar att nyligen ombordförda CA inte listas i CAA-posten; kvartalsvis CAA-revision som identifierar inaktuella CA-poster i CAA-poster för domäner där den CA:n inte längre utfärdar	RFC 8659 Avsnitt 4 (underhåll av CAA-register); CA/Browser Forum Baseline Requirements Avsnitt 3.2.2.8; intern CA-policy för onboarding och offboarding av ändringar

Bästa praxis för att konfigurera och hantera CAA-poster

Att skapa CAA-register är enkelt, men att göra det på rätt sätt kräver lite planering. Här är de viktigaste metoderna att följa:

• Granska först ditt certifikatlager: Innan du lägger till CAA-poster, ta reda på vilka CA:er som redan utfärdar certifikat för dina domäner. Verktyg som crt.sh kan hjälpa dig med detta. Om du begränsar utfärdandet till en CA som du inte faktiskt använder kommer certifikatförnyelser att misslyckas.
• Ställ in både issue- och issuewild-taggarna explicit: Anta inte att det ena täcker det andra. Var tydlig med vilka CA:er som kan utfärda standard- och wildcard-certifikat och för register över varför varje CA är auktoriserad.
• Lägg till en iodef-tagg och övervaka den faktiskt: Rapporter hjälper bara om någon läser dem. Anslut din iodef-slutpunkt till ditt säkerhetsteams ärendesystem eller SIEM och ta alla överträdelsemeddelanden på allvar.
• Använd CAA-poster tillsammans med DNSSEC: DNSSEC säkerställer att er CAA-policy inte kan förfalskas på DNS-nivå. Om era zoner ännu inte är DNSSEC-signerade är detta en bra anledning att komma igång.
• Testa dina CAA-register efter publicering: Använd verktyg som dig, SSLMate CAA Record Generator eller MX Toolbox för att kontrollera att dina poster tolkas korrekt från flera platser.
• Uppdatera CAA-poster när dina CA-relationer ändras: Varje gång du byter CA, skriver kontrakt med en ny leverantör eller går igenom en sammanslagning, uppdatera dina CAA-register så att de matchar. Föråldrade register kan vara lika riskabla som saknade register.

Hur krypteringskonsulting kan hjälpa

Att korrekt konfigurera CAA-poster börjar med att veta exakt vilka certifikatutfärdare som redan utfärdar certifikat för dina domäner. Utan den inventeringen riskerar du att låsa ute en certifikatutfärdare som aktivt förnyar certifikat, vilket orsakar avbrott i det ögonblick en förnyelse misslyckas. Det är den granskningen som de flesta organisationer kör fast, och det är där CertSecure Manager gör störst skillnad.

CertSecure Manager är Encryption Consultings plattform för hantering av certifikatlivscykeln. Den ger ditt team en komplett, kontinuerligt uppdaterad inventering av alla SSL/TLS-certifikat i din miljö, inklusive vilken CA som utfärdat varje certifikat, när det löper ut och var det distribueras. Den insynen är precis vad ni behöver innan ni skriver en enda CAA-post. För fullständig insyn i kryptografisk egendom utöver certifikat utökar CBOM Secure identifieringen till algoritmer, nycklar och kryptografiska beroenden i moln-, lokala och hybridmiljöer.

Så här hanterar CertSecure Manager var och en av dessa utmaningar:

Certifikatupptäckt och inventering: Vår CertSecure Manager skannar ditt nätverk och dina molnmiljöer för att identifiera alla certifikat som används, oavsett vilken CA som utfärdat det. Innan du begränsar utfärdandet via CAA-poster måste du veta vad som redan finns tillgängligt. Den hanterar det steget automatiskt.

Spårning av CA-relationer: Eftersom din CAA-policy bara är så exakt som din kunskap om vilka CA:er du faktiskt använder, håller CertSecure Manager ditt certifikatregister aktuellt så att dina CAA-poster förblir i linje med verkligheten, även när din miljö växer eller dina CA-relationer förändras.

Automatisering av förnyelse: När dina CAA-poster är på plats kommer alla certifikatförnyelser som går till en obehörig CA att misslyckas. CertSecure Manager automatiserar förnyelser via dina auktoriserade CA:er, så det finns inga överraskningar i sista minuten när ett certifikat snart löper ut.

Revisionslogg för efterlevnad: För ramverk som SOC 2, ISO 27001 och PCI DSS är möjligheten att visa kontroll över certifikatutfärdande en dokumenterbar säkerhetskontroll. CertSecure Manager loggar varje certifikathändelse, vilket ger ditt efterlevnadsteam de bevis de behöver.

CAA-poster ger dig policyer. CertSecure Manager ger dig insyn och automatisering för att se till att policyn fungerar konsekvent i hela din certifikatmiljö. För organisationer som bygger eller utökar privat PKI-infrastruktur tillhandahåller PKI as a Service en fullständigt hanterad CA-hierarki där intern CA-användning integreras snyggt med CAA-poststyrning. För planering efter kvantmigrering av DNSSEC-zonsigneringsalgoritmer som används tillsammans med CAA, spåra kraven genom PQC Center of Excellence.

Slutsats

CAA-poster är lätta att missa eftersom de arbetar tyst i bakgrunden, men att lämna dem utanför skapar en verklig säkerhetsbrist. Eftersom felaktig certifikatutfärdande fortsätter att vara en risk över hela internet måste domänägare ta kontroll över vem som kan utfärda certifikat för deras räkning. CAA-poster ger dig den kontrollen på ett enkelt, standardiserat sätt.

När CAA-poster är korrekt konfigurerade och kopplade till DNSSEC, en övervakad iodef-slutpunkt och en gedigen certifikathanteringsprocess blir de en meningsfull del av din PKI-strategi. De är inte svåra att implementera, men de behöver hållas uppdaterade allt eftersom din miljö förändras.

Denna guide granskas kvartalsvis och omedelbart när CA/Browser Forum uppdaterar sina CAA-kontrollregler för baselinekrav eller introducerar nya CAA-egenskapstaggar.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från CAA Records Explained: Defining Which Certificate Authorities Can Delivery for Your Domain (CAA Records Explained: Defining Which Certificate Authorities Can Delivery for Your Domain)?

CAA-poster är en DNS-utgivningskontroll (RFC 6844, uppdaterad RFC 8659) som begränsar vilka certifikatutfärdare som kan utfärda SSL/TLS-certifikat för din domän, vilket upprätthålls av CA/Browser Forum Baseline Requirements sedan september 2017. En domän utan CAA-poster tillåter alla offentligt betrodda CA att utfärda certifikat för den. Tre taggar kontrollerar utfärdandet: issue (standardcertifikat), issuewild (jokerteckencertifikat) och iodef (rapportering av överträdelser). DNSSEC skyddar CAA-poster från förfalskning. Taggarna issue och issuewild är oberoende av varandra; om den ena anges utan den andra lämnar du halva certifikatnamnrymden okontrollerad.

Varför är CAA-register viktiga för PKI-team på företag?

Företags-PKI-team står inför två CAA-relaterade risker. En domän utan CAA-poster är öppen för certifikatutfärdande av vilken som helst av de över 100 offentligt betrodda CA:erna, varav vilken som helst kan komprometteras eller tvingas fram. DigiCert Trust Pulse Survey (2 juli 2025) fann att 45 procent av företagen upplevde certifikatrelaterade driftstopp; felkonfigurerade CAA-poster som utelämnar en aktiv CA orsakar förnyelsemisslyckanden, vilket ger just den driftstoppen. Vid 47 dagars maximal TLS-giltighet från mars 2029 (CA/B Forum SC-081v3, godkänd april 2025) orsakar en felkonfigurerad CAA-post förnyelsemisslyckanden ungefär åtta gånger per år per påverkat certifikat.

Vilka risker ökar om CAA-poster inte konfigureras eller hanteras manuellt?

Tre riskkategorier ökar: exponering för öppen utfärdande (utan CAA-poster kan vilken offentligt betrodd CA som helst utfärda certifikat för domänen); felkonfiguration som blockerar förnyelser (en CAA-post som utelämnar en aktiv CA orsakar förnyelsefel, åtta gånger per år med 47 dagars giltighetstid); och wildcard-gap (konfigurering av issue utan issuewild, eller issuewild utan issue, lämnar hälften av certifikatnamnrymden okontrollerad).

Vilka team bör äga konfiguration och underhåll av CAA-poster?

DNS- och infrastrukturteam äger publiceringen av CAA-poster och DNSSEC-underhållet. PKI- och certifikatteam äger mappningen mellan certifikat och CA som avgör vilka CA:er som måste listas. Säkerhetsarkitekter äger styrningsmodellen: policy för issue versus issuewild, övervakning av iodef-slutpunkter och handlingsplan för svar på obehöriga utfärdanden. Compliance-team äger revisionsbevisen som bekräftar att CAA-poster är närvarande, korrekta och aktuella för alla domäner inom scopet.

Hur kopplas CAA-poster till hantering av certifikatlivscykeln?

CAA-poster är ett livscykelberoende: varje certifikatförnyelse utlöser en CAA-sökning hos den utfärdande CA:n. En CAA-post som utelämnar den förnyande CA:n gör att förnyelsen misslyckas. CertSecure Manager tillhandahåller den certifikatinventering som behövs för att bekräfta vilka CA:er som måste listas innan CAA-poster publiceras och automatiserar förnyelser genom auktoriserade CA:er så att CAA-avvikelser inte orsakar avbrott.

Hur bör organisationer mäta framgång med implementeringen av CAA-register?

Viktiga mätvärden: 100 procent av organisationsägda domäner med CAA-poster; 100 procent av CAA-posterna matchar den aktuella certifikat-till-CA-mappningen från CLM-inventeringen; noll misslyckade certifikatförnyelser som kan hänföras till felaktig CAA-konfiguration; iodef-rapporter granskade inom definierat SLA (mål: 100 procent inom 24 timmar); och DNSSEC-signeringstäckning för 100 procent av domänerna med CAA-poster.

Vad bör granskas eller övervakas regelbundet?

Övervaka kontinuerligt: ​​iodef-rapporter från alla auktoriserade certifikatutfärdare med automatiska aviseringar; händelser vid misslyckad certifikatförnyelse som korrelerar med CAA-sökningsfel. Granska kvartalsvis: CAA-postnärvaro för alla organisationsägda domäner; CAA-postens noggrannhet mot den aktuella certifikat-till-CA-mappningen; DNSSEC-signeringsstatus för alla domäner med CAA-poster; och CA/B-forumets baslinjekrav för eventuella CAA-relaterade uppdateringar.

Hur påverkar CAA-poster moln-, hybrid- eller multi-CA PKI-miljöer?

Det är i miljöer med flera CA-konton som CAA-poster blir som mest komplexa: varje domän kan ha flera auktoriserade CA:er (publik CA för kundvänd TLS, privat CA för interna tjänster, molnleverantörs-CA för molnbaserade arbetsbelastningar), och CAA-posten måste lista alla korrekt. Molnprovisionerade underdomäner som inte finns i DNS-inventeringen skapar täckningsgap. En CLM-plattform med identifiering mellan olika miljöer är en förutsättning för korrekta CAA-poster över en multi-CA och en multi-moln-egendom.

Vilka vanliga misstag bör team undvika?

De vanligaste misstagen: publicering av CAA-poster innan granskning av vilka CA:er som aktivt utfärdar (orsakar förnyelsefel om en aktiv CA utelämnas); sättning av issuewild utan att även sätta issue (lämnar standardcertifikatutfärdande öppen för alla CA); att inte inkludera alla CA:er som används över underdomäner; att inte konfigurera DNSSEC (lämnar CAA-poster sårbara för DNS-cacheförgiftning); och att inte övervaka iodef-rapporter (eliminerar aviseringsvärdet för iodef-taggen).

Vad bör uppdateras kvartalsvis?

Kvartalsvis: jämför CAA-poster med den nuvarande certifikat-till-CA-mappningen från CLM-inventeringen; bekräfta att DNSSEC signerar alla domäner med CAA-poster; granska iodef-rapporter från föregående kvartal; bekräfta att nya domäner som lagts till sedan den senaste revisionen har CAA-poster; och verifiera att CA/B Forum Baseline Requirements inte har infört nya CAA-kontrollregler. För planering av DNSSEC-algoritmmigrering efter kvantum, kontrollera PQC Center of Excellence . Detta inlägg granskas kvartalsvis.