Nginx adding certificate worked but renew dry-run fails

Help
1

Today I got the certificate installed using

sudo certbot --nginx --rsa-key-size 4096

Then i wanted to make sure the certificate would renew properly since I'm using HSTS. So I ran the certbot renew --dry-run as stated below. That fails for some reason. I read a few other forum posts but my configs are extremely vanilla.

In the letsencrypt.log file I saw where it wrote

location = /.well-known/acme-challenge/*randomstring*{default_type text/plain;return 200 *randomstring*.*anotherrandomstring*;} # managed by Certbot
Also, forgive me but I don't entirely know if everything this log file is safe to share.

I just don't understand how it was able to issue a valid cert on the website but the dry-run for renewing just keeps choking like it can't access the url it is adding to the nginx config.

My domain is: inventory.owensboro.kyschools.us

I ran this command: certbot renew --dry-run

It produced this output:

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/inventory.owensboro.kyschools.us.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Simulating renewal of an existing certificate for inventory.owensboro.kyschools.us
Performing the following challenges:
http-01 challenge for inventory.owensboro.kyschools.us
Waiting for verification...
Challenge failed for domain inventory.owensboro.kyschools.us
http-01 challenge for inventory.owensboro.kyschools.us

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: inventory.owensboro.kyschools.us
  Type:   connection
  Detail: During secondary validation: 170.185.177.50: Fetching http://inventory.owensboro.kyschools.us/.well-known/acme-challenge/*randomstring*: 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.

Cleaning up challenges
Failed to renew certificate inventory.owensboro.kyschools.us with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/inventory.owensboro.kyschools.us/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.18.0 (Ubuntu)

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

My hosting provider, if applicable, is: Internal

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

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

1 Like
2

Hmm. It looks like there is a firewall that blocks access from IP addresses outside the US. But, it is puzzling how you got a cert earlier today which would have required access from the Let's Encrypt Server in Germany (they might move around but various points around the world are used).

Could you have changed a firewall setting after getting the cert?

See this global test site for only US connection worked

I have no trouble accessing from my US test server and Let's Debug test site was fine too. The error saying "Secondary Validation" failed indicates it may have been the Europe region failing.

3 Likes
3

Thanks for the info. Unfortunately our firewall is maintained by corporate which puts a ticket in with ATT to make changes so I have no way of knowing. I'm submitting a ticket though to find out.

Is there documentation somewhere that details what IPs need to be white listed?

1 Like
4

A list of IP's is not provided. See this explanation in the FAQ

See if you can whitelist the URL format of the ACME challenge. It always starts with:

http://(domain)/.well-known/acme-challenge/

Another option is to use the DNS Challenge. You need ability to update the DNS for your domain either manually or by API. If difficult to update DNS each cert renewal, an option is to use a CNAME record to redirect the DNS challenge to a DNS system you can more easily control.

3 Likes
5

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