Renewal problem

[rickiek]

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: https://www.zecaafonso46.duckdns.org

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/www.zecaafonso46.duckdns.org.conf

---

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 www.zecaafonso46.duckdns.org
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (www.zecaafonso46.duckdns.org) from /etc/letsencrypt/renewal/www.zecaafonso46.duckdns.org.conf produced an unexpected error: Failed authorization procedure. www.zecaafonso46.duckdns.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.zecaafonso46.duckdns.org/.well-known/acme-challenge/l6Q992x44-UV7Wh2CNmLgvdhaa9Db1UuC7U5cwn32WM: Timeout during connect (likely firewall problem). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.zecaafonso46.duckdns.org/fullchain.pem (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/www.zecaafonso46.duckdns.org/fullchain.pem (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)

IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: www.zecaafonso46.duckdns.org
  Type: connection
  Detail: Fetching
  http://www.zecaafonso46.duckdns.org/.well-known/acme-challenge/l6Q992x44-UV7Wh2CNmLgvdhaa9Db1UuC7U5cwn32WM:
  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): apache2 2.4.25-3+deb9u9

The operating system my web server runs on is (include version): Debian 9.13

My hosting provider, if applicable, is: Own.

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

[schoen]

Hi @rickiek,

It does look like you have a firewall blocking inbound connections on port 80 on this system, and only allowing port 443. Inbound port 80 connections are required for your certificate renewal. Could you find and change that firewall policy?

[rickiek]

Yes, that solved it!

To me it seemed strange that port 80 should be open, seemed natural that only 443 should be open. So I didn’t try it.

Thanks a lot for your fast reply!

Kind Regards,
Rickie

[schoen]

I’m glad it worked for you!

Let’s Encrypt has a document about this

Best Practice - Keep Port 80 Open - Let's Encrypt - Free SSL/TLS Certificates

In case you’re curious, the reason that port 80 is required is kind of obscure—when Let’s Encrypt was first created, we planned to also allow renewals on port 443 using substantially the same technology, but it turned out that the way that some large shared hosting providers handled HTTPS would have allowed one shared customer to obtain certificates for another customer’s domain that was hosted on the same server. The equivalent problem mostly didn’t exist for share hosting providers’ implementation of HTTP, so the file-based authentication method using port 80 was preserved while the one using port 443 [“https-01”] was eliminated. There was another method using port 443 [“tls-sni-01”], but this method subsequently turned out to have other somewhat analogous problems with shared hosting environments. This history is described in section 4.3 of https://jhalderm.com/pub/papers/letsencrypt-ccs19.pdf and caused a fair amount of stress for the people behind Let’s Encrypt at the time! … There is a new and more complicated method [“tls-alpn-01”] that once again uses port 443—third time’s the charm!—but it doesn’t work well with Apache, and Certbot’s Apache integration can’t make use of it.