Defaults.Exposed › Åtgärder › CAA-poster

Hur du fixar CAA-poster

En CAA-post är en kort instruktion i dina domäninställningar som namnger vilka certifikatföretag som tillåts utfärda 'hänglåsets' säkerhetscertifikat för din webbplats. Med den aktiverad kan inget annat företag tyst skapa ett giltigt certifikat i ditt namn.

Slutsats för ditt företag: Utan en CAA-post kan nästan vilket som helst av hundratals certifikatföretag världen över utfärda ett genuint, fullt betrott hänglåscertifikat för din domän — vilket låter en bedragare bygga upp en felfri, till synes 'säker' klon av din webbplats för att skörda dina kunders inloggningar och kortuppgifter, med ingenting på skärmen som varnar dem.

Vad detta kan kosta dig

En bedragare skaffar ett riktigt certifikat för en kopia av din webbplats, så den visar det gröna hänglåset och HTTPS — dina kunder ser ingenting fel, skriver in sina lösenord och kortnummer, och du får reda på det först när chargebacks och arga samtal börjar.
Dina kunder blir nätfiskade via en pixelperfekt kopia av din inloggningssida; följderna — återbetalningar, supportbelastning, rykteskada — landar på ditt varumärke även om din riktiga webbplats aldrig rördes.
En potentiell kunds säkerhets- eller inköpsteam kör en snabb kontroll på din domän innan de skriver på, ser inget CAA-skydd och markerar dig tyst som 'svag på grunderna' — sätter en affär i risk för en inställning som tar fem minuter att lägga till.
Ett av världens certifikatföretag komprometteras (det har hänt upprepade gånger — DigiNotar, Comodo, Symantec), och för att du aldrig sa vem som tillåts agera för dig är din domän exponerad mot vilken av dem som visar sig vara den svagaste länken.

Varför det spelar roll. Just nu står dörren vidöppen: varje certifikatföretag på Earth kan borga för en webbplats som påstår sig vara din, vare sig du någonsin haft att göra med dem eller inte. En CAA-post låser den dörren så att bara den leverantör du valde kan utfärda certifikat — det är det enklaste, billigaste skyddet mot att någon imiterar ditt företag online.

CAA-poster, i klartext

Varje säker webbplats har ett certifikat — det som sitter bakom hänglåset i webbläsaren och “https” framför din adress. Dessa certifikat delas ut av specialistföretag som kallas certifikatmyndigheter (CA:er): namn som Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. När din webbläsare ser ett giltigt certifikat visar den hänglåset och berättar för din kund att anslutningen är genuin och säker.

Här är den del de flesta företagsägare aldrig fått veta: som standard tillåts hundratals av dessa certifikatmyndigheter runt om i världen var och en att utfärda ett certifikat för din domän — vare sig du någonsin hört talas om dem eller inte. En CAA-post (Certification Authority Authorization) är en enradsanteckning du lägger till i din domäns DNS-inställningar som i praktiken säger: “bara dessa leverantörer tillåts utfärda certifikat för mig.” Varje legitim certifikatmyndighet är skyldig enligt branschens regler att kontrollera den anteckningen före utfärdande — och att vägra om de inte finns på din lista.

Det är skillnaden mellan en olåst ytterdörr som vem som helst kan gå igenom och en där bara de personer du valt håller en nyckel. Och det kostar ingenting att lägga till.

Vad det här kan kosta dig

Risken en CAA-post stänger av är övertygande imitation. När en bedragare kan få ett riktigt certifikat för en kopia av din webbplats försvinner de vanliga varningstecknen — inget trasigt hänglås, ingen “ej säker”-banner, inget certifikatfel. Allt ser rätt ut, vilket är exakt vad som gör det farligt.

Den felfria förfalskningen. En bedragare registrerar en lookalike-adress (eller komprometterar en väg till dina kunder), skaffar ett genuint certifikat och sätter upp en perfekt klon av din inloggnings- eller kassasida — hänglås och allt. Kunder anger lösenord och kortnummer som normalt. Det första du hör om det är en våg av chargebacks, bedrägerirapporter och arga telefonsamtal.
Nätfiskekampanjen i ditt namn. Angripare skickar “bekräfta ditt konto”-mejl som länkar till deras certifierade klon av din webbplats. Eftersom sidan ser fullt säker ut faller fler för det. Städningen — att informera kunder, återbetalningar, supporttimmar, den besvärliga offentliga förklaringen — landar på dig, även om dina riktiga servrar aldrig rördes.
Affären som stannar på en checklista. En större kunds säkerhets- eller inköpsteam skannar din domän innan de skriver på. “Ingen CAA-post” dyker upp som ett rött eller gult element bredvid ditt namn. Det är litet tekniskt sett, men det läses som “täcker inte grunderna,” och det kan sakta ned eller sänka ett kontrakt du annars skulle ha vunnit.
Drabbad av någon annans intrång. En certifikatmyndighet du aldrig haft att göra med komprometteras — det är inte hypotetiskt; DigiNotar, Comodo och Symantec har alla haft allvarliga incidenter. För att du aldrig begränsade vem som kunde agera för dig kan angriparen skaffa ett giltigt certifikat för din domän via den svaga CA:n. En CAA-post skulle ha vägrat dem.
Jokerteckens blinda fläcken. Även företag som är försiktiga med sin huvudsida glömmer ofta underdomäner. Utan en issuewild-regel ger en angripare som kan skaffa ett jokerteckencertifikat i praktiken en nyckel till varje underdomän du någonsin kommer att ha på en gång.

Inget av dessa kräver en sofistikerad attack på dina servrar. De utnyttjar det faktum att utan en CAA-post är det bredare certifikatsystemet helt enkelt för tillitsfullt å dina vägnar.

Vad det faktiskt är, och vad “bra” ser ut som

En CAA-post lever i din domäns DNS — samma inställningar som pekar din domän mot din webbplats och e-post. Varje post har tre delar: en flagga, en tagg och ett värde. De taggar som spelar roll är:

issue — namnger en certifikatmyndighet som tillåts utfärda normala certifikat för din domän. Du kan ha flera, en per leverantör du legitimt använder.
issuewild — styr jokertecken-certifikat (ett certifikat som täcker varje underdomän, t.ex. *.example.com). Om du inte använder jokertecken är den rekommenderade inställningen att blockera dem helt.
iodef — en valfri kontaktadress där du meddelas om en certifikatmyndighet avvisar en begäran på grund av din CAA-policy. Det är din tidig-varning om att någon försökt.

Vad “bra” ser ut som: minst en issue- (eller issuewild-) post finns, som namnger den eller de leverantörer du faktiskt använder, med jokertecken antingen begränsade till en namngiven leverantör eller blockerade. Det är det som den här kontrollen mäter — den slår upp din domäns CAA-poster över flera oberoende resolvers och godkänns när den hittar en riktig issue- eller issuewild-policy på plats. En domän utan inga CAA-poster alls behandlas som den öppna dörr den är.

Påverkar det här mitt betyg? Ja. En saknad CAA-post är en betygsatt post och flaggas med medelhög allvarlighetsgrad — det är ett genuint gap, inte bara trevligt att ha, för det lämnar en verklig impostorväg öppen. Att lägga till posten stänger gapet och rensar fyndet.

Så här åtgärdar du det (gratis, ~5 minuter)

Lämna det här avsnittet till den som hanterar din domän eller webbplats — åtgärden är gratis. Det är en liten DNS-ändring, inte en ombyggnad. Vi tar bara betalt om du senare vill att vi ska hålla koll på att posten förblir på plats; att lägga till den kostar ingenting.

Steg 1 — Ta reda på vilken certifikatmyndighet du faktiskt använder. Det är det enda steget värt att göra rätt, för att lista fel leverantör kan blockera din nästa förnyelse. Vanliga fall:

Let’s Encrypt — används av många värdar och kontrollpaneler (cPanel, Plesk) → letsencrypt.org
Cloudflare (om det utfärdar ditt edge-certifikat) → letsencrypt.org, digicert.com, comodoca.com, pki.goog och ssl.com (Cloudflare använder flera backend-CA:er; lista de som dess instrumentpanel visar, eller dess fullständiga uppsättning, så att förnyelser aldrig bryter)
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com (och comodoca.com)
Microsoft 365 / Azure — Microsoft använder vanligtvis DigiCert för hanterade certifikat → digicert.com (bekräfta i din portal)

Om du är osäker, titta på ditt nuvarande certifikat i webbläsaren (klicka på hänglåset → certifikatdetaljer → “Utfärdat av”) för att se vem som utfärdade det.

Steg 2 — Logga in på din DNS-leverantör. Det är dit din domäns poster lever — vanligtvis din registrar, din webbvärd eller Cloudflare. Hitta DNS-postavsnittet och välj att lägga till en ny post av typen CAA (vissa gränssnitt märker den typ 257).

Steg 3 — Lägg till en issue-post för varje leverantör du använder. För Let’s Encrypt, till exempel:

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

Lägg till en issue-rad per legitim leverantör. De flesta DNS-instrumentpaneler ger dig separata rutor för flaggan (0), taggen (issue) och värdet (CA:ns domän) så att du inte behöver skriva hela raden för hand.

Steg 4 — Kontrollera jokerteckencertifikat. Om du inte använder jokertecken, blockera dem helt så att ingen tyst kan skaffa ett:

example.com.   CAA   0 issuewild ";"

Om du använder jokertecken, namnge leverantören istället: 0 issuewild "letsencrypt.org".

Steg 5 — (Rekommenderat) Lägg till en meddelandeadress. Så att du informeras när en CA avvisar ett försök — din tidig-varning om att någon försökt:

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

Steg 6 — Spara och verifiera. Kör dig CAA example.com (eller använd valfritt DNS-sökverktyg online) och bekräfta att dina poster visas. Ändringar kan ta allt från några minuter till några timmar att sprida sig över internet. Ditt befintliga certifikat och alla förnyelser fortsätter fungera hela tiden — CAA styr bara ny utfärdande.

Plattformssnabbnoteringar: På Cloudflare, DNS → Poster → Lägg till post → typ CAA. På Google Workspace hanterar du DNS på din registrar (eller Cloud DNS om du använder det) — lägg till CAA-posterna där med pki.goog. På Microsoft 365 sätts CAA inte i M365 administratörscentret; lägg till det var din domäns DNS är hostad och lista din hanterade-certifikat-CA (vanligtvis DigiCert). På vanliga värdar (GoDaddy, Namecheap och liknande) är det i samma DNS-panel där dina A- och MX-poster lever.

Vanliga misstag

Lista fel CA — eller glömma en. Den störst verkliga risken är inte säkerhet, det är att blockera dina egna förnyelser. Om du använder mer än en utfärdare (t.ex. en för huvudwebbplatsen och en annan bakom Cloudflare), lista dem alla. Om du är osäker, lista ett fåtal du litar på snarare än för få.
Sätta issue men ignorera jokertecken. En domän som begränsar normala certifikat men inte säger något om jokertecken lämnar fortfarande den kraftfullare jokerteckenvägen öppen. Sätt alltid issuewild också — antingen till din leverantör eller till ";" för att blockera den.
Placera CAA på fel namn. CAA läses av certifikatmyndigheten för det exakta namn som certifieras, som promenerar upp i trädet. Att sätta den på toppen av din domän (“apex”, t.ex. example.com) är rätt drag — det täcker underdomäner som standard om inte en underdomän sätter sin egna.
Anta att din plattform redan gjort det. Cloudflare, Google och Microsoft hanterar certifikat men lägger inte till CAA-poster åt dig. Om du inte lade till dem är din domän fortfarande öppen.
Behandla det som ett engångsjobb utan övervakning. En senare DNS-migration, en registratorbyte eller en “städning” av poster kan tyst ta bort ditt CAA-skydd. Det är värt att kontrollera att det fortfarande finns kvar efter varje DNS-ändring.

Det tekniska lagret (lämna det här till din IT-person)

CAA definieras i RFC 8659 och verkställs under CA/Browser Forum Baseline Requirements — varje offentligt betrodd CA är skyldig att kontrollera CAA vid utfärdningstillfället. Poster tar formen <flaggor> <tagg> <värde>, med taggar issue, issuewild och iodef. En icke-tom issue- eller issuewild-policy är vad som tillfredsställer den här kontrollen; närvaron av iodef ensam gör det inte (det är rapportering, inte auktorisering).

En solid baslinje vid apex:

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

Noteringar för implementeraren:

CAA träd-klättring: CA:er utvärderar CAA från det begärda FQDN uppåt till apex, och stannar vid det första namnet med en CAA-postuppsättning. En post vid apex skyddar därför alla underdomäner om inte en underdomän publicerar sin egna, vilket den kan — användbart om en specifik underdomän använder en annan utfärdare.
;-värdet i issuewild betyder “ingen CA får utfärda jokertecken” — ett uttryckligt nekande. Använd det när jokertecken inte är en del av din inställning.
0-flaggan är utfärdar-kritisk-flaggan; 0 (icke-kritisk) är korrekt för normal användning. Undvik att sätta den kritiska biten om du inte fullständigt förstår den, eftersom en missförstådd kritisk tagg kan få konforma CA:er att vägra utfärdande.
Flera utfärdare: flera issue-poster är tillåtna och additiva — lista varje CA legitimt i din stack (inklusive backend-CA:erna din CDN/edge-leverantör använder) för att förhindra förnyelsemisslyckanden.
Verifiering: dig CAA example.com +short, eller kontrollera via CA/Browser Forum CAA-testverktyg. Den här kontrollen i sig frågar CAA över flera oberoende resolvers och accepterar det första auktoritativa svaret, så ett enda resolveravbrott inte producerar ett falskt “ingen CAA”-resultat.
DNSSEC-parning: CAA berättar för CA:er vem som får utfärda; DNSSEC förhindrar att CAA-svaret i sig förfalskas under transport. De är kompletterande — för domäner med högt värde, kör båda.

Konfigurera det hos din leverantör

Steg för steg för populära leverantörer:

Vanliga frågor

Jag är inte teknisk — kan jag hantera det här själv?

Du behöver inte förstå detaljerna, men åtgärden är en liten förändring i ditt domäns DNS-inställningar, så det är bäst att lämna det till den som hanterar din webbplats eller domän. Skicka avsnittet 'Så här åtgärdar du det' nedan till dem — det är en fem-minuters, kostnadsfri ändring. Vi tar bara betalt om du senare vill att vi ska hålla koll på att posten förblir på plats; åtgärden i sig är alltid gratis.

Kommer att lägga till det här att bryta min webbplats eller mitt certifikat?

Nej — förutsatt att du listar den certifikatleverantör du faktiskt använder, fortsätter allt att fungera precis som förut. En CAA-post rör eller ersätter inte ditt befintliga certifikat; den styr bara vem som tillåts skapa nya sådana. Det enda sättet att orsaka problem är att lämna din riktiga leverantör av listan, vilket kan blockera din nästa automatiska förnyelse — stegen nedan är specifikt skrivna för att undvika det.

Om certifikat utfärdas automatiskt nuförtiden, varför behöver jag fortfarande det här?

Automatiska certifikat är bra och bekväma — problemet är att systemet är öppet för alla som standard, inklusive någon som låtsas vara dig. En CAA-post namnger helt enkelt vem som tillåts, och förvandlar en öppen dörr till en med ditt eget lås på den. Det fungerar tillsammans med automatisk utfärdande, inte mot det.

Påverkar det här min Google-rankning eller mitt betyg i den här rapporten?

Det påverkar ditt säkerhetsbetyg här — en saknad CAA-post är en betygsatt post, märkt som ett medelsvårt gap, för den lämnar en verklig impostorväg öppen. Det är inte en direkt Google-rankningsfaktor, men den imitation och det nätfiske det förhindrar är exakt de typer av incidenter som skadar förtroende och trafik. Oavsett är det en snabb, gratis vinst.

Vad är skillnaden mellan 'issue' och 'issuewild'?

En 'issue'-post styr normala certifikat för din domän och dess underdomäner. En 'issuewild'-post styr jokertecken-certifikat — det enskilda certifikatet som täcker varje möjlig underdomän på en gång (som *.example.com). Jokertecken är kraftfullare och därför riskfylldare i fel händer, så det är god praxis att kontrollera dem separat: om du inte använder jokertecken, blockera dem helt.

Vi använder Cloudflare / Google Workspace / Microsoft 365 — täcker det redan det här?

Inte automatiskt. De plattformarna hanterar dina certifikat åt dig, men om du inte uttryckligen har lagt till CAA-poster säger din domän fortfarande till världen 'vilken myndighet som helst kan utfärda'. Det goda är att åtgärden är samma enkla DNS-ändring på alla av dem, och där Cloudflare eller din värd utfärdar ditt certifikat, listar du helt enkelt den leverantören. Plattformnoterningarna i avsnittet om åtgärden nedan täcker de vanliga fallen.