Renew certificates connection refused

My domain is:

I ran this command:
certbot certonly --debug --force-renew -a manual -d --dry-run --authenticator apache

It produced this output:
Type: connection
Detail: Fetching
Connection refused

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):
Server version: Apache/2.4.7 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 14.04 3.16.0-77

My hosting provider, if applicable, is:

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

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

Sorry for this ‘never-ending-stupid-question’ … but i am lost a bit here

Strange enough – challenge is there for http
curl -X GET -I -4
HTTP/1.1 200 OK
Date: Sun, 03 Mar 2019 19:46:32 GMT
Server: Apache/2.4.7
Strict-Transport-Security: max-age=63072000; includeSubdomains;
Last-Modified: Sun, 03 Mar 2019 19:37:09 GMT
ETag: “57-58335c4135d0e”
Accept-Ranges: bytes
Content-Length: 87

and is not for http
curl -X GET -I -4
HTTP/1.1 301 Moved Permanently
Date: Sun, 03 Mar 2019 19:47:56 GMT
Server: Apache/2.4.7
Content-Length: 299
Content-Type: text/html; charset=iso-8859-1

Also normal web request (firefox for ex) works for the challenge.
I’ve noticed that ‘certbot’ is trying http instead of https for some reason.

I do have ‘RewriteRule’ in my Apache config:
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [NC,R=301,L]

Can you tell me what the heck is going on?

I can connect to your server on port 80 from here, and so can Let’s Debug, but it seems that the Let’s Encrypt staging server can’t.

Do you have a firewall or something blocking connections from certain IP addresses or ranges?

yea… that’s the mystery for me as well… i do have ‘fail2ban’ running though…

what is the IP of the staging server if you pls?

strangely enough it started when i start to deprecate TLS-SNI-01 validation method. but maybe it is just a coincidence.

The staging server connects from a number of different IP addresses. The live ones are intentionally not specified; I’m not sure whether the same is true of staging but I suspect so. At least I’ve never seen any official list of IP addresses.

Can you temporarily disable fail2ban and re-enable it after renewal?

I think fail2ban bans IP addresses from connecting at all, rather than from connecting to a specific port, right? In which case it may just be a coincidence indeed.

That much is normal and expected - Let’s Encrypt has to connect over HTTP before it sees the redirect to HTTPS.

Hi @ataraxic


Letsencrypt plans to use a new validation method:

The feature we’re most excited about is multi-perspective validation. Currently, when a subscriber requests a certificate, we validate domain control from a single network perspective. This is standard practice for CAs. If an attacker along the network path for the validation check can interfere with traffic they can potentially cause certificates to be issued that should not be issued.


and have already turned parts of this feature on in our staging environment.

1 Like

hmm… one step forward but not yet there… here is new log

Type: unauthorized
Detail: Invalid response from
[]: “\n\n403



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.

what else do i miss?

I don’t see a 403, instead I see the redirect http -> https and a good http status 404 ( ):

Domainname Http-Status redirect Sec. G 301 0.210 A 301 0.080 A 200 1.750 A 200 1.780 A 301 0.174 A
Visible Content: Moved Permanently The document has moved here . 301 0.083 A
Visible Content: Moved Permanently The document has moved here . 404 1.580 A
Not Found
Visible Content: Not Found The requested URL /.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de was not found on this server. 404 1.593 A
Not Found

Looks like you use the Apache-plugin, that may add a redirect.

So there are two options:

  • Rerun your last command with the -vvv option, check the output to find the temporary redirect. Then check the permissions of that directory
  • Use your correct working webroot / DocumentRoot of your vHost definition.
certbot run -a webroot -i apache -w yourDocumentRoot -d -d

thank you… digesting now… hehehe.
actually webroot ex of yours worked like charm.
i wonder what went wrong && where with my old configuration, as it worked since 2016 without any failures.

Happy to read that it works. Yep, there is the new Letsencrypt certificate:
expires in 90 days, - 2 entries

The webroot can use the existing configuration and the running webserver. And Letsencrypt follows redirects.

So no temporary configuration change and rollback is required.

This may be a false sense of “working”.
More than likely all previous renewals were via TLS-SNI-01 (HTTPS), while the current renewals are using HTTP-01 (HTTP).
So… the old ones connected to your https block/config and the new ones connect to your http block/config.
[which are different, and even if they were not changed, they seem to “work” (or not) in different ways]

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