CAA records: Kontrollér hvem der kan udstede certifikater til dit domæne

Hvad er CAA records?

Certification Authority Authorization (CAA) er en DNS record-type defineret i RFC 8659. Den fortæller certifikatudstedere, om de har lov til at udstede certifikater for dit domæne.

Siden september 2017 er alle offentlige CA'er forpligtet til at tjekke CAA records, før de udsteder et certifikat. Hvis din CAA record ikke tillader den pågældende CA, skal CA'en afvise anmodningen.

CAA er en policy-mekanisme, der håndhæves af CA'erne ved udstedelse, frem for en teknisk spærring i TLS-protokollen. Hvis en CA ignorerer din CAA record og udsteder alligevel, er det et brud på CA/Browser Forum-reglerne, som kan koste dem deres plads i trust stores.

Hvordan CAA virker

En CAA record har tre dele:

1. Flag: Normalt 0. Værdien 128 (critical flag) betyder, at CA'en skal afvise udstedelse, hvis den ikke forstår property-tagget.
2. Tag: issue (tillader almindelig udstedelse), issuewild (tillader wildcard-udstedelse) eller iodef (notifikation ved afviste forsøg).
3. Value: CA'ens domænenavn (f.eks. digicert.com) eller tom streng for at blokere alle.

CA'en slår CAA op for det specifikke domæne. Hvis der ikke er nogen CAA record, søger den opad i DNS-hierarkiet (f.eks. fra www.example.dk til example.dk). Hvis der slet ingen CAA records findes, betragtes alle CA'er som tilladte.

Opsætning af CAA records

Et typisk setup for en virksomhed, der bruger DigiCert og GlobalSign:

example.dk.  CAA  0 issue "digicert.com"
example.dk.  CAA  0 issue "globalsign.com"
example.dk.  CAA  0 issuewild "digicert.com"
example.dk.  CAA  0 iodef "mailto:ssl-admin@example.dk"

I dette eksempel kan både DigiCert og GlobalSign udstede almindelige certifikater, men kun DigiCert kan udstede wildcard-certifikater. Alle afviste forsøg rapporteres via email.

Du kan blokere wildcard-certifikater helt ved at tilføje en tom issuewild-record:

example.dk.  CAA  0 issuewild ";"

En anden strategi er at tillade én CA til wildcards og andre kun til specifikke domænenavne:

example.dk.  CAA  0 issue "digicert.com"
example.dk.  CAA  0 issue "globalsign.com"
example.dk.  CAA  0 issuewild "digicert.com"

Her kan både DigiCert og GlobalSign udstede almindelige certifikater, men kun DigiCert kan udstede wildcards.

CAA understøtter også issuemail for S/MIME-certifikater (RFC 9495). Det fungerer som issue, men styrer hvilke CA'er der kan udstede e-mail-certifikater for dit domæne:

example.dk.  CAA  0 issuemail "digicert.com"

Brug vores CAA record generator til at bygge den korrekte konfiguration for dit domæne.

CA-identifikatorer

De vigtigste CA'er og deres CAA-identifikatorer:

CA	CAA issue-værdi	Bemærkning
DigiCert	digicert.com	Dækker også RapidSSL, GeoTrust, Thawte
GlobalSign	globalsign.com	Dækker også AlphaSSL
Sectigo	sectigo.com	Dækker også gamle Comodo-produkter og ZeroSSL
Let's Encrypt	letsencrypt.org	Brugt af de fleste hosting-udbydere (one.com, Simply, cPanel m.fl.)
Certum	certum.pl
ssl.com	ssl.com	Overtog Entrust CA-driften

Cloud- og hosting-udbydernes CA'er

De store cloud-platforme driver deres egne CA'er. Bruger du deres automatiske certifikatudstedelse (f.eks. AWS Certificate Manager eller Cloudflare), skal du tillade deres CA i dine CAA records, ellers fejler auto-provisioning.

Platform	CAA issue-værdi	Bemærkning
Amazon (AWS)	amazon.com	AWS Certificate Manager (ACM). Påkrævet for ALB/CloudFront-certifikater.
Google Cloud	pki.goog	Google Trust Services. Også gratis ACME-server.
Cloudflare	letsencrypt.org digicert.com pki.goog	Cloudflare bruger flere CA'er. Tillad alle tre for at undgå problemer.
Microsoft Azure	digicert.com	Azure App Service bruger DigiCert til managed certificates.

DigiCerts identifikator dækker alle deres underbrands. Du behøver ikke tilføje separate records for RapidSSL eller GeoTrust.

Avancerede CAA-parametre

Notifikation ved udstedelsesforsøg (iodef)

CAA understøtter en iodef property der beder CA'en om at sende en notifikation, hvis nogen forsøger at udstede et certifikat for dit domæne og bliver afvist af CAA-reglerne. Det kræver blot én ekstra DNS-record:

example.dk.  CAA  0 iodef "mailto:ssl-alerts@example.dk"

Du kan også angive en HTTPS-URL, hvis du vil modtage strukturerede rapporter via en webhook:

example.dk.  CAA  0 iodef "https://example.dk/caa-report"

Ikke alle CA'er implementerer iodef, men de store (DigiCert, Sectigo) gør. Det giver en tidlig advarsel hvis nogen forsøger at misbruge dit domæne.

Kontolåsning (accounturi)

Du kan begrænse udstedelse til en specifik konto hos CA'en ved at tilføje accounturi som parameter:

example.dk.  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"

Kun den specifikke ACME-konto kan derefter udstede certifikater, selv om CA'en er tilladt i CAA. Det er primært relevant for organisationer der vil forhindre at andre afdelinger eller medarbejdere opretter certifikater uden om de normale kanaler.

CAA vs HPKP: Hvorfor CAA vandt

HTTP Public Key Pinning (HPKP) var et tidligere forsøg på at begrænse, hvilke certifikater en browser ville acceptere for et domæne. HPKP fastlåste specifikke public keys via en HTTP-header. Hvis du mistede din private nøgle eller lavede en fejl i konfigurationen, låste du effektivt alle brugere ude af domænet i pin-periodens varighed (typisk uger eller måneder). Der var ingen recovery-mekanisme. Google Chrome fjernede HPKP-support i 2018.

CAA løser det samme problem (begræns hvem der kan udstede) uden risikoen for selvskade. Du kan altid ændre dine CAA records, og ændringen træder i kraft inden for DNS TTL-perioden. Ingen brugere bliver låst ude.

Almindelige fejl

• Blokerer CA'er du allerede bruger. Den hyppigste fejl er at tilføje CAA records uden at vide hvilke CA'er der allerede udsteder certifikater for dit domæne. Tjek crt.sh for at se alle udstedte certifikater, eller brug vores CAA generator til at bygge de rigtige records baseret på dit domæne. Husk at CAA tjekkes ved udstedelse, så nye certifikatbestillinger bliver blokeret hvis CA'en ikke er tilladt. Opdater CAA records før du bestiller fra en ny CA.
• Glemmer issuewild. Hvis du sætter issue records men ikke issuewild, kan alle CA'er udstede wildcards. Sæt eksplicit issuewild records, eller brug issuewild ";" for at blokere wildcards helt.
• Kun issuewild uden issue. Et wildcard-certifikat dækker typisk både *.example.dk og example.dk. CA'en skal derfor have tilladelse via både issue og issuewild. Mangler issue, bliver certifikatet afvist.
• Glemmer subdomæner. CAA records nedarves i DNS-hierarkiet. Hvis du sætter CAA på example.dk, gælder den også for www.example.dk, medmindre www.example.dk har sine egne CAA records.
• Forkert CA-identifikator. Brug CA'ens officielle domæne, ikke dit eget eller forhandlerens. FairSSL er forhandler for DigiCert, GlobalSign og Sectigo, men CAA-værdien er CA'ens domæne (f.eks. digicert.com), ikke fairssl.dk.
• For lav TTL. Sæt en rimelig TTL (300-3600 sekunder). For lav TTL kan give DNS-opslags problemer hos nogle CA'er.
• Manglende iodef. iodef records er valgfrie, men nyttige. De giver dig besked, når en CA afviser en udstedelse pga. din CAA policy. Det kan afsløre fejlkonfigurationer eller forsøg på uautoriseret certifikatudstedelse.
• Glemmer hosting- eller cloud-platformens CA. Mange platforme bruger flere CA'er, ikke kun én. Cloudflare skifter f.eks. mellem Let's Encrypt, DigiCert og Google Trust Services. Hosting-udbydere kan også bruge både gratis og betalte CA'er. Blokerer din CAA bare én af dem, fejler certifikatudstedelsen næste gang platformen vælger en anden CA. Tjek hvilke CA'er din platform bruger, og tillad dem alle.
• CAA på andre domæner i certifikatet. Har dit certifikat flere navne (SAN), tjekker CA'en CAA records for hvert enkelt domæne. Hvis ét af navnene peger via CNAME til en serviceudbyder med restriktive CAA records der ikke tillader din CA, bliver hele certifikatet afvist. Det er en fejl der kan være svær at finde, fordi problemet ligger på et domæne du ikke selv styrer.

Hvorfor CAA og Certificate Transparency eksisterer

CAA og Certificate Transparency (CT) Logs er begge oprettet for at beskytte dig som bruger af certifikater, uanset om du driver servere eller tilgår dem som slutbruger.

Baggrunden er en reel bekymring: CA'er kan blive overtaget, afpresset eller styret af statsmagter. For eksempel blev DigiNotar kompromitteret i 2011, og den iranske stat brugte de falske certifikater til at aflytte Gmail-trafik fra iranske aktivister. CNNIC, en kinesisk statslig CA, udstedte uautoriserede certifikater i 2015. I begge tilfælde var de falske certifikater kun synlige i det land, hvor de blev misbrugt. Resten af verden anede intet.

Scenariet er simpelt: en statsstyret CA udsteder et certifikat for f.eks. gmail.com eller google.com, placerer det på et overvågningssystem i landets netværk, og kan derefter se hvad dissidenter og aktivister skriver til hinanden eller søger efter. Uden CT Logs og CAA var der ingen mekanisme til at opdage eller forhindre det.

Certificate Transparency: intet certifikat uden offentlighed

CT Logs sikrer, at intet internet-gyldigt certifikat kan virke uden at være offentligt registreret i append-only logs, der ikke kan justeres efterfølgende. Browsere (Chrome, Safari) kræver CT-bevis før de accepterer et certifikat. Hvis et certifikat ikke er logget, viser browseren en advarsel.

Enhver uautoriseret udstedelse bliver synlig. Monitoreringstjenester som crt.sh gør det muligt at søge i alle loggede certifikater for et domæne. Organisationer som Facebook, Google og store banker overvåger CT Logs aktivt og reagerer inden for minutter, hvis et uventet certifikat dukker op.

CAA: kontrol over hvem der må udstede

CAA records giver dig direkte kontrol over hvilke CA'er der overhovedet må udstede certifikater til dit domæne. Hvis et certifikat dukker op i CT Logs for dit domæne, og din DNS CAA tydeligt blokerer den pågældende CA, er det et kraftigt signal om at den CA har udstedt uden tilladelse. Det er en alvorlig overtrædelse af CA/Browser Forum-reglerne og kan koste CA'en sin plads i trust stores.

Vil du minimere risikoen for at en kinesisk, amerikansk eller en hvilken som helst anden statsstyret CA udsteder certifikater på vegne af dit domæne, er CAA records den mest direkte løsning. Kombineret med CT-monitorering har du både forebyggelse og opdagelse.

CAA koster ingenting (en DNS record). CT-monitorering er gratis. Der er ingen grund til ikke at bruge begge dele.