# Letsencrypt renewal failure fetching timeout Ubuntu 18.04LTS **URL:** \ **Category:** Help\ **Created:** [December 20, 2018, 9:48am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591 "2018-12-20T09:48:48Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 9:48am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/1 "2018-12-20T09:48:48Z")
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](http://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://eyesonhives.com) > http-01 challenge for [www.eyesonhives.com](http://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](http://eyesonhives.com)) from /etc/letsencrypt/renewal/eyesonhives.com.conf produced an unexpected error: Failed authorization procedure. [www.eyesonhives.com](http://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:](http://www.eyesonhives.com/.well-known/acme-challenge/8eIihpkHHdWNp7iX2urXgO9j0lrMl0UVgrpnNm9ZOpA:) Timeout during connect (likely firewall problem), [eyesonhives.com](http://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:](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: > > - The following errors were reported by the server: 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](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](http://eyesonhives.com) shows port 80 open (although I have a 307 redirect in nginx conf) - curl -IkL -m20 [https://eyesonhives.com:443](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](http://acme-v01.api.letsencrypt.org) - Tried redoing webroot Looking forward to any help and insights! Thank you again! ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [December 20, 2018, 9:50am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/2 "2018-12-20T09:50:25Z")
Your ISP (Cox) is probably blocking inbound port 80. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [December 20, 2018, 9:51am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/3 "2018-12-20T09:51:35Z")
> [@ktemby](#): > > `curl -IkL -m20 http://eyesonhives.com` > **shows port 80 open** Not from where I'm sitting. curl -IkL -m20 [http://eyesonhives.com](http://eyesonhives.com) **curl: (28) Connection timed out after 20001 milliseconds** ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 9:51am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/4 "2018-12-20T09:51:51Z")
Wow thank you for the fast reply! If port 80 was being blocked, how could I see / test that? ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [December 20, 2018, 9:52am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/5 "2018-12-20T09:52:21Z")
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](https://letsdebug.net/eyesonhives.com/12799) shows that it’s inaccessible. ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 9:53am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/6 "2018-12-20T09:53:34Z")
> [@rg305](#): > > curl -IkL -m20 [http://eyesonhives.com](http://eyesonhives.com) 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. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [December 20, 2018, 9:54am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/7 "2018-12-20T09:54:11Z")
> [@rg305](#): > > curl -IkL -m20 [http://eyesonhives.com](http://eyesonhives.com) > **curl: (28) Connection timed out after 20001 milliseconds** ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 9:55am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/8 "2018-12-20T09:55:11Z")
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. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [December 20, 2018, 9:55am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/9 "2018-12-20T09:55:27Z")
Does your web server logs show any port 80 access? ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [December 20, 2018, 9:55am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/10 "2018-12-20T09:55:56Z")
(apart from your LAN IPs, of course) ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 9:56am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/11 "2018-12-20T09:56:10Z")
I’ll check right now. Wow this forum is amazingly active, thank you rg305 and \_az 🙂 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [December 20, 2018, 9:57am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/12 "2018-12-20T09:57:55Z")
The best attracts the best/most and well deserved too. ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 10:01am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/13 "2018-12-20T10:01:55Z")
Ok I’m going to need more time to figure out where the right logs are 😕 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! ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [December 20, 2018, 10:05am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/14 "2018-12-20T10:05:27Z")
> [@ktemby](#): > > can you please point me to any potential alternative options I should keep in mind if I fail on that front? 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](https://github.com/Neilpang/acme.sh/tree/master/dnsapi#4-use-godaddycom-domain-api-to-automatically-issue-cert) ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 10:06am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/15 "2018-12-20T10:06:18Z")
Got it. Of course I’m testing this from within the network… and should have realized the result wasn’t valid. ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 10:09am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/16 "2018-12-20T10:09:12Z")
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](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. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [December 20, 2018, 10:10am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/17 "2018-12-20T10:10:57Z")
> [@ktemby](#): > > i didn’t have to specify a url:port, I could just go to [http://eyesonhives.com](http://eyesonhives.com), I must have had an open port 80 right? 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/](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. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [December 20, 2018, 10:15am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/18 "2018-12-20T10:15:23Z")
[https://www.cox.com/residential/support/internet-ports-blocked-or-restricted-by-cox.html](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. ---
**Author:** ![ktemby](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ktemby/32/35963_2.png) [@ktemby](https://community.letsencrypt.org/u/ktemby)\ **Post date:** [December 20, 2018, 10:17am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/19 "2018-12-20T10:17:42Z")
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 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [December 20, 2018, 10:24am UTC](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591/20 "2018-12-20T10:24:41Z")
> [@\_az](#): > > Hooray for technological progress. 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. [Next page](https://community.letsencrypt.org/t/letsencrypt-renewal-failure-fetching-timeout-ubuntu-18-04lts/80591.md?page=2)