Error Getting Validation Data: HTTP 400

[deepstop]

I haven’t been able to get past this error after a few hours of trying. My router is open on 443 and 80 and NAT directed to the server and the firewall is disabled during the test. tcpdump shows a long (220 or so messages) conversation going through the port. When I ran tcpdump -vv it reported incorrect checksum on all outbound packets which seems a little odd:

192.168.1.10.49814 > 23.201.74.133.443: Flags [.], cksum 0x2427 (incorrect -> 0xa8b5), seq 4194, ack 11829, win 521, options [nop,nop,TS val 16903296 ecr 1323909653], length 0

I ran these commands to confirm nothing was holding on to the ports:
netstat -nlt | grep ':80\s’
netstat -nlt | grep ‘:443\s’

I see an http 400 in the log. Not sure what that’s about.

I can’t paste the log because I get ‘too many links’ for a new user, and I can’t upload it because I’m also a new user. If someone can tell me how to work around this I will reply with it, or I can email it to anyone who cares.

Thanks to all for help.

My domain is: ve3nrt.net

I ran this command: sudo certbot -n --email xxxx@ve3nrt.net --agree-tos --standalone certonly --preferred-challenges tls-sni -d ve3nrt.net

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for ve3nrt.net
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. ve3nrt.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: ve3nrt.net
  Type: connection
  Detail: Error getting validation data

  To fix these errors, please make sure that your domain name was
  entered correctly and the DNS A record(s) for that domain
  contain(s) the right IP address. Additionally, please check that
  your computer has a publicly routable IP address and that no
  firewalls are preventing the server from communicating with the
  client. If you’re using the webroot plugin, you should also verify
  that you are serving files from the webroot path you provided.

My web server is (include version): None

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

My hosting provider, if applicable, is: N/A

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

[Patches]

I believe if you enclose your log within three backticks it won’t linkify it and allow you to post it, e.g.

```
<log contents>
```

Otherwise you could use a pastebin service like https://gist.github.com or https://pastebin.com and link it here.

As for your issue, I would suggest setting up a temporary web server to make sure connectivity is good.

Here’s a simple procedure that launches one that uses software that should already be installed on your server:

mkdir /tmp/webtest
cd /tmp/webtest
echo "Hello, world!" > index.html
sudo python -m SimpleHTTPServer 80

With that running, try and visit your domain from a different network (e.g. a smartphone with mobile data) and see if it loads. If it works, try using http-01 as the preferred challenge and if that doesn’t work we’ll loop in a Let’s Encrypt engineer to check their logs for possible issues.

If you cannot access a temporary webserver in this fashion, your connectivity issues are not specific to Let’s Encrypt and will need to be sorted out.

[deepstop]

Patches, I appreciate your help. The simple web server tip showed that my upgrade from Jessie to Stretch has caused some issues that I will need to resolve first. I have had 3 IP addresses attached to the Ethernet interface since I first installed the OI (192.168.1.10 , 11, and 12) and only the second one responds, not the first one as I expected. I’ve also been having to manually set up a route to the gateway after reboot, which wasn’t needed before the upgrade. So yes, I will have to sort the network issue before trying certbot again. This has given me some good insight into what is going on.

Chris

[deepstop]

Solved: It turned out that my understanding of iptables was primarily in CentOS and it was still running on my Debian Pi. It was blocking the .10 address but not .11. So I modified the rules instead of trying to disable it. The certificate is issued now. On to my next problem that Outlook can’t verify it, but more research hours needed before resorting to posting a new topic.

Thanks,
Chris

[schoen]

I would suggest making sure that the full chain is being served (e.g. using fullchain.pem, not cert.pem). — And also that Outlook is accessing the server using a DNS name that is actually a subject name of the certificate.