Problem with certbot and nginx

Help
1

Hi,
I need help setting renewing the certificate for my domain. I’m not that experienced with it but I am trying to use nginx. I used this guide and got it to work the first time. But now I tried to renew & replace the cert manually to make sure it works and it doesn’t. By now I have completely removed nginx with all settings and reinstalled it. I then set up the nginx with the settings you can find below (sites-enabled is symlinked)

I also removed ufw and checked iptables (is empty).

What can I do to troubleshoot this?

nginx sites-available conf
server {
# Listen HTTP
listen 80;
server_name api.frizzelblizzel.de;
# Define LE Location
location ~ ^/.well-known/acme-challenge/ {
default_type “text/plain”;
root /var/www/html;
}
# Else Redirect to HTTPS // API
# location / {
# return 301 https://$host$request_uri;
# }
}

My domain is:
api.frizzelblizzel.de

I ran this command:
certbot --nginx
It produced this output:
Failed authorization procedure. api.frizzelblizzel.de (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://api.frizzelblizzel.de/.well-known/acme-challenge/MRrTbVIii7617xjQuhLrhkP7osJuTtIzD_qF5oVwbQA: Timeout during connect (likely firewall problem)

My web server is (include version):
nginx version: nginx/1.14.2
The operating system my web server runs on is (include version):
Debian 10
I can login to a root shell on my machine (yes or no, or I don’t know):
yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.31.0

2

The config is a bit "constrained".
Because of the temporary removal of the redirect there is no root or action to take for anything other than challenge requests.
In the interim, try adding a root for the requests out of the challenges.
If that doesn't correct the problem, try using:
certbot --nginx --webroot -w /var/www/html -d api.frizzelblizzel.de

OOOOH!
And let's not overlook the obvious:

Make sure that port 80 can reach your system.

3

Taking nothing for granted…
Let’s confirm your Internet IP with what global DNS says:

Name:    api.frizzelblizzel.de
Address:  207.180.247.98

Please show the output of:
curl ifconfig.me

4

Thank you for responding to my question

I changed the config to the following to make it less constrained and restarted nginx:

server {
# Listen HTTP
listen 80;
server_name api.frizzelblizzel.de;
# Define LE Location
 location ~ ^/.well-known/acme-challenge/ {
  default_type "text/plain";
  root         /var/www/html;
}
location / {
  default_type "text/plain";
  root         /var/www/html;
}
# Else Redirect to HTTPS // API
#    location / {
#      return 301 https://$host$request_uri;
#    }
}

Please show the output of:
curl ifconfig.me

207.180.247.98root@vmd49804:~#

Make sure that port 80 can reach your system.

I'm not sure how to do this. I tried this site https://www.yougetsignal.com/tools/open-ports/ and it says port 80 is closed.

I also ran
netstat -tnlp | grep -w 80
output:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 15679/nginx: master

5

That is the expected IP- GOOD.

Than means NGIX is listening on port 80.

The last hurdle is ensuring the firewall/router is port forwarding the outside IP:80 to your inside IP:80
Or if it is directly on the Internet [very likely], that the local firewall is not blocking port 80.
Speak with your hosting provider about that or search their site for help on how to do that.

6

Hmmm it’s a VPS and the cert creation worked before so I dont think it is a problem on the provider side.

I used sudo iptables -F to delete all rules and sudo iptables -L returns:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

so no rules.
I even removed ufw completely.

What else could block the port?

Thank you again for the response and your patience

7

How about:
sudo ufw status

Not too sure about this statement:

EDIT: It might be possible that the "rules" remain after the program is "removed"

8

Otherwise, there must be some “control panel” or such that is preceding your system.
And ask you HSP if they can think of anything (that could be blocking).

9

Thanks again for your time. The problem was an apache2 server that was somehow preinstalled on the VPS.
It was only after I restartet the server that nginx reported problems starting/restarting and then I saw that apache was listening on port 80. After removing apache everything worked.