Unable to renew certificate

Help
1

I used to renew my certificate every 2.5 months, with the exact same command. It used to work, but started failing this time. I have tried using both letsencrypt-auto and certbot, but both are failing.

Since my server is behind cloudflare, I use the webroot plugin. I noticed that, in other topics people mentioned about disabling IPv6. I have disabled IPv6 in cloudflare. And still I get the same timeout issue.

My domains are: codiva.io, kasadara.com

I ran this command:
export DOMAINS="-d codiva.io -d kasadara.com -d www.codiva.io -d www.kasadara.com"
export DIR=/tmp/letsencrypt-auto
cd /opt/letsencrypt/
mkdir -p $DIR && ./letsencrypt-auto --renew-by-default certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path=$DIR --agree-dev-preview $DOMAINS
sudo service nginx reload

It produced this output:

http-01 challenge for codiva.io
http-01 challenge for kasadara.com
http-01 challenge for www.codiva.io
http-01 challenge for www.kasadara.com
Using the webroot path /tmp/letsencrypt-auto for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /tmp/letsencrypt-auto/.well-known/acme-challenge
Failed authorization procedure. kasadara.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://kasadara.com/.well-known/acme-challenge/JUnVgjZ0DoV_pc6ehssiZZI3kOOUYBb-Pt_rsMUBr2o: Timeout, www.codiva.io (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.codiva.io/.well-known/acme-challenge/XkoMFlc1I4Sc_RjYdAxaWBHdH7zehumG0PTH7l76gKY: Timeout, www.kasadara.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.kasadara.com/.well-known/acme-challenge/oioY7LQj-iwxTz5t_TGAlGibhLh7ngMIHQX5BcAH0Kk: Timeout

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: kasadara.com
   Type:   connection
   Detail: Fetching
   http://kasadara.com/.well-known/acme-challenge/JUnVgjZ0DoV_pc6ehssiZZI3kOOUYBb-Pt_rsMUBr2o:
   Timeout

   Domain: www.codiva.io
   Type:   connection
   Detail: Fetching
   http://www.codiva.io/.well-known/acme-challenge/XkoMFlc1I4Sc_RjYdAxaWBHdH7zehumG0PTH7l76gKY:
   Timeout

   Domain: www.kasadara.com
   Type:   connection
   Detail: Fetching
   http://www.kasadara.com/.well-known/acme-challenge/oioY7LQj-iwxTz5t_TGAlGibhLh7ngMIHQX5BcAH0Kk:
   Timeout

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

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

The operating system my web server runs on is (include version):
ubuntu 14.04

My hosting provider, if applicable, is: AWS EC2 machine behind cloudflare.

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

Please let me know how to fix this.

Thanks,
JP

2

Hi @jayp,

I tried looking at some of these in a browser and at least one of them took a long time and then showed a Cloudflare timeout message indicating that the origin was unavailable.

I’m not sure of the underlying reason why your origin server appeared to be down, but one hypothesis is that maybe when you switched your site to HTTPS you stopped having it listen on HTTP at all? Right now if I try to go to http://www.codiva.io/ I get a timeout. However, after visiting https://www.codiva.io/ in a particular browser, it is difficult to get that specific browser to try to load http://www.codiva.io/ over HTTP at all, because you send HSTS headers which tell the browser to use the HTTPS version of the site automatically.

My conclusion is that maybe the origin server for one or more of these no longer serves HTTP or no longer serves it reliably, which is breaking the challenges, but that you don’t notice the error in a browser because the HSTS header is preventing your browsers from ever trying to load HTTP resources from your sites at all. If you try with a fresh browser or with a tool like curl that doesn’t know about HSTS, you might notice some configuration errors more readily.

3

Thanks. This makes sense. I am able to reproduce this with curl. I will debug what I missed in the config.

Is this a new change? I have been using the exact config for almost a year, and the renew script used to work without any issues.

~JP

4

Answering HTTP was always required and is part of the protocol specification. Is it possible that you previously redirected HTTP to HTTPS, and subsequently disabled HTTP? The certificate authority is willing to follow a redirection, but it has to be given the redirection explicitly in response to an initial HTTP connection.

5

In my case, I had accidentally disabled port 80 in aws EC2 security group. I don’t remember touching this recently but it is possible that I did it 2-3 months ago.

I never noticed because of HSTS, as you mentioned.

Thanks. It all worked!

6

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