When it comes to managing TLS certificates, one crucial aspect that often goes overlooked is delegated domain verification.
In my previous post, I talked about the work we’re doing at the IETF to establish best practices around DNS-based domain verification via the Internet-Draft ‘Domain Verification Techniques using DNS‘. Delegated domain verification is a neat use case enabled by using CNAMEs for domain verification.
Delegated domain verification is a process used to verify the ownership of a domain by delegating the verification task to an intermediary or a Content Delivery Network (CDN). A lot of CDNs, such as Cloudflare and Fastly, offer to manage your TLS certificates as a service.
In order to be issued a TLS cert from a Certificate Authority (CA) like Let’s Encrypt, you need to prove that you control the domain. Typically, this is done via the DNS-01 challenge where you place a unique token that Let’s Encrypt gives you in your DNS.
But what happens when you want to renew the certificate?
Let’s Encrypt only issues certificates with a 90-day validity period for security reasons. This means that after 90 days, you need to redo the DNS-01 challenge and replace the unique token with a new one.
Doing this manually is an annoyance and the consequences of messing it up are huge, given that browsers heavily penalize non-HTTPS websites. This is why CDNs offer to automate this process for you, but this cannot be done via TXT records because you’d have to hand over access to your entire DNS in order to let them do that. CNAMEs to the rescue!
CNAMEs let you say that ‘the DNS record for this name actually lives over there‘. This works great for delegation. You can put a CNAME record in your DNS for the Let’s Encrypt domain verification challenge, and point it to a CDN-controlled DNS name. For example, if you were trying to delegate your domain
example.com’s Let’s Encrypt certificate renewal via Cloudflare, you could add the following CNAME once and be done with it:
_acme-challenge.example.com. CNAME "<random-token-given-by-cloudflare>.cloudflare.com"
Cloudflare would add something like:
<random-token-given-by-cloudflare>.cloudflare.com. TXT "<random-token-given-by-let's-encrypt>"
Now, Cloudflare can request certificate renewal on your behalf. Every 90 days, Let’s Encrypt will give Cloudflare a unique token asking to prove that it controls
example.com, which Cloudflare will put in the TXT record (<random-token-given-by-let’s-encrypt>).
Now, Let’s Encrypt can do a DNS query for
_acme-challenge.example.com and be redirected to the name
<random-token-given-by-cloudflare>.cloudflare.com. then verify the unique token needed for renewal. Importantly, the CNAME record you add, which points to Cloudflare, also needs a random token. This proves to Cloudflare that you control the
Delegated domain verification using CNAME records and CDNs simplifies the process of TLS certificate renewal and mitigates the risks associated with manual handling. It provides a secure and automated solution for managing TLS certificates and ensuring the continuous operation of HTTPS-enabled websites.
Shivan Sahib is a privacy engineer with an interest in privacy-respectful standards and is active in the IETF and W3C, co-chairing groups responsible for Oblivious HTTP and privacy research. Shivan is currently on the Advisory Council of Open Tech Fund’s Information Controls Fellowship.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.