CAA-poster – kontroller hvem som kan utstede TLS-sertifikater

En CAA-post, Certification Authority Authorization, er en DNS-post som angir hvilke offentlige sertifikatutstedere som er autorisert til å utstede TLS-sertifikater for et domenenavn. Den kan redusere risikoen for feilutstedelse og gjøre virksomhetens sertifikatpolicy tydeligere.

CAA er likevel ikke en funksjon som bør aktiveres ved å kopiere ett tilfeldig eksempel. En for streng eller ufullstendig policy kan stoppe den automatiske fornyelsen av nettstedets sertifikat. Kartlegg derfor alle legitime utstedere, domenenavn og wildcardbehov før dere publiserer posten.

Hva gjør CAA?

Før en offentlig sertifikatutsteder utsteder et sertifikat, skal den finne den relevante CAA-policyen for hvert navn som skal inngå. Hvis policyen finnes, må utstederen være autorisert av den eller bruke et dokumentert unntak i sine sertifikatregler.

RFC 8659 beskriver CAA som en ekstra kontroll mot utilsiktet feilutstedelse. Standarden understreker samtidig at samsvar med CAA er nødvendig, men ikke tilstrekkelig for utstedelse. Utstederen må fortsatt validere kontroll over domenet og følge sine øvrige krav.

CAA:

• påvirker nye utstedelser og fornyelser
• ligger i den autoritative DNS-sonen
• kan tillate én eller flere sertifikatutstedere
• kan ha egen policy for wildcard
• kan arves av subdomener

CAA:

• tilbakekaller ikke eksisterende sertifikater
• gjør ikke HTTPS-konfigurasjonen sikrere alene
• beskytter ikke privatnøkkelen
• stopper ikke en autorisert CA fra å gjøre en valideringsfeil
• varsler ikke automatisk domeneeieren om hvert nytt sertifikat

Bruk CAA sammen med sterk tilgang til DNS og overvåking av Certificate Transparency .

Syntaksen i en CAA-post

En vanlig post ser slik ut:

bedrift.no.  CAA  0  issue  "letsencrypt.org"

Feltene betyr:

Bruk CA-identifikatoren fra sertifikatutstederens egen dokumentasjon. Den er ikke nødvendigvis identisk med merkenavnet, nettstedets hoveddomene eller navnet som vises i sertifikatkjeden.

DNS-paneler viser feltene ulikt. Noen ber bare om flagg, tag og verdi fordi sone-/domenenavnet allerede er valgt. Ikke legg inn anførselstegn hvis panelet legger dem til automatisk.

issue, issuewild og iodef

issue tillater vanlig utstedelse

Denne posten ber om at bare Let’s Encrypt skal kunne utstede for navnet:

bedrift.no.  CAA  0  issue  "letsencrypt.org"

Hvis den relevante policyen ikke har en issuewild-post, gjelder issue også for wildcardutstedelse.

issuewild styrer wildcard separat

Hvis wildcard skal ha en annen utsteder enn vanlige sertifikater:

bedrift.no.  CAA  0  issue      "ca-for-vanlige.example"
bedrift.no.  CAA  0  issuewild  "ca-for-wildcard.example"

Når minst én issuewild finnes i det relevante postsettet, ignoreres issue ved vurdering av wildcardnavn. issue fortsetter å gjelde vanlige navn.

For å tillate en utsteder for vanlige sertifikater, men be alle utstedere la være å utstede wildcard:

bedrift.no.  CAA  0  issue      "letsencrypt.org"
bedrift.no.  CAA  0  issuewild  ";"

En tom utstederverdi uttrykt som ";" gir ingen CA autorisasjon for denne taggen.

iodef oppgir en rapporteringsadresse

bedrift.no.  CAA  0  iodef  "mailto:sikkerhet@bedrift.no"

iodef kan be en utsteder sende rapport om en forespørsel eller utstedelse som bryter med policyen. Det er ikke en garanti for at alle utstedere varsler. Adressen må dessuten fungere og være overvåket når hovedtjenesten har problemer.

Ikke publiser en privat saksadresse som ingen følger, og ikke baser hendelsesoppdagelsen bare på iodef.

Flere CAA-poster tillater flere utstedere

Poster med samme tag virker additivt:

bedrift.no.  CAA  0  issue  "letsencrypt.org"
bedrift.no.  CAA  0  issue  "annen-ca.example"

Begge utstedere er da autorisert for vanlig utstedelse. Dette er nyttig når nettsted, e-postplattform, CDN eller reserveplattform bruker ulike CA-er.

Ikke slett en «ukjent» tillatelse før dere har funnet hvilken aktiv tjeneste som trenger den. En plattform kan velge sertifikatutsteder dynamisk eller bruke en annen utsteder for reservekjeder og migrering.

Slik arves CAA av subdomener

Ved utstedelse for portal.team.bedrift.no leter CA-en etter CAA i denne rekkefølgen:

1. portal.team.bedrift.no
2. team.bedrift.no
3. bedrift.no
4. no

Søket stopper ved det første navnet som har et CAA-postsett. En policy på et mer spesifikt subdomene erstatter derfor den arvede policyen; den blir ikke automatisk slått sammen med postene på hoveddomenet.

Eksempel:

bedrift.no.         CAA  0  issue  "letsencrypt.org"
portal.bedrift.no.  CAA  0  issue  "annen-ca.example"

portal.bedrift.no tillater her annen-ca.example. Den arver ikke samtidig tillatelsen til letsencrypt.org fra bedrift.no.

Dette har to praktiske konsekvenser:

• én tilfeldig iodef- eller ukjent CAA-post på et subdomene kan endre hvilket postsett CA-en bruker
• policyen må testes for hvert navn som skal inngå i sertifikatet, ikke bare soneapex

CNAME endrer ikke hovedregelen

Mange nettsteder bruker CNAME til en hosting- eller CDN-plattform. Etter RFC 8659 klatrer CAA-søket i navnet sertifikatet skal dekke. Standarden klatrer ikke i tillegg opp hele navnetreet til hvert CNAME-mål slik den eldre RFC 6844 beskrev.

Praktisk betyr det at domeneeieren kan ha en CAA-policy på sitt eget vertsnavn eller en forelder uten at hostingplattformens CAA-policy automatisk blir slått sammen med kundens.

Et navn som er en CNAME kan normalt ikke samtidig ha andre posttyper på samme navn. Da må policyen ofte arves fra en forelder. Kontroller både DNS-modellen og leverandørens dokumentasjon før dere gjør endringen.

Sertifikater med flere domenenavn

Ett sertifikat kan inneholde mange SAN-navn. Sertifikatutstederen skal kontrollere CAA for hvert navn. Hvis ett vertsnavn bare tillater en annen CA, kan hele bestillingen feile selv om alle de andre navnene tillater utstederen.

Eksempel:

bedrift.no.         CAA  0  issue  "letsencrypt.org"
butikk.bedrift.no.  CAA  0  issue  "annen-ca.example"

En bestilling hos Let’s Encrypt som inneholder både bedrift.no og butikk.bedrift.no, kan da bli stoppet på grunn av policyen for butikknavnet.

Når en plattform rapporterer en CAA-feil, finn hele navnelisten i sertifikatbestillingen. Ikke kontroller bare navnet brukeren åpnet i nettleseren.

Flagget 0 og issuer critical

De fleste CAA-poster skal bruke flaggverdien 0.

CAA har et issuer critical-flagg med presentasjonsverdien 128. Hvis dette settes på en egenskap CA-en ikke forstår, skal utstedelsen stoppes. Det er laget for fremtidige, kritiske egenskaper – ikke for å gjøre en vanlig issue-post «mer sikker».

Ikke bruk 1 eller 128 ukritisk etter eksempler fra tilfeldige generatorer. Følg dokumentasjonen til egenskapen og sertifikatutstederen.

DNSSEC og SERVFAIL

Hvis CA-ens resolver får SERVFAIL når den spør etter CAA, kan utstedelsen stoppe. En vanlig årsak er brudd i DNSSEC-kjeden, men også utilgjengelige autoritative tjenere, feil delegering eller DNS-problemer kan gi samme resultat.

Kontroller:

dig bedrift.no CAA
dig bedrift.no CAA +dnssec
dig @1.1.1.1 bedrift.no CAA
dig @8.8.8.8 bedrift.no CAA

Et tomt, vellykket svar er ikke det samme som SERVFAIL. Tomt svar kan bety at ingen CAA-policy finnes på akkurat dette navnet, mens CA-en deretter må lete hos forelderen.

Ikke «rett» en CAA-relatert SERVFAIL ved å fjerne DNSSEC uten å undersøke kjeden. Bruk guiden til vanlige DNS-feil til å skille policyfeil fra ugyldig DNS.

Trygg utrulling steg for steg

1. Lag et sertifikatinventar

Kartlegg:

• alle aktive domenenavn og subdomener
• alle offentlige sertifikater og SAN-navn
• hosting, CDN, e-post og tredjepartsplattformer
• utstederen hver tjeneste bruker nå
• hvem som eier sertifikat- og DNS-kontoene
• om wildcard brukes eller er planlagt

Søk i Certificate Transparency for historiske utstedere, men bekreft aktive tjenester med leverandørene.

2. Les leverandørens CAA-dokumentasjon

Finn den eksakte CA-identifikatoren for hver tjeneste. Spør om plattformen kan bytte utsteder uten varsel, og om den trenger flere tillatelser samtidig.

Noen utstedere støtter valgfrie parametere som begrenser sertifikatbestillingen til en bestemt konto eller valideringsmetode. RFC 8657 standardiserer accounturi og validationmethods, men bruk bare parametere den aktuelle CA-en dokumenterer og håndhever.

3. Publiser alle legitime utstedere først

Start med å tillate dagens og den planlagte løsningens CA-er. Skill wildcard bare hvis virksomheten har en eksplisitt grunn til det.

4. Vent ut gammel TTL

DNS-endringer kan være cachet. Registrer TTL før endringen og vent til den gamle verdien er utløpt hos relevante resolvere før dere stoler på at policyen er lik overalt.

5. Test en reell utstedelse eller stagingfornyelse

Et DNS-oppslag viser syntaksen, men ikke at hostingplattformens faktiske bestilling lykkes. Bruk leverandørens test- eller stagingløp hvis det finnes, eller planlegg en kontrollert fornyelse med rollback.

6. Overvåk neste automatiske fornyelse

Hold den gamle sertifikatutstederen tillatt til den nye leveransen er stabil, og kontroller minst én automatisert fornyelse. Et sertifikat som fortsatt er gyldig i flere uker skjuler lett en feil CAA-policy.

7. Fjern gamle tillatelser kontrollert

Når alle avhengigheter er bekreftet, fjern utstedere virksomheten ikke lenger bruker. Dokumenter hvorfor de gjenværende er autorisert, og sett dato for ny gjennomgang.

Slik bytter dere sertifikatutsteder uten stans

Ved migrering:

1. Legg til den nye CA-identifikatoren før sertifikatet bestilles.
2. Vent ut relevant TTL.
3. Bestill og monter nytt sertifikat på målplattformen.
4. Kontroller HTTPS for alle navn i sertifikatet.
5. Flytt trafikken kontrollert.
6. Bekreft automatisk fornyelse på ny plattform.
7. Fjern gammel CA først når rollbackbehovet er borte.

Ikke erstatt den gamle CAA-posten i samme øyeblikk som dere starter migreringen. Da kan både gammelt miljø, nytt miljø og rollback miste muligheten til å fornye.

Vanlige feil og hva de betyr

Hvis et ukjent sertifikat allerede finnes

En ny CAA-policy gjør ikke det gamle sertifikatet ugyldig. Start med å undersøke hvem som utstedte det, hvilke navn det dekker, om det er aktivt og hvordan domenet ble validert.

Hvis sertifikatet er uautorisert:

• sikre DNS-, hosting- og CA-kontoer
• steng valideringsveien
• kontakt utstederen og be om tilbakekalling
• roter berørte nøkler og kontotilganger
• overvåk flere CT-funn og DNS-endringer
• publiser eller korriger CAA når den legitime arkitekturen er kjent

Ikke publiser en tilfeldig streng policy midt i hendelsen hvis den også kan stoppe gjenoppretting på den legitime plattformen.

CAA i Vymos standardtilbud

Vymo aktiverer HTTPS for den enkle bedriftsnettsiden vi setter opp og hoster. Standardtilbudet lover foreløpig ikke en kundestyrt CAA-policy, valgfri sertifikatutsteder, wildcard eller kontoavgrenset CAA-konfigurasjon.

Har virksomheten krav til bestemte utstedere, egne sertifikater, wildcard, CT-varsling eller en dokumentert CAA-policy, må dette avklares før bestilling. Send Vymo domenenavnene og kravene , men ikke send private nøkler, API-nøkler eller passord i skjemaet.

CAA gir best verdi når virksomheten kjenner hele sertifikatlandskapet. Tillat de utstederne dere faktisk bruker, test hver navnevariant og fornyelsesvei, og fjern gamle tillatelser først når migreringen er bevist stabil.