ACME TLS-SNI-01 Email -- Inboud Port 80 closed by design

Port 80 is closed by external firewall, by design, port 80 is not allowed. Is there any recourse/action that can be taken?

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-auto renew --dry-run

It produced this output:
root@g:/opt/cert# /etc/init.d/apache2 stop
[ ok ] Stopping apache2 (via systemctl): apache2.service.
root@g:/opt/cert# ./certbot-auto renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification…
Cleaning up challenges
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: 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. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)

** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)


  • 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.
    root@g:/opt/cert# ./certbot-auto renew --dry-run
    Saving debug log to /var/log/letsencrypt/letsencrypt.log

My web server is (include version): 2.4.29

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

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

Hi @101jallen

(a) it’s a bad design,
(b) use dns-01 - validation
© use tls-alpn-01 - validation

You have three options.

  1. Change your mind and open port 80 :slight_smile: See this post for some reasons that might be a good idea.

  2. Switch to DNS-01 validation. Certbot has plugins for a number of popular DNS services that can automate this, but unfortunately it’s still difficult to install these plugins with certbot-auto (the PPA is easier, if you can switch to that). If your DNS provider does have an API, you can also set up automated renewals by writing a script (if you can program) - see for details. Alternatively you could try a different client that has better DNS-01 support than Certbot, such as

  3. Switch to the new TLS-ALPN-01 validation method. This works over port 443 like the TLS-SNI-01, but Certbot doesn’t support it yet so you’ll have to use a different client for now. Unfortunately most webservers don’t have flexible enough ALPN support to allow this to work while the webserver is running, so you would have to stop it temporarily during the authorization.


This LE Cert instance is not a public server in the sense. I do not care about traffic, I care about not having tens of thousands of robots poking the content. I’ll work around this.

I can say that purchasing SSL is very attractive when this email was sent out 12 days before the expiration, lacks the domain on which the error is occurring and digging through a few dozen servers and finding that by in large none of the operating systems have a valid OS level update path, it might have been cheaper to have paid for the certs by the time my time is added up getting this resolved.

Great, glad you’ve found a solution.

I apologize for the late notice on the deprecation, and it’s certainly reasonable if you’d like to switch to a paid certificate authority.

You might like to know that if you renew your certificate today, you’ll still be able to use TLS-SNI-01, and the resulting certificate will be valid for 90 days, giving you at least 60 days before you need to have an alternate validation strategy in place.


1 Like

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