Timeout failure

My turn, I guess…

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: mccloud.thompsonian.net

I ran this command: sudo certbot certonly --standalone -d mccloud.thompsonian.net
from apt show certbot
Version: 0.21.1-1+ubuntu16.04.1+certbot+0.2

It produced this output:

Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mccloud.thompsonian.net
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. mccloud.thompsonian.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://mccloud.thompsonian.net/.well-known/acme-challenge/3ncnScX16NO9RSJH-n9obX0zLaw085JJfnh2wQXN5Jc: Timeout

mccloud@mccloud:~$ sudo tail /var/log/letsencrypt/letsencrypt.log
certr, chain, key, _ = self.obtain_certificate(domains)
File “/usr/lib/python3/dist-packages/certbot/client.py”, line 318, in obtain_certificate
self.config.allow_subset_of_names)
File “/usr/lib/python3/dist-packages/certbot/auth_handler.py”, line 81, in get_authorizations
self._respond(resp, best_effort)
File “/usr/lib/python3/dist-packages/certbot/auth_handler.py”, line 138, in _respond
self._poll_challenges(chall_update, best_effort)
File “/usr/lib/python3/dist-packages/certbot/auth_handler.py”, line 202, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. mccloud.thompsonian.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://mccloud.thompsonian.net/.well-known/acme-challenge/3ncnScX16NO9RSJH-n9obX0zLaw085JJfnh2wQXN5Jc: Timeout

My web server is (include version): the certbot --standalone one

The operating system my web server runs on is (include version): Linux mccloud 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

My hosting provider, if applicable, is: self-hosted, Cox Communications subscriber.

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

Other notes:
Not running a firewall. Placed it in the “DMZ” of my router. I can ping it via FQDN and ip, ssh into it, and in the past I’ve run web servers on ports 80 and 443 with success locally generated self-signed certs. Running --standalone this time to make sure there’s nothing interfering. Please help me to discover whatever it is I’ve obviously forgotten to do. :confused:

Hi,

You forget to open port 80 and 443…(at least it’s not open to public)

Thank you.

1 Like

Hey thanks for the quick reply!

There’s nothing running on 80 or 443 currently. Shall I put something up to help with the diagnosis? Asking out of ignorance: is it actively denying a connection or would it look the same if nothing was there to answer??

-A

Yes, it would be helpful for diagnosis.

Additionally, is this a residential Cox connection?

If so, Cox block port 80 inbound, which means you wouldn't be able to use the HTTP validation method at all, sorry.

It looks more like filtering than "nothing running" (timeout vs connection refused), but this can sometimes be ambiguous.

1 Like

This has turned out to be more a test of my (in)ability to configure Apache than a proof that, yes, the ports are open but I've prevailed. :trophy:

Apache listening on 80 and 443 (although with a self-signed cert.)

I ran

sudo certbot certonly --webroot --webroot-path /var/www/html

and got the same failure as in my original post.

Failed authorization procedure. mccloud.thompsonian.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://mccloud.thompsonian.net/.well-known/acme-challenge/TomDmbaODfqsB74DHM0sFnzUNgKJvjgYfuE3TfigdY8: Timeout

But here's the thing: as soon as I could I refreshed a view of .well-known/acme-challenge/ in my browser and I could see the file just fine. Mind you, I did this over port 443 from the public ip. So... the file is there being served but somehow letsencrypt can't use/see it.

Seriously reconsidering my life choices (all of them) at this point.

And, yes, I'd also heard that Cox doesn't allow personal web servers on their residential accounts. Mine's kinda "upper-tier," if you will, so maybe I'm special. Was surprised when it worked in the first place.

-A

Won't work. Let's Encrypt initiates the validation request using port 80 only, and will not try on 443 unless it is redirected there from 80. This is a behavior designed to avoid a certain security issue.

I still think that Cox is blocking 80 on your connection. I can successfully visit your server over 443, but not 80.

I suggest you try to load your site over port 80 from a different internet connection to your server (such as from a mobile device, not using wifi). It will fail.

1 Like

Won’t work. Let’s Encrypt initiates the validation request using port 80 only, and will not try on 443 unless it is redirected there from 80. This is a behavior designed to avoid a certain security issue.

I still think that Cox is blocking 80 on your connection. I can successfully visit your server over 443, but not 80.

Yes, indeed that is the issue! I could swear I had tried port 80 before (and run a website there, no less). Thank you for your assistance and patience. I did learn a lot today wrestling with Apache, and now I know a bit more about how Lets Encrypt works as well, so I'm going to put this in the "win" column.

Best,
A

You might still be able to get a certificate using the DNS challenge - you seem to be using Dreamhost’s DNS, acme.sh claims to support their API so that might be worth a try.

1 Like

It took me a while to sort it out but, yes, I was able to obtain a key from Dreamhost’s DNS. Plugged that in to acme.sh and was able to prove I owned the domain that way. All set up with a legit certificate. Thanks for the pointer!

Was also able to put a certificate on a machine internal to my network (no ports exposed to the outside world) using the same method.

1 Like

Great, glad it worked out for you!

BTW, your server isn’t sending the intermediate certificate so it might intermittently not work on some devices. Since you seem to be on Apache 2.4, you should use the --fullchain-file rather than the --cert-file, that should fix it.

1 Like

Thank you. I’ve pointed apache2’s SSLCertificateFile directive at a copy of the file created by acme.sh as the fullchain-file. Reloaded. I wasn’t able to see any difference from Chrome but it does seem to be working. Guessing I don’t own any devices (yet) that rely on this. Thanks again for the help.

SSLCertificatFile Directive

Yep, looks good now :slight_smile:

1 Like

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