Letsencrypt renewal failure fetching timeout Ubuntu 18.04LTS


#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.


#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

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


#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.


#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


#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.


#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.


#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.