Skip to content

CAA Violation: Certificate Not Authorized

Key idea:

CAA (Certificate Authority Authorization) violation — the domain's DNS CAA record does not permit the specified CA to issue a cert. Let's Encrypt, DigiCert and others check CAA before issuance. If CAA says "only digicert.com" and you request from Let's Encrypt — refuse. Fix: add the CA to CAA or remove the CAA record.

Below: causes, fixes, FAQ.

Check your site's SSL →

Common Causes

  • DNS CAA permits only a specific CA (e.g. digicert.com) while you use Let's Encrypt
  • CAA wildcard (issuewild) does not authorise CA for wildcard certs
  • iodef CAA with a wrong email — CA can't notify
  • CAA with ; in value — syntax error, effectively "no CA allowed"
  • Propagation not complete — stale CAA still cached

Step-by-Step Fix

  1. Check current CAA: Enterno DNS → CAA type
  2. Add the CA to CAA: example.com. IN CAA 0 issue "letsencrypt.org"
  3. For wildcards: example.com. IN CAA 0 issuewild "letsencrypt.org"
  4. Full example: CAA research
  5. Wait 24h after CAA update (propagation)

Check SSL Certificate →

Related SSL Errors

TL;DR: Understanding CAA Violation Error

The CAA Violation Error occurs when a Certificate Authority (CA) issues a certificate for a domain without proper authorization, violating the Certificate Authority Authorization (CAA) DNS record. To resolve this, ensure that your domain's CAA records explicitly list the CA you intend to use. Use the command dig CAA yourdomain.com to check your current CAA records.

What is a CAA Violation Error?

The CAA Violation Error arises when a certificate is issued for a domain without the necessary permissions defined in the domain's CAA records. CAA records are a DNS resource record that allows domain owners to specify which Certificate Authorities are permitted to issue certificates for their domain. This mechanism enhances security by preventing unauthorized issuance of SSL/TLS certificates.

When a Certificate Authority receives a request for a certificate, it checks the CAA records for that domain. If the CA is not listed in the records, it will reject the request, leading to the CAA Violation Error. This can manifest in various ways, including browser warnings or SSL handshake failures.

For example, if your domain example.com has a CAA record that only allows letsencrypt.org to issue certificates, any request to issue a certificate from digicert.com will trigger a CAA Violation Error. The specific DNS record might look like this:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"

In this case, the CA must be listed in the CAA record for the certificate to be authorized.

How to Fix CAA Violation Errors

To resolve a CAA Violation Error, you need to ensure that your CAA records are configured correctly. Follow these steps:

  1. Check Your Current CAA Records: Use the following command to check your CAA records:
dig CAA yourdomain.com

This command will return the current CAA records for your domain. Look for records that specify which CAs are authorized to issue certificates.

  1. Modify Your CAA Records: If the CA you wish to use is not listed, you will need to add it. This is done at your domain registrar's DNS management interface. For example, to allow digicert.com and letsencrypt.org to issue certificates, your CAA record should look like this:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"

Note: You can specify multiple CAs by adding additional CAA records. Make sure to follow the correct syntax as per your DNS provider's requirements.

  1. Verify the Changes: After updating your CAA records, wait for the DNS changes to propagate (this can take up to 48 hours) and then recheck with the dig command. Ensure that your desired CA is listed correctly.

Once the correct CAA records are in place, you can attempt to reissue the SSL certificate. If the CAA records are configured correctly, the Certificate Authority should issue the certificate without triggering the CAA Violation Error.

In conclusion, the CAA Violation Error is an important security feature that helps prevent unauthorized certificate issuance. By ensuring that your CAA records are accurate and up-to-date, you can avoid this error and maintain a secure web presence.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

Frequently Asked Questions

I don't need CAA — what now?

Remove all CAA records. Any CA may issue. CAA is optional — no constraints by default.

Who checks CAA?

The CA before issuance (mandatory for public CAs since 2017). Browsers do not check CAA.

Is iodef CAA mandatory?

No. iodef is an email for notifications on mis-issuance attempts. Useful but optional.

How to check CAA?

<a href="/en/dns">Enterno DNS</a> → CAA type. Or <code>dig CAA example.com</code>.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.