How to Fix ACME SSL Certificate Errors

When you’re setting up or renewing SSL certificates using the ACME protocol, it’s not unusual to run into cryptic errors that stop the process in its tracks. This guide walks you through the most common ACME-related issues, explains what they actually mean, and shows you exactly how to fix them. Whether you’re installing a new certificate, automating renewals, or debugging a failed validation, this is the place to start.

---

External Account Binding Missing or Invalid

This error shows up when the ACME server requires External Account Binding (EAB), but your client didn’t send valid credentials or skipped them entirely. EAB is a way to prove that you’re allowed to use a particular ACME server.

How to fix it:

1. Double-check your Key ID and HMAC key: Make sure both are correct and exactly as provided. No hidden spaces or line breaks.
2. Use the correct ACME Directory URL: Some clients let you pass –server. Don’t mix up production and staging URLs.
3. Add the EAB flags: If you’re using acme.sh, the flags should look like this: –eab-kid –eab-hmac-key
4. Update your ACME client: If the client is outdated, update it. Newer versions have better EAB support.

---

Account Does Not Exist

The urn:ietf:params:acme:error:accountDoesNotExist error appears when your ACME client tries to use a local account key (the one stored in its configuration folder) that the CA doesn’t recognize.

In plain terms, your ACME client is referencing an account that doesn’t exist or was deleted on the CA’s end. It’s common when you reinstall the client, move servers, or switch between staging and production endpoints.

How to fix it:

1. Re-register your ACME account: Use your correct external account binding (EAB) credentials when registering.
Example for acme.sh:

acme.sh --register-account \
--server https://acme.your-ca.com/v2/DV \
--eab-kid YOUR_EAB_KID \
--eab-hmac-key YOUR_EAB_HMAC_KEY \
--accountemail [email protected]

2. Check the ACME server URL: Make sure you’re registering with the correct endpoint that matches your order.

3. Avoid reusing account files: Don’t move account.conf or account keys between servers or clients unless you’re 100% sure they’re valid for the same CA and environment.

---

Bad Nonce or Anti-replay Error

Your ACME client sent a request using a nonce (a one-time token from the CA) that was already used, expired, or invalid. The server blocks it to prevent replay attacks. The urn:ietf:params:acme:error:badNonce is usually a temporary issue caused by bad timing, delayed requests, or clock mismatch.

How to fix it:

1. Just retry the request: Most ACME clients (like acme.sh) will automatically retry when they get a badNonce error. If not, re-run your last command manually. It should work on the second attempt.

2. Sync your server clock: A skewed system time can cause replay errors. Run:

timedatectl status
timedatectl set-ntp true

Or ensure ntpd or chronyd is running properly.

3. Check for proxy or CDN delays: If you’re behind Cloudflare, a load balancer, or a slow proxy, it might delay your requests enough to invalidate the nonce. Try bypassing it temporarily.

---

A Requested Identifier Has Not Been Delegated

When the urn:ietf:params:acme:error:rejectedIdentifier error pops up, the ACME server rejected one or more of the domain names you tried to validate. It’s usually because:

• The domain doesn’t exist in public DNS
• There’s no DNS record pointing to your server
• The domain isn’t authorized for certificate issuance

Put simply, the CA can’t verify you own or control that domain.

How to fix it:

1. Use the correct format in your command: Only include the domain name. no protocol, slashes, or full URLs.

• Correct: -d example.com
• Wrong: -d http://example.com

2. Check that the domain exists and resolves. Run:

dig example.com +short

If there’s no output, your domain isn’t live yet, fix your DNS settings first.

2. Match your ACME order: If you’re using a commercial ACME certificate, ensure the domain you’re issuing for is listed on the original order. You can’t add domains on the fly. It has to be pre-approved.

3. Watch out for typos and subdomain mixups: Double-check things like www.example.com vs example.com. These are treated as separate entries.

---

Unauthorized or Invalid Response

The certificate authority couldn’t verify your domain ownership. Most often, it couldn’t access the ACME challenge file that your client placed on the server. This is an HTTP validation issue: the CA tried to reach your site, but couldn’t find or read the challenge.

The exact error message is urn:ietf:params:acme:error:unauthorized. It may also appears as: “Invalid response from http://yourdomain.com/.well-known/acme-challenge/…”.

How to fix it:

• Emsure your server is reachable on port 80 (even if your site normally redirects to HTTPS).
• Double-check the webroot path in your ACME client config. The challenge files must be written to: /.well-known/acme-challenge/.
• If your server forces HTTPS redirects, temporarily allow plain HTTP requests for that path.
• Disable CDNs, reverse proxies, or firewalls that might interfere with external HTTP validation from the CA.
• Check file permissions and confirm that the challenge file is actually being created and publicly accessible.

---

Token Not Found or File Not Reachable (404 or 403)

The ACME server tried to fetch the HTTP challenge file, but got a 404 (Not Found) or 403 (Forbidden) response. This means the file either wasn’t placed correctly, isn’t publicly accessible, or your web server is blocking access.

Exact error messages may vary. Here’s what you can expect to see:

• Invalid response from http://yourdomain.com/.well-known/acme-challenge/… [404]
• Invalid response… [403 Forbidden]
• urn:ietf:params:acme:error:unauthorized

How to fix it:

Check the document root for the domain and make sure it matches where the ACME client is placing the file: /.well-known/acme-challenge/

Confirm the token file exists and is reachable from a browser. You should be able to open the challenge URL directly in your browser and see the token content.

Set correct file permissions: the ACME challenge file and its parent folders must be world-readable.

If you’re using .htaccess rules, firewalls, or security plugins (like on WordPress), make sure they’re not blocking access to the /.well-known/ path.

If you get 403, also check file ownership and SELinux/AppArmor restrictions if applicable.

---

CAA Record Forbids Issuance

Your DNS has a CAA record that restricts which certificate authorities can issue certificates for your domain. If the CA you’re trying to use isn’t listed, they’re blocked by default. You may see the following error message: urn:ietf:params:acme:error:caa

This is a DNS-level policy, not a server problem. CAs are required to check CAA before issuing any cert.

How to fix it:

Check your domain’s DNS zone for CAA records. You can use online tools or the dig command:

dig CAA yourdomain.com

If there’s no CAA record, any CA can issue. But if there is one, make sure it includes the exact name of your certificate provider like:

• 0 issue “sectigo.com”
• 0 issue “digicert.com”

If you’re using a wildcard certificate, also add the issuewild line: 0 issuewild “sectigo.com”

Wait a few minutes for DNS propagation, then retry the ACME order. If you’re unsure, remove the CAA record temporarily to test issuance, but only if you’re managing the DNS securely.

---

TXT Record Not Found (for Wildcard Certificates)

Wildcard certificates (like *.example.com) require DNS-01 validation, the only method allowed by all CAs for wildcard domains.

DNS-01 works by asking you to create a special TXT record in DNS: _acme-challenge.example.com

If this record is missing or hasn’t propagated yet, you’ll get this error.

Error examples:

• urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com
• TXT record not found for _acme-challenge.example.com

How to fix it:

In your DNS provider, create a TXT record:

• Name: _acme-challenge.example.com
• Value: (the token your ACME client gives you; unique per request)

Wait 1–10 minutes for DNS to propagate. Some providers take longer. Confirm with the following command.

dig TXT _acme-challenge.example.com

You can also use an online an online DNS lookup tool. Once visible, retry validation.

---

Too Many Requests or Rate Limit Exceeded

The error appears as urn:ietf:params:acme:error:rateLimited or 429 Too Many Requests when the ACME server is refusing to process your request because you’ve hit a rate limit.

This usually happens when you request too many certificates for the same domain(s) in a short period or you send too many failed requests in a row.

How to fix it:

Most rate limits reset automatically after an hour, a day, or a week depending on what you hit. If using a script, check logs and fix errors before retrying. Don’t brute-force blindly, it just worsens the lockout.

For DNS-01 validations, avoid rapid re-requests after small TXT record mistakes. Wait for DNS propagation. If your CA provides a rate limit status page or headers, check those for more precise reset times.

---

DNS Errors or Lookup Failures

If you get messages like “DNS problem: NXDOMAIN looking up A for example.com” or “Temporary failure in name resolution“, it means the ACME server couldn’t resolve your domain name, either because the domain doesn’t exist, isn’t propagated yet, or has no valid IP records.

The certificate authority relies on DNS to verify that your domain exists and points somewhere real. If it can’t reach your A (IPv4) or AAAA (IPv6) records, it will stop the validation process.

This can happen if:

• Your domain is brand new and DNS hasn’t fully propagated
• You forgot to add the right DNS records
• You’re working in a local or internal network with no public DNS visibility
• There’s a typo in the domain name you submitted

How to fix it:

• Double-check that your domain has valid A or AAAA records pointing to your live server.
• Use tools like dig, nslookup, or online checkers (e.g. whatsmydns.net) to confirm propagation.
• Make sure you’re not using a private or internal-only domain. ACME validation only works for publicly resolvable names.
• Wait a few minutes after DNS changes; they don’t always go live instantly.

---

Could Not Connect to ACME Server

This error appears when your server can’t reach the ACME API endpoint. It may show up as Connection refused, Timeout during connect, Could not connect, or similar messages depending on the ACME client.

How to fix it:

• Ensure sure your server allows outbound HTTPS connections on port 443.
• Check firewall settings or outbound network rules (especially in cloud/VPS setups).
• If you use a proxy, allow traffic to the CA’s ACME server domain.
• Confirm your server has a working DNS resolver.
• Test connectivity with: curl https://acme.example.com (replace with your CA’s real endpoint).
• Restart your ACME client after resolving network issues.

---

Post-renewal Script Failed

This error shows up after a successful certificate renewal when the follow-up script meant to reload your web server or service didn’t run properly. Depending on your ACME client, you might see messages like “post-hook error”, “deploy script failed”, or “command not found”.

How to fix it:

• Run your post-renewal script manually to see what breaks.
• Check file paths, especially for the new cert and key.
• Make sure the script has execution permissions (e.g., chmod +x script.sh).
• Look for typos, missing dependencies, or wrong command syntax.
• If you’re using a deploy hook or post-hook, confirm the client supports it and it’s configured properly.

---

Final Words

We’ve covered the most common ACMS SSL certificate errors and gave quick fixes. If none of these resolve your issue, run your ACME client in debug mode. Most clients will give more detailed output when you enable logging. That information can help identify the real cause and get your SSL working again.