Defaults.Exposed › Fikser › CAA-poster

Slik fikser du CAA-poster

En CAA-post er en kort instruksjon i domeneinnstillingene som navngir hvilke sertifikatselskaper som har lov til å utstede 'hengelås'-sikkerhetssertifikatet for nettstedet ditt. Med den slått på kan intet annet selskap stille opprette et gyldig sertifikat i ditt navn.

Bunnlinjen for virksomheten din: Uten en CAA-post kan nesten hvilken som helst av de hundrevis av sertifikatselskaper over hele verden utstede et ekte, fullt betrodd hengelåssertifikat for domenet ditt — og lar en svindler sette opp en feilfri, fullt 'sikker'-utseende kopi av nettstedet ditt for å høste innloggings- og kortdetaljer fra kundene dine, uten noe på skjermen som advarer dem.

Hva dette kan koste deg

En svindler skaffer et ekte sertifikat for en kopi av siden din, slik at den viser grønn hengelås og HTTPS — kundene dine ser ingenting galt, taster inn passord og kortnumre, og du får først vite om det når tilbakebetalingene og de sinte samtalene starter.
Kundene dine blir phishet gjennom en pixel-perfekt lookalike av innloggingssiden din; etterspillet — refusjoner, støttebyrde, omdømmeskade — lander på merket ditt selv om det ekte nettstedet aldri ble rørt.
Et prospekts sikkerhets- eller innkjøpsteam kjører en rask sjekk på domenet ditt før de signerer, ser ingen CAA-beskyttelse, og merker deg stille som 'svak på det grunnleggende' — setter en avtale i risiko over en innstilling som tar fem minutter å legge til.
Et av verdens sertifikatselskaper blir kompromittert (dette har skjedd gjentatte ganger — DigiNotar, Comodo, Symantec), og fordi du aldri sa hvem som har lov til å handle på dine vegne, er domenet ditt eksponert for det som viser seg å være det svakeste leddet.

Hvorfor det er viktig. Akkurat nå er døren vidåpen: ethvert sertifikatselskap på Jorda kan gå god for en side som hevder å være din, enten du noen gang har hatt med dem å gjøre eller ikke. En CAA-post låser den døren slik at bare leverandøren du valgte kan utstede sertifikater — det er det enkleste, billigste forsvaret som finnes mot at noen utgir seg for å være virksomheten din på nett.

CAA-poster, i enkle ord

Hvert sikkert nettsted har et sertifikat — tingen bak hengelåsen i nettleseren og «https» foran adressen. Disse sertifikatene deles ut av spesialistfirmaer kalt sertifikatmyndigheter (CA-er): navn som Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Når nettleseren ser et gyldig sertifikat, viser den hengelåsen og forteller kunden at tilkoblingen er ekte og sikker.

Her er den delen de fleste virksomhetseiere aldri har fått vite: som standard er hundrevis av disse sertifikatmyndighetene over hele verden hver og en tillatt å utstede et sertifikat for ditt domene — enten du noen gang har hørt om dem eller ikke. En CAA-post (Certification Authority Authorization) er et en-linjes notat du legger til domenets DNS-innstillinger som i praksis sier: «bare disse leverandørene har lov til å utstede sertifikater for meg.» Alle legitime sertifikatmyndigheter er pålagt av bransjereglene å sjekke det notatet før de utsteder — og å nekte hvis de ikke er på listen din.

Det er forskjellen mellom en ulåst inngangsdør hvem som helst kan gå gjennom, og en der bare menneskene du har valgt har en nøkkel. Og det koster ingenting å legge til.

Hva dette kan koste deg

Risikoen en CAA-post lukker er overbevisende etterligning. Når en svindler kan få et ekte sertifikat for en kopi av nettstedet ditt, forsvinner de vanlige advarselstegnene — det er ingen ødelagt hengelås, ingen «ikke sikker»-banner, ingen sertifikatfeil. Alt ser riktig ut, som er nøyaktig det som gjør det farlig.

Den feilfrie falske. En svindler registrerer en lookalike-adresse (eller kompromitterer en rute til kundene dine), skaffer et ekte sertifikat, og setter opp en perfekt klon av innloggings- eller kassesiden din — hengelås og alt. Kunder skriver inn passord og kortnumre som normalt. Det første du hører om det er en bølge av tilbakebetalinger, svindelmeldinger og sinte telefonsamtaler.
Phishing-kampanjen i ditt navn. Angripere sender «vennligst bekreft kontoen din»-e-poster som lenker til den sertifiserte klonen av siden din. Fordi siden ser fullt sikker ut, er det flere som faller for det. Ryddearbeidet — varsle kunder, refusjoner, støttetimer, den vanskelige offentlige forklaringen — lander alt på deg, selv om de ekte serverne aldri ble rørt.
Avtalen som staller på en sjekkliste. En større kundes sikkerhets- eller innkjøpsteam skanner domenet ditt før de signerer. «Ingen CAA-post» dukker opp som et rødt eller gult punkt ved siden av navnet ditt. Det er lite teknisk sett, men det leses som «dekker ikke det grunnleggende», og det kan bremse eller ødelegge en kontrakt du ellers ville ha vunnet.
Fanget av noens andres brudd. En sertifikatmyndighet du aldri har hatt med å gjøre blir kompromittert — dette er ikke hypotetisk; DigiNotar, Comodo og Symantec har alle hatt alvorlige hendelser. Fordi du aldri begrenset hvem som kunne handle for deg, kan angriperen få et gyldig sertifikat for domenet ditt gjennom den svake CA-en. En CAA-post ville ha nektet dem.
Wildcard-blindpunktet. Selv virksomheter som er forsiktige med hovednettstedet glemmer ofte underdomener. Uten en issuewild-regel får en angriper som kan skaffe et wildcard-sertifikat effektivt en nøkkel til hvert underdomene du noen gang vil ha på én gang.

Ingen av disse krever et sofistikert angrep på serverne dine. De utnytter det faktum at det bredere sertifikatsystemet, uten CAA-post, rett og slett er for tillitsfull på dine vegne.

Hva det faktisk er, og hva «bra» ser ut som

En CAA-post lever i domenets DNS — de samme innstillingene som peker domenet mot nettstedet og e-posten. Hver post har tre deler: et flagg, en tag og en verdi. Taggene som betyr noe er:

issue — navngir en sertifikatmyndighet som har lov til å utstede normale sertifikater for domenet ditt. Du kan ha flere, én per leverandør du legitimt bruker.
issuewild — kontrollerer wildcard-sertifikater (ett sertifikat som dekker hvert underdomene, f.eks. *.eksempel.com). Hvis du ikke bruker wildcards, er den anbefalte innstillingen å blokkere dem fullstendig.
iodef — en valgfri kontaktadresse der du varsles hvis en sertifikatmyndighet avviser en forespørsel på grunn av CAA-policyen din. Dette er din tidligvarsel om at noen prøvde.

Hva «bra» ser ut som: minst én issue- (eller issuewild-) post er til stede, som navngir leverandøren(e) du faktisk bruker, med wildcards enten begrenset til en navngitt leverandør eller blokkert. Det er grensen denne sjekken måler — den slår opp CAA-poster i domenet ditt på tvers av flere uavhengige resolvere og godkjenner det når den finner en reell issue- eller issuewild-policy på plass. Et domene med ingen CAA-poster i det hele tatt behandles som den åpne døren det er.

Påvirker dette karakteren min? Ja. En manglende CAA-post er en scored post og er flagget ved middels alvorlighetsgrad — det er et genuint gap, ikke bare et hyggelig-å-ha, fordi det etterlater en reell etterligningsrute åpen. Å legge til posten lukker gapet og fjerner funnet.

Slik fikser du det (gratis, ~5 minutter)

Gi denne seksjonen til den som administrerer domenet eller nettstedet ditt — fiksen er gratis. Det er en liten DNS-endring, ikke en ombygging. Vi tar bare betalt hvis du senere ønsker at vi skal fortsette å overvåke at posten forblir på plass; å legge den til koster ingenting.

Steg 1 — Finn ut hvilken sertifikatmyndighet du faktisk bruker. Dette er det ene steget det er verdt å gjøre riktig, fordi det å liste feil leverandør kan blokkere neste fornyelse. Vanlige tilfeller:

Let’s Encrypt — brukt av mange webhoteller og kontrollpaneler (cPanel, Plesk) → letsencrypt.org
Cloudflare (hvis det utsteder kantesertifikatet ditt) → letsencrypt.org, digicert.com, comodoca.com, pki.goog og ssl.com (Cloudflare bruker flere backend-CA-er; list de som dashbordet viser, eller hele settet, slik at fornyelser aldri brytes)
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com (og comodoca.com)
Microsoft 365 / Azure — Microsoft bruker typisk DigiCert for administrerte sertifikater → digicert.com (bekreft i portalen)

Hvis du er usikker, se på det gjeldende sertifikatet i nettleseren (klikk hengelåsen → sertifikatdetaljer → «Utstedt av») for å se hvem som utstedte det.

Steg 2 — Logg inn på DNS-leverandøren. Dette er der domenets poster bor — vanligvis registraren din, webhotellet, eller Cloudflare. Finn DNS-poster-seksjonen og velg å legge til en ny post av typen CAA (noen grensesnitt kaller det type 257).

Steg 3 — Legg til en issue-post for hver leverandør du bruker. For Let’s Encrypt, for eksempel:

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

Legg til én issue-linje per legitim leverandør. De fleste DNS-dashbord gir deg separate bokser for flagget (0), taggen (issue) og verdien (CA-ens domene) slik at du ikke trenger å taste inn hele linjen for hånd.

Steg 4 — Kontroller wildcard-sertifikater. Hvis du ikke bruker wildcards, blokker dem fullstendig slik at ingen stille kan skaffe seg ett:

eksempel.com.   CAA   0 issuewild ";"

Hvis du bruker wildcards, navngi leverandøren i stedet: 0 issuewild "letsencrypt.org".

Steg 5 — (Anbefalt) Legg til en varslingsadresse. Slik at du blir varslet når en CA avviser et forsøk — din tidligvarsel om at noen prøvde:

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

Steg 6 — Lagre og verifiser. Kjør dig CAA eksempel.com (eller bruk et gratis DNS-oppslagsverktøy online) og bekreft at postene dine vises. Endringer kan ta alt fra noen minutter til noen timer å spre seg over internett. Det eksisterende sertifikatet og alle fornyelser fortsetter å fungere gjennom alt — CAA styrer bare ny utstedelse.

Plattform-kjappe notater: På Cloudflare, DNS → Poster → Legg til post → type CAA. På Google Workspace, administrerer du DNS hos registraren (eller Cloud DNS hvis du bruker det) — legg til CAA-postene der med pki.goog. På Microsoft 365 settes CAA ikke i M365-administrasjonssenteret; legg det til der domenets DNS er hostet, og list administrert-sertifikat-CA-en (vanligvis DigiCert). På vanlige webhoteller (GoDaddy, Namecheap, osv.) er det i det samme DNS-panelet der A- og MX-postene lever.

Vanlige feil

Liste feil CA — eller glemme én. Den største reelle risikoen er ikke sikkerhet, det er å blokkere egne fornyelser. Hvis du bruker mer enn én utsteder (f.eks. én for hovednettstedet og en annen bak Cloudflare), list dem alle. Hvis du er usikker, list noen få du stoler på heller enn for få.
Sette issue men ignorere wildcards. Et domene som begrenser normale sertifikater men sier ingenting om wildcards lar den kraftigere wildcard-ruten fortsatt stå åpen. Sett alltid issuewild også — enten til leverandøren din eller til ";" for å blokkere det.
Plassere CAA på feil navn. CAA leses av sertifikatmyndigheten for det nøyaktige navnet som sertifiseres, og går opp i treet. Å sette det på toppen av domenet («apex», f.eks. eksempel.com) er det riktige trekket — det dekker underdomener som standard med mindre et underdomene setter sitt eget.
Anta at plattformen allerede har gjort det. Cloudflare, Google og Microsoft administrerer sertifikater, men legger ikke til CAA-poster for deg. Med mindre du la dem til, er domenet fortsatt åpent.
Behandle det som en engangsting uten overvåking. En senere DNS-migrering, en registrar-bytte, eller en «rydding» av poster kan stille fjerne CAA-beskyttelsen. Det er verdt å sjekke at den fortsatt er der etter enhver DNS-endring.

Det tekniske laget (gi dette til IT-personen din)

CAA er definert i RFC 8659 og håndhevet under CA/Browser Forum Baseline Requirements — alle offentlig betrodde CA-er er pålagt å sjekke CAA ved utstedelsestidspunktet. Poster tar formen <flagg> <tag> <verdi>, med taggene issue, issuewild og iodef. En ikke-tom issue- eller issuewild-policy er det som tilfredsstiller denne sjekken; tilstedeværelsen av iodef alene gjør det ikke (det er rapportering, ikke autorisasjon).

Et solid grunnlinje ved apex:

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

Notater for implementøren:

CAA-tre-klatring: CA-er evaluerer CAA fra det forespurte FQDN-et oppover til apex, og stopper ved det første navnet med et CAA-postsett. En post ved apex beskytter derfor alle underdomener med mindre et underdomene publiserer sitt eget.
;-verdien i issuewild betyr «ingen CA kan utstede wildcards» — en eksplisitt avvisning. Bruk det når wildcards ikke er en del av oppsettet.
0-flagget er utstederkritisk-flagget; 0 (ikke-kritisk) er korrekt for normal bruk. Unngå å sette det kritiske bitet med mindre du fullt ut forstår det.
Flere utstedere: flere issue-poster er tillatt og additive — list hver CA legitimt i stabelen (inkludert backend-CA-ene CDN-/kanteleverandøren bruker) for å forhindre fornyelsesfeil.
Verifisering: dig CAA eksempel.com +short, eller sjekk via CA/Browser Forum CAA-testverktøy. Denne sjekken spør selv CAA over flere uavhengige resolvere og godtar det første autoritative svaret.
DNSSEC-paring: CAA forteller CA-er hvem som kan utstede; DNSSEC stopper selve CAA-svaret fra å bli forfalsket under transport. De er komplementære — for høyverdige domener, kjør begge.

Sett det opp hos din leverandør

Trinn for trinn for populære leverandører:

FAQ

Jeg er ikke teknisk anlagt — kan jeg ordne dette selv?

Du trenger ikke forstå detaljene, men fiksen er en liten endring inne i domenets DNS-innstillinger, så det er best å overlate det til den som administrerer nettstedet eller domenet ditt. Send dem «Slik fikser du det»-seksjonen nedenfor — det er en fem-minutters, kostnadsfri endring. Vi tar bare betalt hvis du senere ønsker at vi skal fortsette å overvåke at posten forblir på plass; selve fiksen er alltid gratis.

Vil det å legge dette til ødelegge nettstedet eller sertifikatet mitt?

Nei — så lenge du lister sertifikatleverandøren du faktisk bruker, fortsetter alt å fungere nøyaktig som før. En CAA-post berører ikke eller erstatter det eksisterende sertifikatet; den styrer bare hvem som har lov til å opprette nye. Den eneste måten å skape problemer på er å la den virkelige leverandøren utelate fra listen, noe som kan blokkere neste automatiske fornyelse — stegene nedenfor er skrevet spesielt for å unngå det.

Hvis sertifikater utstedes automatisk i dag, trenger jeg fortsatt dette?

Automatiske sertifikater er fine og praktiske — problemet er at systemet er åpent for alle som standard, inkludert noen som utgir seg for å være deg. En CAA-post navngir ganske enkelt hvem som er tillatt, og gjør en åpen dør til en med din egen lås på den. Det fungerer ved siden av automatisk utstedelse, ikke mot det.

Påvirker dette Google-rangeringen eller karakteren min på denne rapporten?

Det påvirker sikkerhetscoreren din her — en manglende CAA-post er en scored post, merket som et mellomstort gap, fordi det etterlater en reell etterligningsrute åpen. Det er ikke en direkte Google-rangeringsfaktor, men etterligning og phishing det forhindrer er nøyaktig den typen hendelser som skader tillit og trafikk. Uansett er det en rask, gratis gevinst.

Hva er forskjellen mellom 'issue' og 'issuewild'?

En 'issue'-post kontrollerer normale sertifikater for domenet og underdomener. En 'issuewild'-post kontrollerer wildcard-sertifikater — det ene sertifikatet som dekker alle mulige underdomener på én gang (som *.eksempel.com). Wildcards er kraftigere og dermed farligere i feil hender, så det er god praksis å kontrollere dem separat: hvis du ikke bruker wildcards, blokker dem fullstendig.

Vi bruker Cloudflare / Google Workspace / Microsoft 365 — dekker det allerede dette?

Ikke automatisk. Disse plattformene administrerer sertifikatene dine for deg, men med mindre du eksplisitt har lagt til CAA-poster, forteller domenet fortsatt verden 'enhver autoritet kan utstede.' Den gode nyheten er at fiksen er den samme enkle DNS-endringen på alle av dem, og der Cloudflare eller webhotellet utsteder sertifikatet, lister du ganske enkelt den leverandøren. Plattformnotatene i fikse-seksjonen nedenfor dekker de vanlige tilfellene.