Challenge failed. System configuration pre-reqs? (Ubuntu 16.04 LTS)

My domain is:

I ran this command:
sudo letsencrypt certonly -a webroot --webroot-path=/path/to/application -d

It produced this output and stack trace in the logs:

2017-12-30 05:32:12,794:DEBUG:letsencrypt.cli:Exiting abnormally:
Traceback (most recent call last):
File “/usr/bin/letsencrypt”, line 9, in
load_entry_point(‘letsencrypt==0.4.1’, ‘console_scripts’, ‘letsencrypt’)()
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 1986, in main
return config.func(config, plugins)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 706, in obtain_cert
_, action = _auth_from_domains(le_client, config, domains, lineage)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 474, in _auth_from_domains
lineage = le_client.obtain_and_enroll_certificate(domains)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 269, in obtain_and_enroll_certificate
certr, chain, key, _ = self.obtain_certificate(domains)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 252, in obtain_certificate
return self.obtain_certificate_from_csr(domains, csr) + (key, csr)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 225, in obtain_certificate_from_csr
authzr = self.auth_handler.get_authorizations(domains)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 84, in get_authorizations
self._respond(cont_resp, dv_resp, best_effort)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 142, in _respond
self._poll_challenges(chall_update, best_effort)
File “/usr/lib/python2.7/dist-packages/letsencrypt/”, line 204, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)

FailedChallenges: Failed authorization procedure. (http-01): urn: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): nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 16.04.3 (4.4.0-1043-aws)

My hosting provider, if applicable, is: GoDaddy + AWS

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

I am working on a tool to use with SSO for a personal project. Out of the box, I have configured nginx to listen on port 80, set the path in my serverblock as follows:

server {
        listen 80;
        listen [::]:80;

        root /home/username/appdirectory;

        location ~ /.well-known {
                allow all;

#        return 301 https://$server_name$request_uri;

I have confirmed in the logs that the challenge file is being created (and then cleaned-up when it fails). In order for this to work I had to create the “.well-known” directory manually and gave ownership to www-data on this and the app directory for troubleshooting so perhaps there is some sort of issue with permissions? I have tried a variety of permissions and double-checked firewall rules to ensure that all communication flow should be happening.

To currently test, you should be able to access a test index.html in the same directory by visiting the address directly via http.

Are there certain configurations or permissions that must exist that are not documented in the tutorials for the webroot tool to work properly on Ubuntu 16.04 out of the box?

Let's Encrypt won't validate over an IP address URL like (That's just how it's designed.)

You need to configure the web server not to respond with a redirect like that. Either don't redirect at all, or redirect to an URL with a hostname, like or or whatever.

Additionally, did you know that site has two IP addresses?  (unsigned)  600  A  (unsigned)  600  A

One of them is an EC2 IP, and one of them is a GoDaddy IP that sends weird redirects. It might be for a GoDaddy service like "URL forwarding" or "domain redirects"? If so, you should turn it off. It will cause problems for Let's Encrypt validation. And other things.

1 Like

This actually is something a friend of mine was just pointing out to me - on his end it was not resolving properly. I Do have GoDaddy's Subdomain redirect tool being used, so I will go ahead and just A name it and see if that helps.

Spot on advice. I removed the subdomain forwarding. I also switched to a CNAME record pointing to my public dns rather than the IP via A record. Re-ran the script and it generated…

6 hours of time spent, 10 minutes after I asked someone for help I had the answer… :smiley:


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