Letsencrypt renewal failure fetching timeout Ubuntu 18.04LTS

Help
1

Hi, I have read through many posts that seemed relevant on this forum and SO, and am still struggling. Thank you for your time and assistance in advance.

My domain is: eyesonhives.com

I ran this command: sudo letsencrypt renew

It produced this output:

sudo letsencrypt renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/eyesonhives.com.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for eyesonhives.com
http-01 challenge for www.eyesonhives.com
nginx: [warn] duplicate MIME type "text/html" in /etc/nginx/sites-enabled/eyesonhives:48
Waiting for verification...
Cleaning up challenges
nginx: [warn] duplicate MIME type "text/html" in /etc/nginx/sites-enabled/eyesonhives:44
Attempting to renew cert (eyesonhives.com) from /etc/letsencrypt/renewal/eyesonhives.com.conf produced an unexpected error: Failed authorization procedure. www.eyesonhives.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.eyesonhives.com/.well-known/acme-challenge/8eIihpkHHdWNp7iX2urXgO9j0lrMl0UVgrpnNm9ZOpA: Timeout during connect (likely firewall problem), eyesonhives.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://eyesonhives.com/.well-known/acme-challenge/Kn-0CrthZwwrc9-8FJ4zVakFrF1GLBLMdhJlMGXe5R8: Timeout during connect (likely firewall problem). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/eyesonhives.com/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/eyesonhives.com/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

My web server is (include version): nginx/1.14.0

The operating system my web server runs on is (include version): Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-39-generic x86_64)

My hosting provider, if applicable, is: (godaddy configured dns, locally hosted webserver)

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, although dns configured with godaddy.

Notes:

  • Letsencrypt had been working and autorenewing perfectly until upgrading from 16.04LTS to 18.04LTS in November.
  • I have nginx sub configuration in sites-enabled doing a redirect of all non https scheme to https, originally custom, now as per letsencrypt tutorial.
  • Tried nuking and re-starting nginx configuration from scratch
  • I am using webroot, and can access a test file https://eyesonhives.com/.well-known/acme-challenge/test.json
  • I noticed that the http-01 challenge is calling the http site (could the redirect be part of problem?)
  • Server only accessible via IPv4, only A record configured on DNS (no AAAA entry),
  • curl -IkL -m20 http://eyesonhives.com shows port 80 open (although I have a 307 redirect in nginx conf)
  • curl -IkL -m20 https://eyesonhives.com:443 shows 443 open (also has the 307 redirect)
  • Tried forcing IPv4 mapping to letsencrypt via hosts entry (now removed) 104.110.134.170 acme-v01.api.letsencrypt.org
  • Tried redoing webroot

Looking forward to any help and insights! Thank you again!

2

Your ISP (Cox) is probably blocking inbound port 80.

3

Not from where I'm sitting.
curl -IkL -m20 http://eyesonhives.com
curl: (28) Connection timed out after 20001 milliseconds

4

Wow thank you for the fast reply! If port 80 was being blocked, how could I see / test that?

5

Well, there’s no definite way to know other than contacting your ISP to verify it. Could also be a failure to forward a port on your router.

But using any online test e.g. https://letsdebug.net/eyesonhives.com/12799 shows that it’s inaccessible.

1 Like
6

Is that not because I'm redirecting that traffic? I have a translation rule in place to send port 80 over to my server from when it hits my router. Until recently that seemed to be working.

7
1 Like
8

I did recently change some part of my ISP (cox) plan, which may have changed the way port 80 behaved. I had thought that it was my own redirect modifying this behavior.

Thank you again! I supposed I need to figure out what to do with port 80, or where I should host this.

9

Does your web server logs show any port 80 access?

10

(apart from your LAN IPs, of course)

2 Likes
11

I’ll check right now. Wow this forum is amazingly active, thank you rg305 and _az :slight_smile:

12

The best attracts the best/most and well deserved too.

1 Like
13

Ok I’m going to need more time to figure out where the right logs are :confused:

Assuming that port 80 is blocked for now, or I need to figure out how to properly route it, can you please point me to any potential alternative options I should keep in mind if I fail on that front?

Thanks again for all of your help!

14

You can use DNS validation.

acme.sh supports GoDaddy's API, who host your nameservers currently: https://github.com/Neilpang/acme.sh/tree/master/dnsapi#4-use-godaddycom-domain-api-to-automatically-issue-cert

1 Like
15

Got it. Of course I’m testing this from within the network… and should have realized the result wasn’t valid.

16

Thanks again, I’ll work through those as next steps after working on the router NAT a little longer. I had TCP 80 forwarded as a rule, but if I was never getting it in the first place, that would make sense.

This is i’m sure a newb question - but when I was only able to serve the site via HTTP and i didn’t have to specify a url:port, I could just go to http://eyesonhives.com, I must have had an open port 80 right?

Trying to track down what else had actually changed recently - internet plan did.

17

Yup (assuming you could do it from an external, non-LAN connection).

There's one way to partially dodge this, and that's to put your site on thte HSTS preload list (https://hstspreload.org/). In that case, participating browsers will automatically force secure connections (over port 443) to your domain.

But not all browsers implement HSTS preload list and .. yeah, better just to get the port unblocked if you can.

1 Like
18

https://www.cox.com/residential/support/internet-ports-blocked-or-restricted-by-cox.html seems to explicitly acknowledge 80 as being blocked.

Maybe you were on a grandfathered profile, and when you upgraded your plan, it stuck you on a modern one. Hooray for technological progress.

1 Like
19

Ouch - well that makes a ton of sense. That was the main ‘other’ thing that changed this past month.

Thank you for your diligence on this issue and the wonderful support you provide this community. I really appreciate your help, and I saw your effort in many posts helping others too. Cheers

20

It's not all bad.
HTTP should be killed/blocked.

Sadly, we lost HTTPS as a valid authentication method.
[There is never a good time for a bad thing to happen.]

Maybe we need to start thinking outside the box for ways to authenticate...
Like using local DNS for authentication.
I think I'll start a new thread on that topic.

1 Like