Vergeet TLSA record niet na vervanging TLS-certificaat

Het gebruik van DANE om server-certificaten voor web en mail van een (extra) anker te voorzien introduceert afhankelijkheden tussen serverbeheer en DNS-management. Bij de verandering van een certificaat moet immers ook het bijbehorende TLSA record aangepast worden.

Sterker nog, een verandering in een server-certificaat vraagt om een kleine roll-over (zoals aangegeven in Appendix A.4 van RFC 6698Link opent in een nieuwe browsertab): Het nieuwe TLSA record moet gepubliceerd worden voordat het certificaat wordt vervangen. Pas na het verlopen van de TTLLink opent in een nieuwe browsertab, als de oude TLSA-informatie uit alle caches is verdwenen, mag het nieuwe certificaat in de server geactiveerd worden. Doe je dat eerder, dan loop je het risico dat validerende clients op basis van de oude informatie het nieuwe certificaat (nog) niet accepteren.

Automatisering

De certificaten van het populaireLink opent in een nieuwe browsertabLet's EncryptLink opent in een nieuwe browsertab hebben een geldigheidsduur van 90 dagen. Volgens de ontwikkelaars is het "afdwingen van automatisering" een belangrijke reden voor deze korte geldigheidsduurLink opent in een nieuwe browsertab. Automatisering van het opvragen en installeren van een nieuw certificaat is prima te doen met behulp van de certbot softwareLink opent in een nieuwe browsertab (een ACME-clientLink opent in een nieuwe browsertab). Voor het automatisch genereren en installeren van het bijbehorende TLSA record in de DNS-server is het aanbod echter beperkt.

Gebruikers van OpenDNSSECLink opent in een nieuwe browsertab zouden het onlangs gepubliceerde bash-script van Dennis BaatenLink opent in een nieuwe browsertab als startpunt hiervoor kunnen nemen. Voor BIND-installaties is het voordehandliggend om iets te bouwen rondom het nsupdate commando voor Dynamic DNS (DDNSLink opent in een nieuwe browsertab) updates.