Cannot pass http-01 challenge with standalone plugin

Hi, I am trying to provision certificates on a server which normally does not run a standard web server. I am trying to use the ‘standalone’ plugin to do so, and I am getting “Error getting validation data” when trying to do the challenge

My domain is:

I ran this command:

sudo certbot certonly --cert-name guardian --standalone --noninteractive --agree-tos --redirect -m -d

It produced this output:

Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Error getting validation data


My web server is (include version):

None (using the standalone plugin)

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

Ubuntu 16.04.6 LTS (Xenial Xerus)

My hosting provider, if applicable, is:

Running in AWS

My domain is mapped using a CNAME record to the DNS of a network load balancer with a listener to forward TCP on port 80 to my instances.

I can login to a root shell on my machine (yes or no, or I don’t know):


I’m using a control panel to manage my site (no, or provide the name and version of the control panel):


The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

certbot 0.31.0

Hi @Lsquared13

if you use --standalone, it's nearly impossible to find connection errors.

Checking your domain there is an answer. But buggy - ( ):

Domainname Http-Status redirect Sec. G -11 0.210 S
ServerProtocolViolation - The server committed a protocol violation. Section=ResponseStatusLine 404 0.966 N
Not Found
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors -11 0.210 S
ServerProtocolViolation - The server committed a protocol violation. Section=ResponseStatusLine
Visible Content:

Your port 80 answers, but the answer isn't good. It's possible that Letsencrypt ignores that error.

Port 443 works, so you may create a redirect http -> https. It's possible that the "small 301 answer" works without such an error.

Hi thanks for the prompt response.

I’m rather unclear on what anything on that page really means. If I’m running a standalone server, wouldn’t I expect bad HTTP responses when I’m not running the certbot because the standalone server only runs when I run certbot? Is that not the case?

I expect port 443 to result in an unsigned certificate error because I have port 443 on my load balancer being forwarded to a different port on my instance, which serves an HTTPS only application with a self-signed cert (my eventual goal is to replace these with Let’s Encrypt certs).

My idea here is that incoming connections to port 443 are forwarded to my application on another port, and incoming connections to port 80 are forwarded to port 80 on my server, which I expect to work only when I am running the standalone server for certificate renewal purposes.

Do you have any suggestions on how I might troubleshoot the problem on port 80, rather than going through port 443? I just can’t figure out what the problem could be or how I would even figure that out.

For further information, here’s the final response I get back when running the challenge with verbosity turned on:

“identifier”: {
“type”: “dns”,
“value”: “
“status”: “invalid”,
“expires”: “2019-04-17T15:06:43Z”,
“challenges”: [
“type”: “dns-01”,
“status”: “invalid”,
“url”: “”,
“token”: “uoTJKlXTw2vicUPxvM_woGcowAyWuhO1Qas9tPOY4yM”
“type”: “tls-alpn-01”,
“status”: “invalid”,
“url”: “”,
“token”: “XlIJPlJlglKtrZejkl55vVnyCutaYM8E_srJWdQh5Mo”
“type”: “http-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:ietf:params:acme:error:connection”,
“detail”: “Fetching Error getting validation data”,
“status”: 400
“url”: “”,
“token”: “ZEK3Uc4g9rwdSwSS1htKnBexN7S_79P-JZYMIJZpeIE”,
“validationRecord”: [
“url”: “”,
“hostname”: “”,
“port”: “80”,
“addressesResolved”: [
“addressUsed”: “”

That's correct. But there is another instance, that answers. But without headers and with a not correct http answer. So I don't know what this is.

Looks like your server has already something on port 80. Or your port forwarding doesn't work as expected.

I definitely don’t have anything on port 80. I did when I first tried this and got a bind error, but then I shut down the service listening on port 80 and started getting the current error.

I tried an experiment and got some more information. Specifically, I changed the Route 53 DNS record from a CNAME record pointing to my Network Load Balancer to an A record pointing directly to the public IP address for my server, and I can provision certificates with that setup.

So it seems to be a problem going through the network load balancer, but I definitely have port forwarding set up. My forwarding on port 80 looks exactly the same as my forwarding with port 443, and I know port 443 is forwarded because network load balancers run on layer 4 (TCP protocol), meaning that’s the only way I’d get an untrusted certificate error since the load balancer doesn’t have a certificate of its own.

All the issues I can think of that might possibly cause this fall into two categories:

  1. The chain of communication between Let’s Encrypt servers, my network load balancer, and my instance breaks down at some point
  2. The Challenge, for some reason, doesn’t like the fact that the IP that the DNS name resolves to (the network load balancer) doesn’t match the IP that the server uses directly (the instance IP, either public or private). Note in my last response that the fields “addressesResolved” and “addressUsed” correspond to my network load balancer and not my instance.

Any suggestions on how I might tell which of these is the issue, and assuming it’s the first one, how I might go about troubleshooting where exactly the issue is?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.