If you are a SaaS, PaaS, or CDN provider that supports custom domains, then CAA records published by your customer could prevent you from obtaining an SSL certificate for their custom domain. This could delay onboarding, causing them to abandon your service. If they publish a CAA record after provisioning your service, it could block certificate renewal, leading to an outage which makes your service look bad.

Fortunately, there is an easy solution that guarantees you can successfully obtain and renew certificates for your customers' domains regardless of their CAA records.

Scenario

• You're a SaaS provider, blogprovider.example, that supports custom domains. Your customer, example.com, delegates their blog subdomain to you with the following CNAME record:

  blog.example.com. CNAME domains.blogprovider.example.

• At domains.blogprovider.example, you publish A/AAAA records for your web server or load balancer.

• Since blog.example.com is delegated to your web server, you have control over blog.example.com and can automatically obtain HTTPS certificates for it using Let's Encrypt's http-01 or tls-alpn-01 challenges (or an equivalent offered by another certificate authority) - provided that the relevant CAA records don't forbid Let's Encrypt.

  For example, if your customer has a CAA record at example.com that looks like

  example.com. CAA 0 issue "sectigo.com"

  then you won't be able to obtain a Let's Encrypt certificate for blog.example.com.

Don't ask your customer to change or remove their CAA record

Having your customer remove their CAA record or add an entry for letsencrypt.org would allow you to get certificates, but it's not a solution. Asking your customer to perform additional work creates friction and they might be reluctant to list a certificate authority which they don't use themselves. This is particularly the case with large companies which tightly control their certificates - your point of contact might not have the authority to make changes to their organization's CAA records.

Additionally, relying on your customer to manage CAA records is fragile. If they later remove letsencrypt.org from the CAA record, your service won't break immediately, but your next certificate renewal will fail. Also, you won't be able to migrate to a different certificate authority in the future unless you ask all of your existing customers to update their CAA records.

Solution: publish a CAA record at domains.blogprovider.example

Fortunately, the CAA specification allows subdomains to override CAA records at parent domains, and since CAA records work like normal DNS records, CNAMEs are supported. Before checking the CAA record at example.com, Let's Encrypt checks blog.example.com, and follows the CNAME record to domains.blogprovider.example. If domains.blogprovider.example has a CAA record that includes letsencrypt.org, then you'll be able to get Let's Encrypt certificates for blog.example.com, regardless of the CAA record at example.com.

Here's what your CAA record should look like:

domains.blogprovider.example. CAA 0 issue "letsencrypt.org"

Once this DNS record is in place, you'll be always be able to obtain Let's Encrypt certificates for your customers' domains, ensuring a smooth onboarding process and reliable renewals.

For more information about CAA, including how to set up CAA records for other certificate authorities, see SSLMate's CAA Helper.