Cannot get certs with standalone or webroot

I’m trying to generate a certificate for a RPi server I’m running at home, and am running into problems.

====
Please fill out the fields below so we can help you better.

My domain is: home.rogersmj.net OR rogersmj.duckdns.org. I’ve tried with both.

I ran this command: sudo ./certbot-auto certonly
Tried both ways with both domains above:

  1. I selected option 2 (standalone), provided domain name
  2. I selected option 3 (webroot), provided domain name, provided the correct webroot (/var/www/html)

In both modes, it produced the same error:

Domain: home.rogersmj.net (or rogersmj.duckdns.org)
Type:   connection
Detail: Fetching http://home.rogersmj.net/.well-known/acme-challenge/lTEMjtY5vaKUEAf-l8I4t_tlDJtr20YTowTECyvjHy8: 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): Standalone, or Apache 2.4.10

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

My hosting provider, if applicable, is: N/A…running at my home on RPi 3

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):

In both standalone and webroot modes, certbot fails to connect to my machine. I have taken the following steps:

  • Ports 80 and 443 are forwarded through my router to the server
  • When running Apache, I can access Apache-served pages from outside my network (on port 80).
  • Also when running Apache, I can successfully access a test.html file I placed in /.well-known/test.html. Again, from outside my network. So I know the DNS and port forwarding are all working correctly.
  • When trying to use certbot’s standalone option, I shut Apache down of course.

I cannot figure out why cerbot can’t connect to this server, when I can successfully connect to it from the outside world and I’ve verified that I can serve files out of the webroot.

What else should I do?

Hi @rogersmj,

Can you double-check your DNS with a DNS testing tool? I believe this error is sometimes caused by DNS misconfigurations which Let’s Encrypt is stricter about than browsers are.

I have, and both rogersmj.duckdns.org and home.rogersmj.net show errors on pingdom’s strict DNS check. However, I know people use duckdns.org with LetsEncrypt so I don’t know why it wouldn’t work in my case.

http://dnscheck.pingdom.com/?domain=rogersmj.duckdns.org (Error: Failed to find name servers of rogersmj.duckdns.org/IN.)
http://dnscheck.pingdom.com/?domain=home.rogersmj.net (Error: delegation not found at parent)

I have spent hours chasing this DNS problem for my personal domain (home.rogersmj.net, which is CNAMED to a dynamic DNS hostname run by freedns.afraid.org) and have gotten nowhere.

Since I’m hosting this at home, I have to use a dynamic DNS service. When I ran into those issues with home.rogersmj.net using FreeDNS, I decided to try the DuckDNS.org option since I know people have used LetsEncrypt successfully with that service (it’s even recommended in an official LetsEncrypt tutorial for the software package I’m trying to use this certificate for).

Not sure what to try next. Do you know of any other dynamic DNS service that LetsEncrypt will work with?

@cpu @jsha, is this Boulder error always caused by a DNS problem or is there some other reason that could account for it?

Does the hostname on the server (or in Apache config?) need to match the FQDN or something?

Nope, DNS errors will always say something about DNS in their name. “Error getting validation data” is a catch-all error for problems that happen after DNS lookup, but we haven’t specifically caught and turned into a useful error. In https://github.com/letsencrypt/boulder/pull/2791 we changed it from “failed to connect” to the current version, since it’s not always a failure to connect. However, looking at the underlying error from the logs, this one is:

dial tcp 68.46.211.182:80: getsockopt: connection refused

Since that’s a pretty common error case, we should make a point to catch that specific error and provide a better message.

Thanks for checking, @jsha. @rogersmj, that makes this sound like a firewall or router problem. (I’m assuming you’re aware that you need to keep Apache running while using --webroot.)

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