Varje webbplats du besöker är beroende av ett SSL/TLS-certifikat för att hålla din anslutning säker. Men vem bestämmer vilka företag som får utfärda dessa certifikat för en viss webbplats? Det är precis vad en CAA-post gör.
En Certification Authority Authorization (CAA)-post är en liten post i din domäns DNS. Den talar om för certifikatutfärdande företag, så kallade certifikatutfärdare eller CA:er , vilka av dem som har tillstånd att utfärda certifikat för din domän. Utan den skulle vilken betrodd CA som helst i världen kunna utfärda ett certifikat för din webbplats, och du kanske inte får reda på det förrän något går fel.
CAA-poster spelar större roll än tidigare eftersom de nu avgör om ett certifikat utfärdas överhuvudtaget, inte bara vilken CA som får utfärda det. Under 2025 och 2026 gjorde två viktiga förändringar CAA-poster mycket kraftfullare. En regel som kallas Multi-Perspective Issuance Corroboration (MPIC) innebär att CA:er nu kontrollerar dina poster från flera platser samtidigt, och från och med mars 2026 måste de även kontrollera Domain Name System Security Extensions (DNSSEC)-signaturer för alla domäner som använder DNSSEC.
Resultatet är enkelt. En felkonfigurerad CAA-post försvagar inte längre bara din säkerhetspolicy, den kan också hindra ditt certifikat från att utfärdas överhuvudtaget. Det omfattar nu två separata fel: ett policyfel som blockerar din egen CA och ett DNS- eller DNSSEC-fel som avbryter sökningen.
Den här bloggen förklarar vad CAA-poster är, hur de nya reglerna fungerar och vad du behöver göra rätt för att undvika certifikatfel. Låt oss börja med grunderna.
Vad är en CAA-post och varför den är viktig
En CAA-post finns i din domäns DNS ; samma system som mappar ditt domännamn till serverns IP-adress och lagrar andra policyposter. Istället för att peka på en serveradress pekar den på en policy: vilka CA:er som har tillstånd att utfärda certifikat för din domän.
Innan CAA blev obligatoriskt för alla offentliga CA:er år 2017 kunde vilken CA som helst utfärda ett certifikat för vilken domän som helst så länge begäran klarade en grundläggande ägarkontroll. Det var riskabelt. En CA som gjorde ett misstag, eller en dålig aktör, kunde få ett giltigt certifikat för din domän utan din vetskap, och webbläsare skulle lita på det precis som det riktiga.
CAA åtgärdar detta genom att lägga till en gatekeeper på DNS-nivå. När en CA får en begäran om att utfärda ett certifikat för din domän kontrollerar den först dina CAA-poster. Om den CA:n inte finns på din lista över godkända certifikat måste den vägra, oavsett vad begäran mer innehåller.
Detta gör CAA till en av de billigaste säkerhetskontrollerna du kan lägga till. En CAA-post är bara en DNS-post, så den kostar ingenting, men den avgör vem som kan utfärda certifikat åt dig. Trots detta är användningen fortfarande låg. I mitten av 2024 hade endast cirka 15 procent av de främsta TLS-webbplatserna CAA-poster på plats, vilket innebär att de flesta organisationer inte använder detta skydd alls.
För att använda CAA väl är det bra att förstå de få enkla taggar som utgör en post.
De viktigaste CAA-taggarna du behöver känna till
En CAA-post har tre delar: en flagga, en tagg och ett värde. Flaggan är nästan alltid noll, vilket innebär att CA kan fortsätta även om den inte känner igen taggen. Det enda standardiserade värdet som inte är noll och som för närvarande används är 128, den issuer-kritiska flaggan, vilket tvingar CA att vägra utfärdande om den inte kan förstå taggen. Taggen anger vilken typ av regel posten anger, och värdet är den faktiska instruktionen. Det finns fyra taggar som du kommer att använda oftast.
Issue-taggen anger vilken CA som har tillstånd att utfärda vanliga certifikat för din domän. Du anger CA:ns officiella domännamn som värde. I det ögonblick du namnger en CA med en issue-post blockeras alla andra CA:er automatiskt, så det finns ingen separat nekanderegel att lägga till. Om du arbetar med mer än en CA lägger du till en issue-post för varje, och alla förblir auktoriserade.
Taggen issuewild styr auktorisering för jokerteckencertifikat . Om en issuewild-post finns åsidosätter den issue-taggen endast för jokerteckencertifikat. Om ingen issuewild-post finns gäller issue-taggen för både vanliga certifikat och jokerteckencertifikat. iodef-taggen anger för certifikatutfärdare vart de ska skicka en avisering när någons certifikatförfrågan blockeras av din policy. Du kan ange en e-postadress eller en webbadress.
Tänk på det som ett tidigt varningssystem. Utan det försvinner ett blockerat försök helt enkelt, och du får aldrig veta att det har hänt. Det är gratis, tar mindre än en minut att installera och de flesta större certifikatutfärdare stöder det. Observera att stödet för iodef varierar. Alla certifikatutfärdare skickar inte dessa rapporter på ett tillförlitligt sätt, så behandla det som en kompletterande signal snarare än din primära varningsmekanism.
Det finns också en fjärde tagg, issuemail, som lades till 2023. Den fungerar precis som issue men gäller S/MIME-certifikat som används för säker e-post. Om din organisation använder S/MIME är det värt att lägga till den också.
Dessa taggar ger dig kontroll över vem som kan utfärda certifikat och hur du varnas när din policy tillämpas. Den kontrollen är ännu viktigare nu, på grund av hur certifikatutfärdare nyligen har ändrat hur de kontrollerar dessa poster.
Vad som förändrades under 2025 och 2026: MPIC och DNSSEC
Fram till 2025 kontrollerade en CA dina CAA-poster från en enda plats. Det låter bra, men det lämnade ett gap. DNS-svar kan förfalskas, till exempel genom BGP-kapning, där internets routing manipuleras för att skicka en CA:s sökningar till angriparkontrollerade servrar som returnerar falska svar. Från en plats kan en CA inte enkelt skilja ett riktigt svar från ett förfalskat. Detta är inte bara teori. År 2018 omdirigerade en BGP-kapning hos en uppströms leverantör trafik avsedd för Amazon Route 53:s DNS-servrar (Amazons egna system komprometterades inte), vilket omdirigerade en kryptovalutaplattforms användare till en bedräglig webbplats och orsakade förluster på mer än 150 000 dollar.
MPIC skapades för att täppa till denna lucka. Dess tillämpning började i hela branschen den 15 september 2025, och det minsta antalet fjärrperspektiv som krävs ökar i faser fram till 2026 och stiger till fyra den 15 juni 2026. Istället för att kontrollera från ett ställe kontrollerar CA:er nu dina CAA-poster från flera nätverksplatser runt om i världen samtidigt. Om alla överensstämmer godkänns kontrollen. Om någon plats returnerar ett annat svar misslyckas kontrollen och inget certifikat utfärdas.
Att förfalska ett DNS-svar är möjligt, men att förfalska samma svar från fyra eller fler oberoende platser samtidigt är mycket svårare. Från och med mars 2026 måste CA:er bekräfta dina poster från minst tre fjärrnätverksperspektiv plus ett primärt perspektiv, alla spridda över minst två distinkta regionala internetregistreringsregioner (RIR), innan de utfärdar ett certifikat.
Den andra ändringen lägger till DNSSEC. MPIC bekräftar att svaren är konsekventa, men det bevisar inte att de är äkta. DNSSEC lägger till kryptografiska signaturer till DNS-poster, vilket gör det möjligt för resolvers att verifiera att DNS-svar är autentiska och inte har manipulerats. Det skyddar mot attacker som DNS-förfalskning och cacheförgiftning.
Från och med den 15 mars 2026 kräver en CA/Browser Forum -regel (Ballot SC-085v2) att CA:er validerar DNSSEC-signaturer när de utför CAA- eller domänkontrollsökningar för en DNSSEC-aktiverad domän. Om din DNSSEC-konfiguration är trasig, med utgångna signaturer eller en ofullständig nyckeländring, kommer din CAA-kontroll att misslyckas och ditt certifikat kommer inte att utfärdas. Om du inte använder DNSSEC påverkar inte denna specifika ändring dig, men det är fortfarande värt att överväga som en del av din bredare DNS-säkerhet.
På grund av dessa ändringar ser stegen som en certifikatutfärdare nu följer innan de utfärdar ett certifikat ut så här:
- CA tar emot en certifikatbegäran för din domän.
- Med hjälp av MPIC söker den upp dina CAA-poster från flera oberoende platser världen över, och om dessa platser inte stämmer överens blockeras utfärdandet.
- Som en del av samma sökning validerar den DNSSEC-signaturer på alla DNSSEC-aktiverade domäner, och om en signatur är trasig eller saknas blockeras utfärdandet.
- Den kontrollerar om den visas i din CAA-post som en godkänd utfärdare, och om den inte visas måste den vägra.
- Den kontrollerar eventuella extra regler, såsom begränsningar för konton eller valideringsmetoder.
- Slutligen bekräftar det att du faktiskt kontrollerar domänen innan du fortsätter.
- Certifikatet är utfärdat.
De flesta problem med utfärdande beror på några undvikbara misstag någonstans i processen. Här är de man bör hålla utkik efter.
Undvika misstag och följa CAA:s bästa praxis
En handfull återkommande misstag orsakar de flesta CAA-misslyckanden, och alla är lätta att förhindra när man väl känner till dem.
Det första är att issuewild saknas när du utfärdar jokercertifikat. Om du bara har en ärendepost och sedan försöker hämta ett jokercertifikat kommer det att blockeras. Många team skapar ärendeposter tidigt och lägger sedan till jokercertifikat senare utan att uppdatera sin policy.
Det andra är att du använder fel CA-namn. Värdet i din post måste vara CA:s officiella domännamn, inte en återförsäljare eller partner. Om du köper certifikat via en återförsäljare behöver du fortfarande den underliggande CA:ns identifierare, så kontrollera deras dokumentation för exakt vilken text som ska användas.
Det tredje är DNS som inte kan nås från det publika internet. Eftersom MPIC kontrollerar från flera externa platser måste dina auktoritativa namnservrar vara nåbara externt. Detta orsakar ofta problem för hybridmolnskonfigurationer där en del av DNS:en hålls intern.
Det fjärde är trasig DNSSEC, som nu blockerar utfärdande helt från och med mars 2026. De vanliga orsakerna är utgångna signaturer och ofullständiga nyckeländringar. Övervaka din DNSSEC-hälsa och ställ in varningar i god tid innan signaturer löper ut.
Det täcker de misstag som bör undvikas. Utöver dem finns det några goda vanor som håller CAA igång medan du växer. Innan du skriver några poster, kontrollera loggarna för certifikattransparens för att se vilka CA:er som redan utfärdar för dina domäner, så att du inte av misstag låser en. Lägg till CAA-poster automatiskt när en ny domän eller underdomän skapas, så att utfärdandet aldrig misslyckas på grund av att en post glömts bort. Detta är viktigare för varje år, eftersom certifikatens livslängd redan är nere på 200 dagar i mars 2026, på väg till 100 dagar i mars 2027 och bara 47 dagar i mars 2029, vilket innebär mycket mer frekventa förnyelser och mycket mindre utrymme för tysta felkonfigurationer.
Att få allt detta rätt inom många områden kräver rätt verktyg och erfarenhet, och det är där vi kan hjälpa till.
Hur krypteringskonsulting kan hjälpa
CAA-poster är enkla i sig men svårare att hantera i stor skala. Att välja rätt CA-identifierare, hantera många underdomäner, samordna med DNSSEC och bygga in CAA i automatiserade certifikatarbetsflöden kräver alla en gedigen förståelse för hur PKI, DNS och de senaste branschreglerna passar ihop.
Krypteringskonsulttjänster hjälper organisationer att utforma och hantera sina PKI, inklusive fullständig hantering av certifikatlivscykeln som täcker både utfärdande och DNS-kontroller kring det. Vår CertSecure Manager- plattform upptäcker certifikat i din miljö, övervakar loggar för certifikattransparens och automatiserar förnyelser, så att den kan flagga certifikat från oväntade certifikatutfärdare innan de förvandlas till incidenter. Vi erbjuder även PKI-tjänster som granskar din beredskap för krav och hittar luckor innan de orsakar avbrott.
Slutsats
CAA-poster har funnits sedan 2017, men 2025 och 2026 ökade insatserna. Med MPIC som nu kontrollerar från flera platser och DNSSEC-validering som krävs är en felkonfigurerad post inte längre en liten svaghet. Det kan hindra dina certifikat från att utfärdas. I takt med att certifikatens livslängd blir kortare och förnyelser sker oftare, ökar bara kostnaden för att göra detta fel.
Den goda nyheten är att stegen är enkla. Auktorisera alla CA som för närvarande utfärdar certifikat för din domän. Lägg till en issuewild-post för jokerteckenscertifikat och en iodef-post så att du får meddelanden om blockerade försök. Håll din DNS offentligt tillgänglig och konsekvent, övervaka din DNSSEC-hälsa om du använder den och bygg in CAA i din automatisering så att varje ny domän är skyddad från dag ett.
Om du vill ha hjälp med att se över din nuvarande CAA-konfiguration eller bygga en starkare DNS- och certifikathanteringsstrategi kan Encryption Consultings team hjälpa dig att täppa till luckorna innan de orsakar problem.
