CAA Records for Let's Encrypt: Wildcard Certificates, Testing, and Fixes

Anyone can ask a public certificate authority (CA) for a certificate for your domain, and by default every public CA is allowed to answer. A CAA record in DNS lets you say which CAs may issue for your domain. In this guide, we will set up CAA Records for Let's Encrypt, issue normal and wildcard certificates, test how inheritance works, and break issuance on purpose to see the error.

Before you start to configure CAA records for Let's Encrypt, make sure you have the items below ready: 

• A domain name you control.
• A DNS provider that lets you add CAA records.
• An Ubuntu 26.04 LTS server or 24.04 with a public IP and ports 80 and 443 open.
• A user with sudo access.
• An API token from your DNS provider for the wildcard test. We use Cloudflare as the example.

Also, you must update the server and install the required tools:

Once you are done, proceed to the following steps to complete the setup.

Certbot is the tool that asks Let's Encrypt for your certificates and renews them for you. In this step, you must install it with Snap, which keeps it up to date.

Remove any old Certbot from apt, then install it with the snap:

Now it is time to tell the world that only Let's Encrypt can issue certificates for your domain (example.com). In this step, you must add three CAA records at your DNS provider, including issue, issuewild, and iodef. Use a low TTL for now so any changes you make show up quickly while you test.

If your DNS panel has only one box for the whole record, you can use this format:

Some DNS panels want only letsencrypt.org in the value box, with no quotes. Do not add https:// or any extra text. A wrong name will block issuance.

If you use more than one CA, add one more issue line for each CA. For example: 0 issue "digicert.com".

If you never want wildcard certificates, use this line instead of the issuewild line above:

A single semicolon means "no CA is allowed."

Your CAA records are now in DNS, but you need to check that the world can see them. You can use the dig command to look up your records. First, ask your normal resolver:

In the output, you should see all three records:

Then, ask a public resolver and your own authoritative name server. The CA asks your authoritative servers, so they matter most:

Replace ns1.your-dns-provider.com with one name from the NS output. All answers should match. If you get no answer, wait for the TTL and try again.

Also, you must check the status of the reply with the command below:

The status should be NOERROR. A SERVFAIL status is a problem. Let's Encrypt cannot issue a certificate when the CAA lookup fails because it cannot tell whether a record is hidden by the error.

If you turned on DNSSEC, your CAA answers are signed with the rest of the zone. A broken DNSSEC setup is the most common cause of SERVFAIL for CAA. Check it with:

Look for the ad flag in the header line. It means the resolver validated the answer. If you have not set up DNSSEC yet, you can follow our DNSSEC and WAF configuration guide.

Let's Encrypt staging has much higher limits and issues certificates that browsers do not trust. Always test here.

First, make sure Nginx is running and serves the default folder /var/www/html:

Then, request a test certificate. We use a separate certificate name so it does not mix with the real one later:

Both names must point to this server in DNS. When it works, Certbot saves the files in /etc/letsencrypt/live/test-http/. Check the issuer with:

The issuer name contains STAGING. That proves the CA checked your CAA records and issued.

Let's Encrypt only issues wildcard certificates with the DNS-01 challenge. Certbot needs a DNS plugin for this. You must pick the plugin for your DNS provider.

This guide uses Cloudflare. Install the plugin with the commands below:

Create an API token in Cloudflare with the Zone: DNS: Edit permission for your zone. Then, create the credentials file:

Next, request a test wildcard certificate with the following command:

Add both example.com and *.example.com. The wildcard does not cover the main domain by itself. Now check the names inside the certificate:

The CA checks the name you ask for. If that name has no CAA record, it moves up one level and repeats until it finds a CAA record. It stops at the first one it finds.

For www.app.example.com, the CA checks in this order:

• www.app.example.com
• app.example.com
• example.com

You can see this with dig. The subdomain has no record of its own, so the answer is empty. That is normal:

The CA ignores the empty answer and uses the record on example.com.

A subdomain can have its own CAA rule. The CA always uses the closest record, so a subdomain record replaces the main domain rule for that name only. In this step, you can add a different rule for api.example.com. Add this record at your DNS provider:

Then, use the following dig command to check it:

Now only DigiCert can issue for api.example.com, and Let's Encrypt is blocked there. The rest of the domain stays on Let's Encrypt. If you still want Let's Encrypt on that subdomain, add both issue lines. Remove the test record when you are done.

CAA checks follow CNAME records like any DNS lookup. If blog.example.com is a CNAME to host.other-provider.net, the CA reads the CAA record at host.other-provider.net. A name with a CNAME cannot hold other records, so you cannot add CAA on that same name. You must put the allow rule on the target or on a higher level of the original name.

At this point, you can see what happens when a CAA record is too strict. You must change your records so that only DigiCert is allowed, then try to get a certificate from Let's Encrypt. The request will fail, and you will see the error that Certbot shows.

First, remove the Let's Encrypt issue line and add:

Wait for the TTL, about 5 minutes, then confirm with dig command:

Then, you must run a dry run. A dry run uses staging and does not save anything:

You must see that the request fails. The CA error looks like this: Detail: CAA record for example.com prevents issuance.

In the ACME error, the type is urn:ietf:params:acme:error:caa. The message may appear when Certbot checks the domain, or later when it finishes the order. See the full log if you need it:

Renewals also fail the same way. Run this, and you will see the same error for each certificate:

Another common mistake is a block on wildcards only. Put the Let's Encrypt issue record back, and change issuewild to a semicolon:

Normal certificates work, but the wildcard fails:

The wildcard name is refused because issuewild overrides issue for wildcards.

Most CAA errors come from a few small mistakes. Check the list below when Certbot says a CAA record blocks issuance:

• The wrong CA name, like letsencrypt.com instead of letsencrypt.org.
• Extra text in the value, like https://letsencrypt.org.
• Another CAA record on a subdomain that does not list Let's Encrypt.
• An old CAA record from your hosting provider or DNS template.
• SERVFAIL or a timeout from your DNS server, often caused by broken DNSSEC or a firewall that drops unknown query types.

Now let's fix the records and make sure everything works again. You can put the correct CAA records back, wait for the old TTL to pass, and run the tests again. Both dry runs should pass. 

First, set the final records, with a normal TTL of 3600:

Wait for the old TTL to pass, then check with dig and repeat both dry runs. They should now pass:

This step is optional, but it adds strong protection. You can lock your CAA records to your own ACME account. Then, only your account can get certificates for your domain, even from Let's Encrypt. Do this last, after your real certificate works.

First, issue the real certificate from the next section. Then get your account URL:

The account URL looks like https://acme-v02.api.letsencrypt.org/acme/acct/1234567890. Change the issue and issuewild records to this form:

Staging uses different accounts, so staging tests will fail after this change. Always test first, and keep a note of the account number.

Also, you can limit the challenge type with ;validationmethods=dns-01. Let's Encrypt supports http-01, dns-01, and tls-alpn-01 here.

Once your tests have passed, you can get the real certificate. First, you must delete the staging test certificates:

Then, request the real certificate. This is the same command as the wildcard test, without --staging:

Finally, check that it was issued with the following command:

Your certificate is ready, so now you need to tell Nginx to use it. First, use the command below to create the site file:

Then, use the following commands to enable it, test the config, and reload:

Finally, use the command below to check that your site shows the new Let's Encrypt certificate:

Let's Encrypt certificates are short-lived, so renewal must run on its own. The Certbot snap sets up a systemd timer that runs renewals twice a day. Check it with:

Certbot renews a certificate when only one third of its life is left. Nginx must reload after each renewal, so you must add a deploy hook. After a successful renewal, Certbot runs every executable file in this folder:

Next, run a dry run to test the full process, including the CAA check:

Let's Encrypt is making certificates shorter. The default lifetime drops to 64 days on February 10, 2027, and to 45 days on February 16, 2028. The time that a past domain check can be reused is also getting shorter.

In practice, your DNS credentials and CAA records will be checked on almost every renewal. Run sudo certbot renew --dry-run after every DNS change, and keep a monitor on dig for your CAA records. A quick monitor script:

You can run it from cron or your monitoring tool.

CAA Records for Let's Encrypt give you a simple safety lock for certificate issuance. You have learned to add issue, issuewild, and iodef records, check them with dig, issue test and wildcard certificates. You saw how a record that is too strict stops ACME. Always test with staging and certbot renew --dry-run after any DNS change.

If you are ready to lock down your own domain, you can register a domain with PerLod and limit certificate issuance to the CAs you trust.

We hope you enjoy this guide. For more detailed information, you can check the Let's Encrypt CAA Docs.