Error Getting Validation Data

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: certbot renew --dry-run

It produced this output:
http-01 challenge for
Waiting for verification...
Challenge failed for domain


My web server is (include version): Apache/2.4.18

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

My hosting provider, if applicable, is: Ubuntu 16.04

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 1.14.0

Port 80 is open but here I get the following findings:

Fatal: Check of /.well-known/acme-challenge/random-filename is blocked, http connection error. Creating a Letsencrypt certificate via http-01 challenge can't work. You need a running webserver (http) and an open port 80. If it's a home server + ipv4, perhaps a correct port forwarding port 80 extern ⇒ working port intern is required. Port 80 / http can redirect to another domain port 80 or port 443, but not other ports. If it's a home server, perhaps your ISP blocks port 80. Then you may use the dns-01 challenge. Trouble creating a certificate? Use to ask.

Can anyone please guide?

Thank you.


Hi @DexterD891

please read your error message.

There is no valid http answer. Instead:

ConnectionClosed - The underlying connection was closed: The connection was closed unexpectedly.

So your configuration is buggy -> fix that.


Hi @JuergenAuer,

Thanks a lot for the quick response. I used Letsencrypt to make a certificate for the first time in January, and it worked perfectly when port 80 was allowed. Now with the same configuration, it is not working. Can you please guide, where should I look?

Thank you.


It's not the same configuration, your port 80 doesn't work.

And you have to find the reason and to fix it. It's your system.

1 Like

I can successfully telnet port 80 from external network. Nmap scan also reveals port 80 to be open.


The port may be "open", but the server (or a firewall or the like) closes the connection before any HTTP reply is sent.

$ curl -v
*   Trying
* Connected to ( port 80 (#0)
> GET /.well-known/acme-challenge/test HTTP/1.1
> Host:
> User-Agent: curl/7.61.1
> Accept: */*
* Empty reply from server
* Connection #0 to host left intact
curl: (52) Empty reply from server
1 Like

Welcome to the Let's Encrypt Community :slightly_smiling_face:

I concur with my colleagues.

Dear All,

Thanks for your inputs. I think firewall rules were ok, but i could not find what the problem with my apache was. But luckily found a workaround. used the certbot certonly --standalone after stopping apache, and certificate was renewed without a problem.

1 Like

That might be a workaround for getting a certificate, but doesn't fix your general Apache webserver problem.

For example, if (new) users go to your site by typing the address in the address bar without explicitely using https://, they'll get the same "Empty response" error in their browser as shown above. Only by explicitely typing https:// users will be able to go to your site.


I agree with you. I tried to find the problem with Apache but was unable to do so. I would still welcome suggestions/help for troubleshooting.

1 Like

Let's start with showing the complete output of:

sudo apachectl -S

Please put 3 backticks on the lines above and below the output like this:


That error

ConnectionClosed - The underlying connection was closed: The connection was closed unexpectedly.

via http isn't an Apache problem. Looks more like a blocking firewall or a .htaccess.

Connection created -> ip checked -> connection closed.

I agree that it does look that way, but if running in --standalone mode works then that implies that it's something specific to Apache (though again, I can't imagine how, as I haven't heard of an Apache config line for "just close the connection rather than responding"). Some kind of local firewall that knows how to hook into Apache but not into certbot's standalone mode?

1 Like

.htaccess, failban, a lot of tools are possible. Or the firewall uses (like Windows) the .exe program -> standalone is another source.

Should be a thing of one minute to find that.

PS: Simple sample. There runs an Apache under Ubuntu. But is that an own Ubuntu?

Yep - the ip is a - ip IP Address | Geo IP Lookup, so it's not a datacenter, it's a home server.

Runs that Ubuntu in a Windows?

And why is now no answer? Something has changed.

1 Like

That was my conclusion as well. I just didn't know where else to begin.

When an HTTP connection is made and the connection closes, is there anything interesting in the Apache log files? I think they're usually in /var/log/httpd but there are a lot of ways to have Apache installed and configured.

1 Like

apachectl -S
VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
         port 80 namevhost (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
         port 80 namevhost cloud.localdomain (/etc/apache2/sites-enabled/000-default.conf:1)
*:*                    cloud.localdomain (/etc/apache2/sites-enabled/default-ssl.conf:2)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/lock/apache2" mechanism=fcntl
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
PidFile: "/var/run/apache2/"
User: name="www-data" id=33
Group: name="www-data" id=33

1 Like

Hi Juergen,

It is a Ubuntu running on a virtual machine. I also checked via TCP dump for port 80, and could not see anything abnormal
There is no fail2ban implemented. Now after the certificate renewal, port 80 has been blocked again.

1 Like

Hi @petercooperjr

nothing unusual in the access or error logs. May be the log level should have been set higher to see in detail.

1 Like

I could see the follwoing in .htaaccess:

RewriteCond %{REQUEST_URI} !^/.well-known/(acme-challenge|pki-validation)/.*

is it rightly configured?

1 Like