Certbot renew failing

Help
1

My domain is: 12a.sh

I ran this command: certbot renew --dry-run

It produced this output:

# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/12a.sh.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Simulating renewal of an existing certificate for 12a.sh and 2 more domains
Performing the following challenges:
http-01 challenge for 12a.sh
http-01 challenge for gitlab.12a.sh
http-01 challenge for nextcloud.12a.sh
Using default address 80 for authentication.
Waiting for verification...
Challenge failed for domain 12a.sh
Challenge failed for domain gitlab.12a.sh
Challenge failed for domain nextcloud.12a.sh
http-01 challenge for 12a.sh
http-01 challenge for gitlab.12a.sh
http-01 challenge for nextcloud.12a.sh
Cleaning up challenges
Failed to renew certificate 12a.sh with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/gitea.12a.sh.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Simulating renewal of an existing certificate for gitea.12a.sh
Performing the following challenges:
http-01 challenge for gitea.12a.sh
Waiting for verification...
Challenge failed for domain gitea.12a.sh
http-01 challenge for gitea.12a.sh
Cleaning up challenges
Failed to renew certificate gitea.12a.sh with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/gitlab.12a.sh.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Simulating renewal of an existing certificate for gitlab.12a.sh
Performing the following challenges:
http-01 challenge for gitlab.12a.sh
Using default address 80 for authentication.
Waiting for verification...
Challenge failed for domain gitlab.12a.sh
http-01 challenge for gitlab.12a.sh
Cleaning up challenges
Failed to renew certificate gitlab.12a.sh with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/jellyfin.12a.sh.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Simulating renewal of an existing certificate for jellyfin.12a.sh
Performing the following challenges:
http-01 challenge for jellyfin.12a.sh
Waiting for verification...
Challenge failed for domain jellyfin.12a.sh
http-01 challenge for jellyfin.12a.sh
Cleaning up challenges
Failed to renew certificate jellyfin.12a.sh with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/nextcloud.12a.sh.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Simulating renewal of an existing certificate for nextcloud.12a.sh
Performing the following challenges:
http-01 challenge for nextcloud.12a.sh
Waiting for verification...
Challenge failed for domain nextcloud.12a.sh
http-01 challenge for nextcloud.12a.sh
Cleaning up challenges
Failed to renew certificate nextcloud.12a.sh with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/12a.sh/fullchain.pem (failure)
  /etc/letsencrypt/live/gitea.12a.sh/fullchain.pem (failure)
  /etc/letsencrypt/live/gitlab.12a.sh/fullchain.pem (failure)
  /etc/letsencrypt/live/jellyfin.12a.sh/fullchain.pem (failure)
  /etc/letsencrypt/live/nextcloud.12a.sh/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
5 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: 12a.sh
   Type:   connection
   Detail: Fetching
   http://12a.sh/.well-known/acme-challenge/L6bfxXvxYgg3cDykq8hfivyXvF3N3ZGFxk3qtnPjHZE:
   Timeout during connect (likely firewall problem)

   Domain: gitlab.12a.sh
   Type:   connection
   Detail: Fetching
   http://gitlab.12a.sh/.well-known/acme-challenge/ttvQXcJPeYhWaaSvA7zwAhVrSGq8twgV0DTYArbH7sM:
   Timeout during connect (likely firewall problem)

   Domain: nextcloud.12a.sh
   Type:   connection
   Detail: Fetching
   http://nextcloud.12a.sh/.well-known/acme-challenge/vjYSD-ocrgMTCPBLs2bkYTOrICsZeY94eONjJ-V47b4:
   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.
 - The following errors were reported by the server:

   Domain: gitea.12a.sh
   Type:   connection
   Detail: Fetching
   http://gitea.12a.sh/.well-known/acme-challenge/hJOpnlRBY3fnjsQfuAOqTw_MSh5pqPqXXeq--V69HmI:
   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.
 - The following errors were reported by the server:

   Domain: gitlab.12a.sh
   Type:   connection
   Detail: Fetching
   http://gitlab.12a.sh/.well-known/acme-challenge/uq1LS_pr-aWK0zOBsaC00Z2ePMUkXNsq0CyPKb6OAbc:
   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.
 - The following errors were reported by the server:

   Domain: jellyfin.12a.sh
   Type:   connection
   Detail: Fetching
   http://jellyfin.12a.sh/.well-known/acme-challenge/Srbtk07tWLMs2k8zNkiLYe31ki1eI6q1TFEGjT6Hhgk:
   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.
 - The following errors were reported by the server:

   Domain: nextcloud.12a.sh
   Type:   connection
   Detail: Fetching
   http://nextcloud.12a.sh/.well-known/acme-challenge/g1fFj3UhC0hAMoG85n08izixxTy2Ljpy8kSkkYePbjM:
   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): nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu Server 20.04.1

My hosting provider, if applicable, is: My closet

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

I'm able to create the file https://12a.sh/.well-known/test.txt, and certbot is running as root, so I don't think its a permissions issue. Also, but dint of being able to reach 'test.txt', I don't think this is a firewall problem.

This used to work, so I assume something changed. My two guesses are 1. my dynamic dns address changed. The website still works, but maybe certbot ingested the old IP at some point. 2. My nginx config file has grown more complicated. Maybe certbot can no longer parse it.

Other than that, I don't know why renewal is failing or how to move forward debugging this problem on my own.

2 Likes
2

Hello @AleksLitynski and welcome to the forum...
So Im seeing
PORT STATE SERVICE
80/tcp filtered http
443/tcp open https

You'll need to open port 80 to get the result you desire.

4 Likes
3

Yes, you need to open http in order to use https

1 Like
4

Welcome to the Let's Encrypt Community, Aleks :slightly_smiling_face:

1 Like
5

Where are you seeing that? When I run ufw status, I see:

 Status: active

To                         Action      From
--                         ------      ----
80,443/tcp                 ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere                  
2022/tcp                   ALLOW       Anywhere                  
25565/tcp                  ALLOW       Anywhere                  
80,443/tcp (v6)            ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)             
443/tcp (v6)               ALLOW       Anywhere (v6)             
2022/tcp (v6)              ALLOW       Anywhere (v6)             
25565/tcp (v6)             ALLOW       Anywhere (v6)
2 Likes
6

Do you have a network level firewall? I’m guessing your host your own server, does your ISP or router block port 80?

3 Likes
7

I did just get a new router. I can check. See if you can hit http://12a.sh, though.

2 Likes
8

Screenshot_20210114-201652_Samsung Internet
Screenshot_20210114-201652_Samsung Internet1390×1277 364 KB

2 Likes
9

Nope. Are you testing on localhost or 127.0.0.1?

2 Likes
10

I concur that port 80 is closed.

3 Likes
11

I'm just running curl from my location. West Coast USA.

3 Likes
12

You're totally right. I think my browser was caching the page. Curl is failing for me too now.

I'll try to find out what's blocking the port.

2 Likes
13

Do you have any other firewall software, like iptables?

1 Like
14

Peel that onion. You'll find it.

:onion:

2 Likes
15

I'm starting to suspect this is my ISP.

I am running IP tables, but the only rules pertaining to port 80 are allow rules. On my router, there is a firewall, which I disabled. Still no luck.

I sent a message to my ISP to ask if they're doing something, but haven't heard back yet.

If anyone has any other ideas what might be blocking port 80, I'd love to hear them.

2 Likes
16

Who is your ISP? That might help.

1 Like
17

It's RCN. I was able to set up my certificates a few weeks ago, so port 80 was open at some point in the last month.

2 Likes
18

According to this, RCN does, in fact, block port 80. You’ll have to contact them in order to allow it.

2 Likes
19

I'll contact them in the morning. Is there any way to set up lets encrypt certificates if I don't have access to port 80?

(still weird that it worked a few weeks ago, but I'll ask them about it)

2 Likes
20

Nope. Read this article

1 Like