Fail on CAA record for domain without CAA record


Hi Letsencrypt team -

I’m trying to provision a cert for my home nextcloud (snap) instance at (cname to, dynamic DNS for my home), using the certbot built into nextcloud.

My domain is:

According to I don’t have a CAA record on the child or parent domain, of either domain ( or My domain is hosted on, which doesn’t allow me to (easily) set a CAA record. Dig just returns the SOA record.

Thanks in advance for your help!

According to the debug log, I ran certbot with these arguments: [’–text’, ‘–config-dir’, ‘/var/snap/nextcloud/current/certs/certbot/config’, ‘–work-dir’, ‘/var/snap/nextcloud/current/certs/certbot/work’, ‘–logs-dir’, ‘/var/snap/nextcloud/current/certs/certbot/logs’, ‘–authenticator’, ‘nextcloud:webroot’, ‘–nextcloud:webroot-path’, ‘/var/snap/nextcloud/current/certs/certbot’, ‘–rsa-key-size’, ‘4096’, ‘–email’, ‘’, ‘–non-interactive’, ‘–agree-tos’, ‘–force-renewal’, ‘-d’, ‘’]

It produced this output:

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Using the webroot path /var/snap/nextcloud/current/certs/certbot for all domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:caa :: CAA record for prevents issuance
 - The following errors were reported by the server:

   Type:   None
   Detail: CAA record for prevents issuance

My web server is (include version): nextcloud snap’s built-in Apache

The operating system my web server runs on is (include version): Ubuntu 18.04 server LTS

My hosting provider, if applicable, is: Me. :slight_smile:

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no


Updated to use a simple A record, and it works! Did I miss some critical documentation or something? What was wrong with the CNAME?


The problem isn’t with Dyn or (directly) with your domain, it’s with TP-Link.

The error message is misleading: it happens when you have CAA records explicitly blocking Let’s Encrypt, and it can happen when the DNS response is invalid.

When Let’s Encrypt’s does a DNS query for CAA, the DNS resolver follows the CNAME to and… I’m not sure what happens. has a lot of issues. I’m not even sure what most of them are.

$ dig caa
;; Got bad packet: FORMERR
67 bytes
88 dc 81 80 00 01 00 01 00 00 00 01 08 76 65 72          .............ver
74 68 6f 6d 65 09 74 70 6c 69 6e 6b 64 6e 73 03          thome.tplinkdns.
63 6f 6d 00 01 01 00 01 c0 0c 01 01 00 01 00 00          com.............
02 6c 00 04 5b 41 76 ba 00 00 29 10 00 00 00 00          .l..[Av...).....
00 00 00                                                 ...

One of them is responding with something invalid to CAA queries.

Another is that they don’t support random capitalization, which is not invalid, but which may cause Let’s Encrypt’s resolvers to fail.

Not really. CNAMEs are okay. You were just using a CNAME to a DNS service that doesn’t work well.


To be explicit, it’s fine not to have CAA records. A valid negative response is a-ok.

Also, I forgot to mention it, but there was one previous thread reporting issues with that domain.


Thank you for the fast, thorough and clear response.

Now I like letsencrypt EVEN MORE. You people are awesome.