Vanaf 7 september 2017 vereisen de Baseline Requirements van het CA/Browser Forum dat de records voor Certificate Authority Authorization (CAA) gecontroleerd worden voordat certificaten uitgeven worden. Websiteoperators en domeinbeheerders hoeven geen updates uit te voeren om aan deze nieuwe vereiste te voldoen.

CAA is een veiligheidsmaatregel die domeineigenaars de mogelijkheid biedt om in hun Domain Name Servers (DNS) te bepalen welke CA's certificaten voor dat domein mogen uitgeven. Als een CA een bestelling ontvangt voor een certificaat voor een domein met een CAA-record en die CA niet is opgegeven als geautoriseerde verlener, dan mag de CA geen certificaat verlenen voor dat domein of een subdomein ervan.

Voordelen van CAA

Een van de voordelen van CAA is dat het complementair is met Certificate Transparency (CT). CT biedt mechanismen waarmee domeineigenaars foutief uitgegeven of uitgegeven certificaten voor hun domeinen kunnen identificeren, terwijl CAA de ongeautoriseerde uitgifte kan helpen voorkomen. Samen zorgen ze voor een betere beveiliging dan elk apart kan bieden.

CAA kan ook organisaties helpen die een standaard CA gekozen hebben of slechts een beperkt aantal CA's willen gebruiken. Vóór CAA konden organisaties dit soort beleid zeer moeilijk afdwingen, maar nu alle CA’s dit moeten controleren in de CAA-records, kan dit beleid daadwerkelijk worden afgedwongen door de CA's.

CAA implementeren

Hoewel controleren op CAA-records verplicht is voor CA's, is CAA gebruiken optioneel voor domeineigenaars. Je kan dus zelf beslissen of je dit wilt implementeren en meerdere CA’s opgeven indien gewenst (zie waarschuwingen verder in deze blog).

Dit zijn de verwerkingsregels voor CA's:

• Geen CAA-record: CA mag certificaat uitgeven.
• CAA-record bevat CA: CA mag certificaat uitgeven.
• CAA-record, maar bevat CA niet: CA mag niet uitgeven.

CAA ondersteunt de volgende kenmerken:

• Issue: staat CA's toe certificaten uit te geven (inclusief wildcard-certificaten, tenzij beperkt door Issuewild)
• Issuewild: staat CA's toe een wildcard-certificaat uit te geven, maar geen niet-wildcard-certificaten.

Dit is een voorbeeld van de CAA-code die je moet toevoegen aan een DNS-zonebestand als je GlobalSign wilt toestaan om certificaten te verlenen voor voorbeeld.com:

CAA 0 issue “globalsign.com”

Houd er rekening mee dat CAA-controles starten met de volledige FQDN en tot het Base Domain gaat, dus bij het valideren van de FQDN van www.ons.voorbeeld.com, controleert de CA:

-          www.ons.voorbeeld.com, dan

-          ons.voorbeeld.com, dan

-          voorbeeld.com

Gedetailleerde instructies over hoe je CAA-records kunt toevoegen, inclusief stappen voor een gehoste DNS, kan je in ons supportartikel vinden.

Wees voorzichtig bij het updaten van CAA

Ga voorzichtig te werk bij het aanmaken van CAA-records. Als je andere afdelingen hebt die certificaten bestellen, moet je ervoor zorgen dat alle gebruikte CA's aan de CAA-records worden toegevoegd. Omdat CAA-controle verplicht is en leidt tot afgewezen bestellingen die een CA niet ongedaan kan maken, is het belangrijk dat de DNS-beheerder het bedrijf niet blokkeert! Als je dus een serviceprovider gebruikt voor een of meerdere hostingoplossingen, beveiligt de provider die servers mogelijk met een CA waarmee je geen directe relatie hebt, dus wees voorzichtig.

Als snelle controle kan je een query uitvoeren voor certificaten die werden verleend voor jouw domein met https://crt.sh/, waarbij je als antwoord een lijst met de verlenende CA's voor dat domein ontvangt. Denk dus voordien goed na bij het updaten van de CAA-records!

GlobalSign en CAA

GlobalSign startte met het opleggen van CAA op 28 augustus 2017.

Zoals hierboven vermeld, hebben we een aantal supportartikelen geschreven om te helpen bij de implementatie en het oplossen van een aantal veel voorkomende fouten. Aarzel niet om contact met ons op te nemen indien je nog vragen hebt over CAA.