CAA record for prevents issuance

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: sudo certbot certonly --force-renewal --webroot -w /var/www -d ""

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Using the webroot path /var/www for all unmatched 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): Openresty

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

My hosting provider, if applicable, is:

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.26.1

I am trying to get a certificate for this domain but i am getting the above caa failed issuance error . I dont know how to fix the issue . Please help me to get this fixed .

Please don't use this option. When something is wrong with issuance, it doesn't force issuance by suddenly making the error go away. It however can cause you to run into rate limit if you keep forcing issuance, but the problem is for example with installing a certificate. Therefore, this option is best not to be used.

That said, the problem is with the CAA record of 300 IN CAA 0 issue ""

When quering the CAA records to check if Let's Encrypt is allowed issuance for the hostname, it will check the parent DNS zone of the hostname if there is no CAA found.

Three solutions exist:

  • Change the CAA record for zone to also include Let's Encrypt, or;
  • Delete the CAA record for zone altogether so any CA can issue for the domain, or;
  • Add a CAA record allowing Let's Encrypt to the hostname.

See also the CAA documentation page from Let's Encrypt, which also links to other useful resources for it:

But the core of the issue is that if the domain is specifically configured by the DNS owner to not allow Let's Encrypt, then Let's Encrypt can't work for it.


I'm guessing, based on the fact that you don't seem to have familiarity with CAA records and that the name you give is a CNAME to another domain entirely, that you're running a service of some sort where you expect your customer to just add the CNAME to you and that you run the whole server. If that's the case:

  1. Because the rest of the certificates for this name are OV certificates from Entrust, your customer might be expecting all their certificates to be from that vendor (which is why they put the CAA record in the first place). They may prefer you to be sending them CSR files for them to get certificates for rather than you getting certificates yourself. It's probably best for you to coordinate with their IT department how they're expecting things to work.
  2. The easiest "solution" for you (though like I said whether or not your customer wants it this way may be another story) is probably for you to add your own CAA record for the name that your customer CNAMEs to (not just for this customer, but probably for all of them), allowing for "". That will allow you to automatically get a certificate from Let's Encrypt and "override" the higher-level domain record. (CAA is checked from the full domain name, and then if there's no record checking the name with the first part removed, and so forth until at the root, at which case if there's no CAA at all it's presumed to be allowed.)

Most, if not all, of that requires DNS control over (potentially) customer domains.
That probably won't scale very well.
For these types of problematic situations, have you considered also offering a subdomain of one of your business domains specifically for your customers' use?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.