Is DNS record for 'acme-challenge' required?

I've received an email concerning a client domain.

zacksf****.com (checked on May 19, 2024 at 8:11:17 PM UTC)

MASTER DCV: 400 urn:ietf:params:acme:error:connection (The server could not connect to a validation target) (During secondary validation: Fetching http://zacks***.com/.well-known/acme-challenge/SsbBhqqXrw7NZP7bmwKyNLI: Timeout during connect (likely firewall problem)) 403 urn:ietf:params:acme:error:unauthorized (The client lacks sufficient authorization) (Incorrect TXT record "wSR************************-Xr5ghme8Ay0" found at _acme-challenge.zack***.com)

Is Let's Encrypt now requiring a '_acme-challenge' DNS record?

One caveat. This is a new version of the website on WordPress platform whereas the SSL certificate might be pointing to the old Joomla website. I see two records in the 'acme-challenge' folder. I'm not sure which one is used.

So would it work if I put a record for ' wSR*****************************' in the 'acme-challenge' folder to match up with the current DNS record?

No, that's not usually needed.

What instructions are you following?


Well, I created a DNS record but it was for the wSR*** code. There is not a file with that beginning wSR** in the acme-challenge. There are two files in the 'ace-challenge' folder. I could simply create a new file for wSR** in the folder with the expanded code which I see in the other two files as they have identical extensions at the end the folder name so it would be easy to created.

Are 'all' files checked to ensure at least one matches up with the DNS record? if so, this might be the simplest solution.

The ACME client you're using might be falling back to the dns-01 challenge when it detected the http-01 challenge wasn't working.

The "Timeout during connect (likely firewall problem)" error suggests your website does not have HTTP port 80 open. Try fixing that and try again.


There are 2 main ways to obtain a LetsEncrypt certificate:

  1. HTTP-01 Challenge - LetsEncrypt loads a specific URL from port 80 on your server (or follows a redirect)

  2. DNS-01 Challenge - LetsEncrypt loads a specific TXT record from your DNS servers (or follows a CNAME onto another server)

With each method, the record uses for the challenge changes on the renewal.

Your ACME client will use either the HTTP-01 or DNS-01 challenge to authenticate; this is a user option. If your client fails one authentication method, the ACME server is required to fail the entire ACME order - so you must submit a new order (with the client configured to use the other challenge type).

In your case, you can safely remove all the TXT records (unless you CNAME onto another DNS service, they are ephemeral and only needed for the validation; most clients now delete them during a "cleanup" after validation) and either start a new order with the DNS-01 challenge or the HTTP-01 challenge.



Thanks for explaining the process. I am using WHM/C-Panel so in the past when I encountered these issues, I would simply go to the AutoSSL, select the domain and either do a 'check' or a forced enable. This has worked fine in the past. However, HostGator tech support indicated that it was a timeout issue which typically resolves itself. Is my method sound?

1 Like

The most likely problem is that you are blocking geographically. Let's Encrypt recently changed their http validation to validate from additional regions, so if you try to block/allow on specific IP ranges validation will probably fail.


I added these URL's to the csf.dyndns file. I deleted the expired SSL certificates and then checked the domains that were expired. All websites loaded. I guess adding these URL's to the whitelist solved the issue.

No. The IPs used by the validating servers are not the same as the API infrastructure.

You can see that for yourself by looking the IP for those domains. And compare that to the IP on the HTTP Challenge requests that show up in your server access logs. They won't be the same.



Then I guess adding Singapore SG code to the firewall country whitelist must have done it.

If you're trying to block by country, you will likely continue to have issues when your certificates need to be renewed. The countries are likely to change over time.



That is bad. Server security procedures for some host providers means blocking many countries where hacking attempts are being made.

I block most countries on my server which has 'dramatically' reduced hacking attempts over the years, even with ConfigServer excellent settings. I am in a little bit of a different situation as I only have a couple of websites which truly needs countries outside of the U.S. All of my websites use Cloudflare for website access which provides access to all. I whitelist Cloudflare's IP's. This allows another layer of security. If LetsEncrypt changes their provider servers often to multiple countries, that will be problematic for many hosting providers.

Yes, this. Adding Sweden would be good idea too. If you only support Singapore and USA you are already "failing" one location. Right now only one failure is allowed so your renewals are more vulnerable to temp failures.

Many people have used geo blocking to allow USA-only and gotten away with it. This was never best practice and LE has long had a non-USA validation center (now they have two and in different countries than before). Such geo-blocking doesn't add any security. Although I agree it eliminates a fair number of nuisance probes.

You should read Peter's wiki post that he linked to. Let's Encrypt is not unique in doing this and will (almost certainly) be included in the CA/B forum Baseline Requirements soon.

I've linked to the topic in that wiki that speaks to this but the entire thread is an excellent description of the whats and whys of this.



I've added Sweden SE code.

1 Like