Renewal, staging fails production works

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain

I ran this command:certbot certonly --dry-run --webroot -w /usr/local/apache-tomcat9/webapps/ -d

It produced this output:
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Connection refused


  • The following errors were reported by the server:

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

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

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

Like a month ago when I had to renew the certificate I got the above error. As I dont manage the network I decided to give it a go and try without --dry-run and it succeded. But whatever that it is making it fail in the staging env could be applied to the final server so I'd like to know what's happening.


I'm getting a connection refused on port 80 too, so it's not limited to the Let's Encrypt staging server. Port 443 is open though.

Your webserver should also be listening with HTTP on port 80.

Hi @jpp1jpp1

that's interesting. I don't get a Connection refused, instead an Apache Tomcat answer:

HTTP Status 404 – nicht gefunden

Type Status Report

Message /.well-known/acme-challenge/o8f99HAFJ55u7v2kVF_-zMydhRbdC-UuM413UDgxgps:

Beschreibung The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

Apache Tomcat/9.0.27

If @Osiris sees a Connection refused, you have a regional filter that blocks.

Hah: Checked with Curl from the same PC, I see the Connection refused too.

May be an UserAgent filter. First sample is my FireFox.

PS: And Chrome has the Connection refused. Different browsers -> different results.

Yup, still "Connection refused" here from the Netherlands. Not that far away from you @JuergenAuer :grin:

1 Like

Staging server needs port 80 but the final production one doesn't?

I also get:
$curl -v telnet://

  • Rebuilt URL to: telnet://
  • Trying
  • connect to port 80 failed: Connection refused

I asked for the 80 port to be open, but the network manager is pretty paranoid, looks like he closed it again. But it doesn't occur to me to check this because the real server issued the certificate.

Port 80 will need to be open for issuance and all renewals. if they will not keep it open, or let you run a pre/post hook to automate opening and closing it for challenges, you will need to use another challenge mechanism, like DNS-01.

It could be the production server has a valid authorization cached. It does so for 30 days. Using --dry-run ensures the staging server always tries to validate the FQDNs and doesn't use any possibly cached authorizations.

No offence, but then your network manager isn't very informed IMHO. If the same service runs behind two ports, why would closing just one port make it any more secure? Note: it doesn't. If the service running on port 80 and port 443 is vulnerable to some kind of exploit, it would most likely be vulnerable on both ports. (The added TLS code for HTTPS would make port 443 even more likely to be vulnerable to some kind of exploit with regard to port 80, which doesn't have TLS code.) Also, if port 80 is only serving a redirect from HTTP to HTTPS, there is absolutely no harm at all to keep port 80 open. No harm at all. See also:

It was that, they opened port 80:

  • The dry run was successful.
1 Like

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