SOLVED: renew dry-run error when no http:80 port available


#1

A solved problem to report for others.
No help needed.

I recently tried to renew my cert like I have done many times in the past over the last years.
This time an error popped up I could not solve.
Timeout during connect (likely firewall problem)

log says Connection Refused, but I debugged and tested from many external locations
but it WAS available; I could not figure out why the dry-run kept failing

Thanks to rg305 post at New certs work - renewals fail

–dry-run request are now being forced over HTTP .
It seems your system is not allowing HTTP connections.

I do have all requests redirected to https along with HSTS - Strict-Transport-Security enabled.

When I ran the renew WITHOUT dry-run, it worked perfectly.

Very frustrating, so I help this post helps others save their time.
tom

My domain is: webarts.bc.ca
I ran this command: certbot-auto renew --dry-run -v --webroot -w /var/www/html
It produced this output:
Timeout during connect (likely firewall problem)

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA 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): httpd v2.4.23
The operating system my web server runs on is (include version): fedora 23
My hosting provider, if applicable, is:
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):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.31.0


#2

Hi @tgutwin,

Unfortunately, this indicates a problem that you’ll still have to resolve.

Let’s Encrypt is in the process (near the end) of making a change to the allowed validation methods due to a security problem identified by a researcher more than a year ago. That means that the behavior of the CA has changed. When people find recent renewal problems that didn’t happen before, it’s usually related to the fact that their old configurations genuinely don’t work with the new CA behavior.

There is lots of information about this issue on the forum; if you want to know some of the history, please see



The change in supported validation methods does mean that some renewals that worked before won’t work in the future and will require updated Let’s Encrypt client applications, changes in firewall rules, or other changes. We’ve tried to make this as automatic and convenient as possible, but particularly because the TCP port that most people use for validation will switch from 443 to 80, it can’t be an automatic switchover for everyone!

The --dry-run is a more realistic simulation of the behavior that Let’s Encrypt will exhibit for everyone next month. If it succeeds, your configuration is OK with regard to the upcoming change, but if it fails, your configuration is not OK and subsequent renewals (with or without --dry-run) are likely to break.

The more specific practical information aimed at Certbot users is here:

If this doesn’t resolve your problem, you still have a problem that needs to be fixed in order to continue renewing certificates after TLS-SNI-01 support is completely disabled. You can find other forum threads or ask for help. What I particularly want to emphasize, though, is that not using --dry-run is not a fix or a solution, because --dry-run in this case simulates the upcoming behavior that will exist for everyone soon. (--dry-run itself isn’t a way to renew certificates; as the name is meant to suggest, it’s just a way to check whether renewing certificates would work, using the Let’s Encrypt staging (test) server.)


#3

Note that we’ve also sent reminder e-mails to the registered contact e-mail address for all certificate renewals that have renewed a certificate recently with the obsolete TLS-SNI-01 method. This represents Let’s Encrypt’s attempt to notify end-users of certificates when it appears that their configurations haven’t been updated sufficiently to address this change. (The attempt to notify client software developers has included the forum posts I linked to, and several others here.) If you have a registered contact e-mail address on your Let’s Encrypt account, you should have received a notice like this directing you to some relevant documentation about the issue.


#4

I realise you’ve already put “SOLVED” in the topic title, but a little note about the above: Let’s Encrypts validation servers ignore HSTS in any form: pre-loaded or through headers.
Also, the HTTP to HTTPS redirect is followed, so that also should not be a problem.


#5

Hi @tgutwin

checked your config, you have a very untypical configuration.

Your http + www and your http + /.well-known/acme-challenge is answered by

Server: Jetty(9.3.15.v20161220)

http + / has

Server: Apache

http + non-www redirects to firewall.webarts.bc.ca, the http + www redirects to https://red.webarts.bc.ca:9443/webArts, that’a non-standard-port.

The result: Letsencrypt checks /.well-known/acme-challenge, your non-www-version is redirected to

http://firewall.webarts.bc.ca/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de

your www ends direct:

http://www.webarts.bc.ca/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de

So it’s a very untypical setting you use.


#6

Thanks for the info,
I now realize I have some things to correct before my next renewal.

For legacy app reasons, I have somewhat of a non-standard setup, but it works.
I will need to clean some things up to enable port 80.

Off to work I go…