aWe have the following DNS configuration in place to allow our clients to use vanity URLs to our services:

sub1.clientA.com        CNAME    clientA.our-domain.com
*.our-domain.com        CNAME    nlb-sub.amazonaws.com
nlb-sub.amazonaws.com   A        <some-ips>

We use Let's Encrypt to provide a cert for the sub domain sample1.clientA.com. Note we currently have no CAA records in place ourselves.

However one of our clients, i.e. clientA has two restrictive CAA records in place for their root domain

clientA.com      CAA  0 issuewild   "ca1.com"
clientA.com      CAA  0 issue       "ca1.com"

Currently, Let's Encrypt cannot issue a cert for sample1.clientA.com. It returns a 403 error:

CAA record for sample1.clientA.com prevents issuance.

More than likely because of the restrictive CAA records.

Should we ask our client to set up a permissive CAA record for its root domain? Or, given that CAA validation follows CNAMEs like all other DNS requests, should it be put on the nlb-sub.amazonaws.com subdomain?

We are not using Route53 and AFAIK our DNS provider does not support ALIAS records.


Yes, CAA records for subdomains are allowed and override CAA records for the domain. If a CNAME exists for the subdomain, the CNAME will be followed, and any CAA record for the alias used instead. RFC 6844 § 4 explains these rules in depth with an example.

So you should be able to take care of this yourself by adding a CAA record for clientA.our-domain.com.

AFAIK Let's Encrypt handles such CAA records correctly, but if you still have a problem, you should contact their community support forum.

  • If we add the CAA record for clientA.our-domain.com. Should we also be putting CAA records on our root domain our-domain.com as we use a wildcard certificate on our root domain for those clients that aren't in need of vanity URLs? – Luuk Aug 1 '19 at 0:41
  • @Luuk That's up to you. It's also a completely separate unrelated issue to this. – Michael Hampton Aug 1 '19 at 1:30
  • Thanks @Michael. I am just confused, before I raised this question, we actually added a CAA record for clientA.our-domain.com. However from that point onward both sub1.clientA.com and clientA.our-domain.com stopped working. I wonder now if there was a local DNS caching issue. – Luuk Aug 1 '19 at 1:51
  • The new RFC (8659) slightly changes things: you still climb to the root as needed, but stopping if encountering CNAME. See section 7: "This document specifies a simplified processing algorithm that only performs tree-climbing on the FQDN being processed, and it leaves the processing of CNAMEs and DNAMEs up to the CA's recursive resolver." – Patrick Mevzek Nov 23 '19 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.