Cert renewal failing as a result of timeout

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. crt.sh | 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:

dev.classyapi.kilterapp.com

I ran this command:

sudo certbot renew --cert-name dev.classyapi.kilterapp.com --dry-run

It produced this output:

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


Processing /etc/letsencrypt/renewal/dev.classyapi.kilterapp.com.conf


Simulating renewal of an existing certificate for dev.classyapi.kilterapp.com

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: dev.classyapi.kilterapp.com
Type: connection
Detail: Fetching http://dev.classyapi.kilterapp.com/.well-known/acme-challenge/gndAAjMzbLyfWhJEllH0qmaTC4myK96pHUBFZjho878: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Failed to renew certificate dev.classyapi.kilterapp.com with error: Some challenges have failed.


All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/dev.classyapi.kilterapp.com/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):

nginx version: nginx/1.14.0 (Ubuntu)

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

NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"

My hosting provider, if applicable, is:

AWS/EC2

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

N

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot 1.26.0


Notes:

Running sudo nginx -T

I noticed the following in my server block added by certbot, but need assistance to help confirm this is the problem.

listen 80;
listen [::]:80;
server_name dev.classyapi.kilterapp.com;
return 404; # managed by Certbot

Results from let's debug confirm that as well

ANotWorking

ERROR

dev.classyapi.kilterapp.com has an A (IPv4) record (3.145.23.184) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.

A timeout was experienced while communicating with dev.classyapi.kilterapp.com/3.145.23.184: Get "http://dev.classyapi.kilterapp.com/.well-known/acme-challenge/letsdebug-test": dial tcp 3.145.23.184:80: i/o timeout

Trace:
@0ms: Making a request to http://dev.classyapi.kilterapp.com/.well-known/acme-challenge/letsdebug-test (using initial IP 3.145.23.184)
@0ms: Dialing 3.145.23.184
@10001ms: Experienced error: dial tcp 3.145.23.184:80: i/o timeout

Is that the entire port 80 server block for that name? Because that would be a problem but not resulting in timeout.

Right now I do not see port 80 (or port 443) open. It looks like your EC2 Security Group may not be allowing connections or perhaps VPC Network ACL access rules?

2 Likes

That was a very tiny snippet and provided completely without context.

1 Like

Thanks for the quick reply.

I checked the SGs before I submitted this but you're reply was well taken and doubled checked my DNS; I realized the instance must have recently recently rebooted which changed the IP address. I updated the DNS record with the new IP and the renewal worked. Huzzah.

Thanks again so much.

1 Like

Apologies to both @rg305 and @MikeMcQ on this. I though I included the entire dump from the test in the content above.

1 Like

Yes, AWS can even trigger such reboots for hardware/system purposes. An Elastic IP can avoid the IP reassignment problem (possibly at extra cost). No worries on your posts.

3 Likes

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